Cassandra Vs Voldemort

  By Diego Erdody on May 07, 2010 Translated by Jametong  目的 在Medallia,我们的系统目前有一个关键组件是运行在一个开源的关系型数据库上.由于此组件主要通过主键来查询数据库的条目,我们想尝试将此组件切换到一个键值存储系统上,以利用键值系统提供的多种好处,包含分布式复制、负载均衡以及失败切换.对此组件进行重构以实现纵向扩展是我们的一个目标,附带的其它好处是,可以缓解我们目前较高的磁盘存储需求. 最近,我们花了部分时间来研究这项技术(以及部分其他技术改进,Medallia激动人心的时刻!),考察了多个不同选项.长话短说,最终落在以下两个选择上:Apache Cassandra与Project Voldemort. 这两个项目看似是他们所在开源类别中最成熟的了,都可以提供内置的分散化集群支持,包含分区、容错性以及高可用性.两者都是基于Amazon的Dynamo论文,主要的差异是,Voldemort遵循简单的键值模型,而Cassandra使用了基于BigTable持久化模型的面向列的模型.两者都支持读一致性,也就是读操作总是返回最新的数据,这一点是我们业务所需要的.

Google MapReduce中文版

译者: alex 摘要 MapReduce是一个编程模型,也是一个处理和生成超大数据集的算法模型的相关实现。用户首先创建一个Map函数处理一个基于key/value pair的数据集合,输出中间的基于key/value pair的数据集合;然后再创建一个Reduce函数用来合并所有的具有相同中间key值的中间value值。现实世界中有很多满足上述处理模型的例子,本论文将详细描述这个模型。   MapReduce架构的程序能够在大量的普通配置的计算机上实现并行化处理。这个系统在运行时只关心:如何分割输入数据,在大量计算机组成的集群上的调度,集群中计算机的错误处理,管理集群中计算机之间必要的通信。采用MapReduce架构可以使那些没有并行计算和分布式处理系统开发经验的程序员有效利用分布式系统的丰富资源。   我们的MapReduce实现运行在规模可以灵活调整的由普通机器组成的集群上:一个典型的MapReduce计算往往由几千台机器组成、处理以TB计算的数据。程序员发现这个系统非常好用:已经实现了数以百计的MapReduce程序,在Google的集群上,每天都有1000多个MapReduce程序在执行。

dropbox已挂

难怪最近连接不上,哎 etc文件: 174.36.30.67    dropbox.com 174.36.30.71     www.dropbox.com 75.101.129.115   dl.dropbox.com 75.101.159.151 dl-web.dropbox.com 174.36.30.67      forums.dropbox.com

The Google File System中文版

译者:alex 摘要 我们设计并实现了Google GFS文件系统,一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上,但是它依然了提供灾难冗余的能力,为大量客户机提供了高性能的服务。   虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处,但是,我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础的,不管现在还是将来,GFS和早期的分布式文件系统的设想都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择,衍生出了完全不同的设计思路。   GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部,存储我们的服务产生和处理的数据,同时还用于那些需要大规模数据集的研究和开发工作。目前为止,最大的一个集群利用数千台机器的数千个硬盘,提供了数百TB的存储空间,同时为数百个客户机服务。   在本论文中,我们展示了能够支持分布式应用的文件系统接口的扩展,讨论我们设计的许多方面,最后列出了小规模性能测试以及真实生产系统中性能相关数据。