如果贵公司是Uber,需要存储每30秒由司机和乘客应用程序发送出去的位置数据,该如何是好?要知道,有许多实时数据是需要实时使用的。
Uber的解决方案很全面。它构建了自己的系统,该系统在Mesos上运行Cassandra。这在Uber的软件工程师阿披谢克·弗玛(Abhishek Verma)的一次畅谈中都得到了解释,那次畅谈题为《Uber:多个数据中心环境下的Mesos上的Cassandra》(多张幻灯片,详见http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016)。
这是不是贵公司也应采取的做法?这是读者在听阿披谢克的畅谈时会忖到的一个饶有意思的想法。
如今,开发人员要做出许多艰难的选择。我们该不该全身心地投入到云?哪一种云?成本是不是太过高昂?我们是否要担心厂商锁定?还是我们应该双管齐下,亲自搭建一种混合架构?还是说由于担心无法获得50%的毛利率,我们就应该完全自己搞?
Uber决定自行构建。或者确切地说,它决定通过结合两种功能非常强大的开源组件,组建一套自己的系统。需要的是让Cassandra和Mesos协同运行的一种方法,这就是Uber构建的方法。
对Uber来说,做出这个决定并不是太难。它财力很雄厚,拥有构建、维护和更新这种复杂系统所需的一流人才和资源。
由于Uber的目标是能够为任何地方准备出行的任何人确保99.99%的可用性,你在扩展到无限庞大的规模时,希望能够控制成本确实有其必要性。
但是你在听畅谈时,会认识到构建这种系统需要投入大量的精力。这果真是普通公司所能胜任的吗?不,胜任不了。如果你属于对云说不的那些人,希望每个人都在最基本的裸机上构建自己的代码,就要牢记这一点。
拿金钱换时间常常很划算。拿金钱换技能常常绝对必不可少。
考虑到Uber在可靠性方面的目标:在10000个请求中,只有1个请求可以失败,它就需要运行多个数据中心。由于事实证明Cassandra可以跨数据中心处理庞大的负载和工作,它成为数据库方面的选择合情合理。
如果你想确保任何地方的任何人都有可靠的出行,就需要高效地利用资源。这正是使用Mesos之类的数据中心操作系统背后的想法。通过在同样的机器统计多路复用服务,你需要的机器数量可以减少30%,这节省了资金。之所以选择Mesos,是因为当时Mesos是被证明唯一可处理数万个机器组成的庞大集群的产品,Uber需要这么大的集群。Uber采取的都是大手笔。
一些更令人关注的结果还有什么?
下面是我对那次畅谈的注释:
开始阶段
现阶段
生产环境
Mesos背景知识介绍
Apache Cassandra背景知识介绍
Mesosphere + Uber + Cassandra = Dcos-Cassandra-Service
使用的是Mesos容器,而不是Docker。
覆盖配置中的5个端口(storage_port、ssl_storage_port、native_transport_port、rpcs_port和jmx_port),那样多个容器可以在同一个机器上运行。
使用持久性卷,那样数据可以存储在沙盒目录外面。万一Cassandra失效,数据仍在持久性卷中,并提供给同一任务。
动态预留用来确保有资源可用于重新启动失效的任务。
原文来自:云疯报
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
如果贵公司是Uber,需要存储每30秒由司机和乘客应用程序发送出去的位置数据,该如何是好?要知道,有许多实时数据是需要实时使用的。
Uber的解决方案很全面。它构建了自己的系统,该系统在Mesos上运行Cassandra。这在Uber的软件工程师阿披谢克·弗玛(Abhishek Verma)的一次畅谈中都得到了解释,那次畅谈题为《Uber:多个数据中心环境下的Mesos上的Cassandra》(多张幻灯片,详见http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016)。
这是不是贵公司也应采取的做法?这是读者在听阿披谢克的畅谈时会忖到的一个饶有意思的想法。
如今,开发人员要做出许多艰难的选择。我们该不该全身心地投入到云?哪一种云?成本是不是太过高昂?我们是否要担心厂商锁定?还是我们应该双管齐下,亲自搭建一种混合架构?还是说由于担心无法获得50%的毛利率,我们就应该完全自己搞?
Uber决定自行构建。或者确切地说,它决定通过结合两种功能非常强大的开源组件,组建一套自己的系统。需要的是让Cassandra和Mesos协同运行的一种方法,这就是Uber构建的方法。
对Uber来说,做出这个决定并不是太难。它财力很雄厚,拥有构建、维护和更新这种复杂系统所需的一流人才和资源。
由于Uber的目标是能够为任何地方准备出行的任何人确保99.99%的可用性,你在扩展到无限庞大的规模时,希望能够控制成本确实有其必要性。
但是你在听畅谈时,会认识到构建这种系统需要投入大量的精力。这果真是普通公司所能胜任的吗?不,胜任不了。如果你属于对云说不的那些人,希望每个人都在最基本的裸机上构建自己的代码,就要牢记这一点。
拿金钱换时间常常很划算。拿金钱换技能常常绝对必不可少。
考虑到Uber在可靠性方面的目标:在10000个请求中,只有1个请求可以失败,它就需要运行多个数据中心。由于事实证明Cassandra可以跨数据中心处理庞大的负载和工作,它成为数据库方面的选择合情合理。
如果你想确保任何地方的任何人都有可靠的出行,就需要高效地利用资源。这正是使用Mesos之类的数据中心操作系统背后的想法。通过在同样的机器统计多路复用服务,你需要的机器数量可以减少30%,这节省了资金。之所以选择Mesos,是因为当时Mesos是被证明唯一可处理数万个机器组成的庞大集群的产品,Uber需要这么大的集群。Uber采取的都是大手笔。
一些更令人关注的结果还有什么?
下面是我对那次畅谈的注释:
开始阶段
现阶段
生产环境
Mesos背景知识介绍
Apache Cassandra背景知识介绍
Mesosphere + Uber + Cassandra = Dcos-Cassandra-Service
使用的是Mesos容器,而不是Docker。
覆盖配置中的5个端口(storage_port、ssl_storage_port、native_transport_port、rpcs_port和jmx_port),那样多个容器可以在同一个机器上运行。
使用持久性卷,那样数据可以存储在沙盒目录外面。万一Cassandra失效,数据仍在持久性卷中,并提供给同一任务。
动态预留用来确保有资源可用于重新启动失效的任务。
原文来自:云疯报
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com