q篇论文?两位作者详l介l了 Cassandra的系l架?它的设计初衷,设计应用时用到的相x?以及设计/实现/使用q程中得到的l验教训.
Cassandra
– 一个分散的非结构化存储pȝ
By Avinash Lakshman Facebook ,Prashant Malik
Facebook; Translated ByJametong
概要
Cassandra 是一个分布式的存储系l?可用来管理分布在大量廉h服务器上的巨量结构化数据,q同时提供没有单Ҏ障的高可用服?Cassandra的设计目的是q行 在由几百个节?可能分布在多个不同的数据中心)l成的基设施(infrastructure)?当节点达到这个规模时,大大小的组件出现故障就? 能经常发生了.Cassandra在管理持久状态时面͘q些故障,q种情况也驱动Y件系l的可靠?reliability)与可伸羃? (scalability)会依赖于Cassandra的服?虽然大部分情?Cassandra看上d一个数据库pȝ, 也与数据库系l共享大量的设计与实现手D?但是Cassandraq不支持完整的关pL据模?相反,它提供了一个简单数据模型的客户?支持Ҏ据布局 与数据格式的动态控?我们设计Cassandra的初h,可以q行在廉L件上,q能在不牺牲L率的情况下实现高的写吞吐?
1. D
Facebookl护着世界上最大的C交|络q_,利用分布在世界各地的大量数据中心的成千上万台服务?Z?
的用h供服?Facebookq_有严格的业务要求,包含性能、可靠性、效率以及高度的可~性以支持q_的持l增?在一个包含成千上万的lg的基
设施上处理故障是我们的标准运作模?在Q何时?随时都可能出现相当数量的服务器或|络lg故障.q样,软gpȝ在构建时需要将故障当作一U常态?
不是异常来处?Z满上面描述的这些可靠性与可~?Facebook开发了Cassandrapȝ.
Z实现可~性与可靠
?Cassandral合了多众所周知的技?我们设计Cassandra的最初目的是解决收g搜索的存储需?在Facebook,q意味着q个
pȝ需要能够处理非常大的写吞吐?每天几十亿的写请?随着用户数的规模而增?׃我们是通过在地理上分布的数据中心对用户q行服务?因此支持跨越
多个数据中心的数据复制对于降低搜索g时就非常关键?当我们在2008q?月发布收件箱搜烦目?我们?亿的用户,现在我们差不多有2.5亿的?
?Cassandra一直保持了其对业务的承?目前,Facebook内部已经有多个服务部|了Cassandra作ؓ其后端存储系l?
本文
的结构如?W?节讨论相关研I?其中的部分研I对我们的设计有很大影响.W?节介l详l的数据模型.W?节简要介l客LAPI.W?节介l系l设计以
及Cassandra中应用到的分布式法.W?节介l我们如何用Cassandra部vFacebookq_的一个应?
2. 相关研究
对于Z性能、可用性与数据持久性对数据q行分布Q文件系l与数据库社区已l进行了q泛的研I?与仅支持扁^
命名I间(namespace)的点对点(P2P)存储pȝ相比,分布式文件系l通常支持层次?hierarchical)的命名空??
Ficus[14]与Coda[16]cM的系l都是通过牺牲一致性来复制文g以实现高可用(high
availability).通常使用特别的冲H解?conflict resolution)E序来管理更新冲H?update
conflict). Farsite[2]是一个没有用Q何中心服务器的分布式文gpȝ.
Farsite使用复制来实现高可用性与可~?Google文gpȝ(GFS)[9]是另一个分布式文gpȝ,用来存储Google内部应用的各U状
态数?GFS设计比较?用一C服务器存储所有的元数?metadata),数据拆分成块(chunk)存储在多个块服务?chunk
server)?不过,目前Google已经使用Chubby[3]抽象层ؓGFS的主服务器做了容错处?fault
tolerant).Bayou[18]是一个分布式的关pL据库pȝ,它支持断开操作(个h理解为网l断开以后的操?q提供最l的数据一致?
(eventual data
consistency).在这些系l中,Bayou、Coda与Ficus允许断开操作Qƈ且在遇到cM与网l断开与停机时能够做到自动复原.q些pȝ
在冲H解决程序上存在差异.例如,Coda与Ficus执行pȝU别的冲H解?而Bayou允许应用U别的冲H解?但所有这些都保证最l一致?
(eventual
consistency).与这些系l类?即在网l段开的时?Dynamo[6]也允许进行读写操?q用不同的冲突解决机制(部分客户端驱?
来解x新冲H?传统的基于复制的关系数据库系l重点在保证复制数据的强一致?strong
consistency).虽然Z致性ؓ应用写程序提供了一个方便的~程模型,但是,q些pȝ在~性与可用性方面却受到了限?因ؓq些pȝ提供Z
致性的保证,所以在|络分开?它们无法进行处?
Dynamo[6]是一个Amazon开发的存储pȝ,Amazon用它来存储检索用L?
物R.Dynamo利用ZGossip的会员算法来l护每个节点上所有其他节点的信息.可以认ؓDynamo是一个只支持一跌\p?one-hop
request routing)的结构化覆盖?structured overlay).Dynamo使用一个向量时?vector
lock)概要来发现更新冲H?但偏爱客L的冲H解x?Z理向量旉?vector
timestamp),Dynamo中的写操作同时也需要执行一ơ读操作.在一个需要处理非常大的写吞吐量的pȝ?q可能会成ؓ瓉.
Bigtable[4]既提供了l构化也支持数据的分布式,不过它依赖于一个分布式的文件系l来保证数据的持久化.
3. 数据模型
Cassandra中的表是一个按照主键烦引的分布式多l图.它的值是一个高度结构化的对?表中的记录键是一 个没有大限制的字符?虽然它通常都只?6-36个字节的长度.无论需要读写多列,单一记录键的每个副本的每ơ操作都是一个原子操?多个列可以组 合在一起Ş成一个称为column family的列的集?q一点与Bigtable[4]pȝ非常怼.Cassandra提供两种cd的column family,单的column family与超U的column family.可以超Ucolumn family惌成column family里面嵌入column family.q一?应用q可以指定超Ucolumn family或者简单column family里面的列的排序顺?pȝ允许按时间或者名U对列进行排?按照旉对列q行排序可以被类g收g搜索这L应用使用,因ؓ它们的结果始l? 需要按照时间顺序进行展C?column family中的每个列都需要通过规范column family : column来进行访?每个column family中的列都通过规范column family : super column : column来进行访?节6.1l出了一个展CUcolumn family抽象能力的非常好的例?通常,应用都会使用一个独占的Cassandra集群,q将它们当作服务的一部分q行理.? ?Cassandrapȝ支持多表的概?在部|时每个概要中都只能有一个表.
4. API
Cassandra 的API׃面三U方法组?
- insert(table, key, rowMutation)
- get(table, key, columnName)
- delete(table, key, columnName) 列名可以是column family里面的一个特定列,或column family,或超Ucolumn family,或超U列里面的一个列
5.
pȝ架构
一个需要在生环境q{的存储系l的架构是很复杂?除了真实的数据持久化lg?q个pȝq需要包含以下特??
伸羃性与强大负蝲均衡解决Ҏ、会员与故障、故障恢复、副本同步、超负荷处理、状态{URƈ发与d调度、请求编l、请求\由、系l监控与报警以及?
|管?详细描述q里的每一个解x案超Z本论文的范围,我们集中介lCassandra使用的核心的分布式系l技?分区、复制、会员、故障处理以
及~?处理dh需要所有这些模块的协同处理.通常,一个键的请求可能被路由到Cassandra集群的Q何一个节点去处理.q个节点会确定这个特
定的键的副本.对于写操作来?pȝ会将h路由到副本上,q且{待仲裁数量的副本以认写操作完?对于L作来?Z客户端要求的一致性保?pȝ
要么请求\由到最q的副本,要么请求\由到所有的副本q等待达C裁数量的响应.
5.1 分区.
? 量扩展的能力是我们设计Cassandra时考虑的一个关键特?它要求做到在集群中的一l节?Node)之间动态的Ҏ据进行分 ?Cassandra使用一致性散?consistent hash[11])技术在整个集群上对数据q行分区,但是使用一U保证顺?order preserving)的散列函数来实现.在一致性散列中,散列函数的输出结果区间可以看作是一个封闭的圆ŞI间或?#8221;?#8221;(例如,最大的散列值回l到最 的散列?.为系l中的每个节点分配这个空间上的一个随机?代表它在q个环上的位|?每个数据w会根据它的键被指z一个节?通过对这个数据项? 键做散列计算,获得它在环上的位|?然后按照时针找到比它的位置大的W一个节?q个节点p认ؓ是这个键的协调器.应用指定q个 ?Cassandra利用它来对请求做路由.q样,每个节点都会负责环上的一个区?节点与它在环上的前一个节?逆时?之间的区?一致性散列的? 要优势是增加或删除节点只会媄响到它的q邻,其他的节炚w不会受媄?基本的一致性散列算法还面一些挑?首先,在环上随机的为每个节Ҏ定位|可能导 致数据与负蝲的分布不均衡.其次,基本的一致性算法会Ҏ节点之间性能的异质?差异).解决q个问题一般有两种Ҏ:一U方法是在环上ؓ节点指定多个? |?Dynamo采用的方?,另一U方法是分析环上的负载信?q移动负载较低的节点的位|以~解负蝲q重的节?引文[17]Ҏ有详l描 q?Cassandra选择了后?因ؓ使用它可以简化设计与实现,q且可以让负载均衡的选择更加h定?
5.2 复制
Cassandra使用复制来实现高可用性与持久?每个数据w会被复制到NC?N是通过参数”per- instance”配置的复制因?每个?k)都被指派l一个协调节?上一节介l的).由协调节点负责复制落在这个节点范围的数据的复制.除了本 节点范围内的数据存储到本地外,协调器需要将q些键复制到环上的其他N-1个节?关于如何复制数据,Cassandra为客L提供了多个选项.? ?Cassandraq提供了多种不同的复制策?例如”机架不可?#8221;(rack unaware)?#8221;机架可知”(rack aware)(同一个数据中心内)?#8221;数据中心可知”(data-center aware).应用选择的复制策略决定了副本的数?使用”机架可知”?#8221;数据中心可知”复制{略时复制的法要稍微复杂一?Cassandra使用一 个称为Zookeeper[13]的系l在q些节点中选择一个引D?leader).所有节点在加入集群旉需要与此引D联p?q由引导者告知它们负 责哪个环上哪个范围的副本,引导者还需保持协调一致的努力来保持不?以确保没有哪个节点负责环上的过N-1个范?关于一个节点负责的范围的元数据 (metadata)信息都会在每个节点做本地~存,q在Zookeeper内做定w处理,q样当一个节点崩溃ƈq回的时候就可以知道它到底负责哪个范 ?借用Dynamo的措?我们认ؓ负责一个给定范围的节点是这个范围的”优选清?#8221;.
5.1节已l介l了每个节点都知悉系l中的所有其 他节?以及它们各自负责的范?通过攑֮5.2节介l的仲裁?quorum)的要?即在出现节Ҏ障与|络分区的情况下,Cassandra也可 以保证持久?在断c冷却故障、网l故障或自然灑֮Ӟ数据中心也会发生故障.可以配置Cassandra使得每条记录都被复制到多个不同的数据中心. 实际?可以q样构徏一个键的偏好列?以实现键的存储节点分布在多个数据中心.q些数据中心都是通过高速网l进行互?即整个数据中心出现故障,q种 跨越多个数据中心的复制架构允许我们做C宕机.
5.3 会员
Cassandra中的? 会员是ZScuttlebutt[19]?一个非帔R效的反熵闲话(anti-entropy Gossip)机制. Scuttlebutt的突出的特点是它非常高效的CPU利用率以及非帔R效的Gossip通道利用?在Cassandra?pȝGossip不止? 来管理会员信?也用来传输其他系l相关的控制状?
5.3.1 故障?/strong>
故障是q?
样一U机?通过它一个节点在本地可以确定系l中的Q一其他节点是活着q是M.在Cassandra?故障还被用来避免在多个操作中与不可达节
点的q行通讯.Cassandra使用的是Φ Accrual故障器[8]的一个改q版?
Accrual故障器的设计思\?故障模块ƈ不是产生一个布值来标记一个节Ҏzȝq是M.相反,故障模块ؓ每个被监控节点生一个代
表其怀疑别的数?此D定义?#934;.其基本的思\是用Φ的值来表示一个范?可以动态对其进行调整以反映监控节点上的|络与负载情?
Φ有以?
几种涵义:l定部分阈?#934;,q假定当Φ=1时我们就军_怀疑一个节点A,我们犯错?例如,q个军_在将来可能由于心x收gq而被证明是错误的)的概?
?0%.Φ=2时出错的概率大约?%,Φ=3大约?.1%,{等.pȝ中的每个节点都会l护一个滑动窗?来表C集中其他节点的gossip信息
的到N隔时?定了这些到N隔时间的分布?可以计出Φ的g.虽然原论文认个分布近g高斯分布(Gaussian
distribution),׃gossip通道的本性以及他对g?latency)的媄?我们认ؓ它与指数分布(Exponential
Distribution)更加怼.据我们所?我们实现的Accrual故障在ZGossip的配|中q属首创.
Accrual故障器在准性与速度上表现都非常? 它们也能很好的适应不同的网l环境或服务器负载环?
5.4 引导E序
当一个节点第一ơ启动的时?它会随机的选择一个o?token)作ؓ它在环上的位|?Z定w的需?映射
关系会被持久化到本地盘以及Zookeeper?接着令牌信息会被传播到整个集?我们是通过它来知道集群中的所有节点以及它们在环上的位|的.?
q它,M一个节炚w可以一个键(key)的请求\由到集群中的合适的节点.在引DE中,当一个新的节炚w要加入集时,它需要读取它的配|文??
|文件中包含集群中的几个联络点名?我们这些联l点UCؓ集群的种?seed).U子也可以来自一个类gZookeeper的配|服?
(configuration service).
在Facebook的环境中,节点停机旉(׃故障或维护Q?通常都很短暂,但有时也会g
长一D|?故障可能有多UŞ?如磁盘故障、CPU损坏{?节点停机很少不表C永q离开(删除节点),因此,不该D分区指派的重新^衡或不可辑։本的
修复.cM?手工错误可能会导致意外地启动新的Cassandra节点.Z避免出现q种效果,所有消息中都包含了每个Cassandra实例集群?
U?如果配置中的手工错误D一个节点尝试加入一个错误的Cassandra实例,可以根据集名U来L?׃上述原因,使用一U明的机制来往
Cassandra实例中添加或从中删除节点或许更加合?理员用命令行(command
line)工具或者浏览器登陆到Cassandra的节?提出一个会员变?节点变更)来加入或d集群.
5.5 集群的扩?/strong>
当有一个新节点加入pȝ?它会被分配一个o?q样可以缓解负载过重的节点的负?q样D的结果是,q? 个新的节点会分担部分先前由其他节点负责的范围.Cassandra的引导算法可ql中的Q何其他节炚w过命o行工hCassandra的网lA表盘 (web dashboard)来启?攑ּq部分数据的节点通过内核到内核的拯技术将数据拯到新的节?我们的运l经验显C?从单个节点传输的速率可以辑ֈ 40MB/s.我们q在努力对它q行改善,通过让多个副本来参与q行化引g?cM于Bittorrent技?
5.6 本地持久?/strong>
Cassandrapȝ要依赖于本地文gpȝ做数据的持久?q些数据是以一U易于高效检索的格式存储在磁
盘上.通常,一ơ写操作会涉及提交日?Commit
Log,Z数据耐用性与可恢复?写入,以及一ơ内存数据结构的更新.只有在写入提交日志成功返回后,才会执行内存数据l构的写入操?在每CZ,
我们都单独地分配了一块磁盘存放提交日?׃提交日志地所有写入操作都是连l的(sequential),所以我们可以最大程度的利用盘吞吐?当内
存数据结构的大小(Ҏ数据量大与对象数量计算得出)过一定的阈?它就会将自n转储到磁?q个写操作会机器配备大量的廉L盘的某一个上执行.所
有到盘的写操作都是序?随着旉的推U?盘上就会存在多个这L文g,后台会有一个合q进E?merge
process)这些文件合q成一个文?q个q程与Bigtablepȝ中的压羃q程(compact process)非常cM.
通常,一
个读操作在检索磁盘文件之前会先查询这个内存数据结?索磁盘文件是按照先新后旧的方式进行的.当发生磁盘检索时,我们可能需要查看多个磁盘文?Z
避免查看不包含相应键(key)的文?我们使用了布隆过滤器(bloom
filter),它对文g中的键进行了汇?它同时存在于每一个数据文件中q常d内存?当需要检索某个键?会先查阅此布隆过滤器以确认给定的文g?
否确实包含此?column
family中的一个键可以包含大量的列.当检索的列距键较远时还需要利用一些特D的索引.Z避免在磁盘上扫描每一?我们l护了一份列索引来帮助我
们直接定位到盘上的对应?׃指定键的列已l被序列化ƈ写出到磁?我们是按照每个块(chunk)256K的范围创建烦引的.块的范围大小是可配置
?不过,我们发现256K的大在我们的生产工作负载下q作良好.
5.7 实现l节
?
台机器上的Cassandraq程主要׃下模块组?分区模块、集会员管理模块、故障检模块与存储引擎模块.所有这些模块都依赖于一个事仉动的?
层模?它是按照SEDA[20]架构设计?消息处理管道与d道切分成了多个阶段.所有这些模块都是完全利用Java实现.集群会员模块与故障检
模块都建立在用非堵塞IO的网l层?所有的pȝ控制信息都依赖于ZUDP协议的消息传?而复制与h路由{应用相关的消息则依赖于TCP协议?
?h路由模块的实C用了一个固定的状态机.当集的M节点收到一个读/写请求时,状态机都会在以下几U状态之间切?
(i)定位拥有q个键的数据的节?ii)请求\由到此节点ƈ{待响应到达(iii)如果{复没有在配|的时旉内到?将此请求置为失败ƈq回l?
客户?iv)Ҏ旉戳算出最新的{复(v)ZQ何数据不是最新的副本的安排数据修?Z赯,详细的故障情冉|们就不在此讨Z.q个pȝ的复
制模式可以配|ؓ同步?synchronous write)也可以配|ؓ异步?asynchronous
write).对于特定的需要高吞吐量的pȝ,我们会选择依赖于异步复?q时,pȝ接收到的写操作远q超q读操作.对于使用同步的例?在返回给用户?
前我们会{待辑ֈ仲裁的响应数?
在Q何日志文件系l中,都需要有一个机制来清理提交日志?commit log entry),
在Cassandra?我们使用一U滚动的提交日志,在一个旧的提交日志超q一个特定的可配|大后,推Z个新的提交日?在我们的生环境??
们发?28M的滚动提交日志运作良? 每个提交日志都有一个头信息,基本上是一个大固定的位向?其大通常过一个系l可能处理的column
family的个?在我们的实现?对于每个column family,我们都会生成一个内存数据结构以及一个数据文?每当一个特定的column
family的内存数据结构{储到盘,我们都会在提交日志中记录它对应的?说明q个column
family已经被成功地持久化到盘.q表明这部分信息已经提交?每个提交日志都有一份对应的位向?q些位向量的信息同时也在内存中进行维?每当
发生提交日志滚动的时?它的位向?以及它之前滚动的提交日志的位向量都会被检查一?如果定所有的数据都已l被成功地持久化到磁?删除这些提?
日志.到提交日志的写操作可以是普通模?normal mode)也可以是快速同步模?fast sync
mode).在快速同步模式下,到提交日志的写操作会被缓?buffered).q表明在机器崩溃时可能会出现潜在的数据丢?在这U模式下,内存数据
l构转储到磁盘也会被~冲.传统的数据库通常都不会被设计用来处理特别高的写入吞吐?Cassandra所有的写入操作都{换成序写操作以最大限?
地利用磁盘的写入吞吐?׃转储到磁盘的文g不再会被修改,从而在d它们的时候也不需要持有Q何锁.Cassandra的服务实例的d操作实际上都
是无锁操?所?我们q不需要应付基于B-Tree的数据库实现中存在的q发问题.
Cassandrapȝ通过主键来来索引所有数?盘上的
数据文g被分解成一pd的块.每个块内最多包?28个键,q过一个块索引来区?块烦引抓取块内的键的相对偏移量以及其数据大小.当内存数据结构被?
储到盘?pȝ会ؓ其生成一个烦?它的偏移量会被写当作索引写到盘?内存中也会维护一份这个烦引以提供快速访?一个典型的L作L会先索内
存数据结?如果扑ֈ将数据q回l应用程?因ؓ内存数据l构中包含Q何键的最新数?如果没有扑ֈ,那么我们需要对所有磁盘数据文件按照时间逆序?
执行盘IO.׃LL最新的数据,我们先查阅最新的文g,一旦找到数据就q回.随着旉的推U?盘上的数据文g数量会出现增?我们会运行一?
非常cM于Bigtablepȝ的压~进E?通过它将多个文g压羃成一个文?基本上是对很多排序好的数据文件进行合q排?pȝL会压~大彼此接q?
的文?例如,永远不会出现一?00GB的文件与另一个小?0GB的文件进行合q的情Ş.每隔一D|?׃q行一个主压羃E序来将所有相关的数据?
件压~成一个大文g.q个压羃q程是一个磁盘IO密集型的操作.需要对此做大量的优化以做到不媄响后l的读请?
6. 实践l验
在设计、实C及维护Cassandra的过E中,我们U篏了不有益的l验,也获得了许多l验教训.一个非? 基本的经验教训是,在没有理解应用的使用效果之前不要增加M新特?最成问题的情况不仅仅来自节点崩溃与|络分区.我们在此分享几个有的场景.
- ? 发布收g搜索应用之?我们必须先ؓ过1亿用L7TB的收件箱数据创徏索引,接着它们存储到我们的MySQL[1]基础l构?然后再将它们加蝲 到Cassandrapȝ?整个处理q程涉及到在MySQL数据文g上运行Map/Reduce[7]d,为它们创建烦?q按照逆序索引的方式将? 们存储到Cassandra?实际?M/Rq程是作为Cassandra的客Lq行?我们为M/Rq程开放了后端通道,使它们可以按用户汇总逆序 索引,q将序列化后的数据传输给Cassandra实例,以节省序列化/反序列化的开销.q样,Cassandra实例的瓶颈就只剩下网l带宽了.
- ? 部分应用都是只需要每个键的每个副本的原子操作.不过,q是有部分应用需要交易支?它的主要目的是维护辅助烦?大部分有着多年RDBMS相关开发经? 的开发h员都认ؓq个Ҏ很有用.我们正在研究开放此cd子操作的机制.
- 我们试实现了多U故障检器,包含[15]与[5]中所描述 的故障检器.我们得到的经验是,随着集群规模的增?到故障的时间也会出现增?出了我们的接受限度.在一个特定的包含100个节点的实验? 一个故障节点竟然耗费大约2分钟的时?在我们的环境?q实际上是不可接受的.利用accrual故障器q设|一个稍显保守的PHI(Φ)?? |ؓ5),在上面的实验中检到故障的^均时间大Uؓ15U?
- 不要对监控想当然.Cassandrapȝ与Ganglia[12]做了 很好的集?Ganglia是一个分布式的性能监控工具.我们向Ganglia开放了各种pȝU别的指?在Cassandra部v到我们的生环境? q一点帮助我们更q理解了这个系l的行ؓ.盘会无~无故地出现故障.当磁盘出现故障时,引导法中有多个异常分支(hook)来修复这个节?但是, q实际上是一个管理操?
- 虽然Cassandra是一个完全分散地pȝ,我们了解?Z使一些分布式Ҏ的实现更加可控,支持一定数 量的协调操作q是非常必要?我们打算寚w分关键特性用Zookeeper抽象,q些Ҏ实际上与用Cassandra作ؓ存储引擎的应用关pM?
6.1 Facebook的收件箱搜烦
对于收g搜?我们为每个用L护了一份所有消息的索引,q些消息包含用户作ؓ发送? 的消息也包含其作为接收者的消息.目前启用了两U类型的索引(a)术语搜烦(b)互动搜烦,Ҏ与此用户l定互动的h的名U返回用户发送给此h以及从此? 处接收的所有消?q个概要(schema)包含两个column family,对于查询(a),用user id作ؓ?key),以构成消息的单词作ؓ?super column).对于查询(b),user id仍然是键(key),接收者的id都是super column.对于q些super column中的每一?单个消息的识别符都是?Z实现快速检?Cassandra为数据的~存提供了特定的钩子(hook)代码.例如,当用 Ld搜烦栏时,会有一条异步消息发送给Cassandra集群,再通过用户索引在高速缓?buffer cache)中准备好该用L数据.q样,当实际的搜烦查询h到达?搜烦l果很可能已l在内存中了.目前,q个pȝ?50个节点的集群上存储了大约 50多TB的数?q些节点分布在美国东西v岸的多个数据中心.下面展示了部分生长环境中量出来的读性能数据.
| ? 时统?/th> | 搜烦交互 | 术语 |
|---|---|---|
| 最?/td> | 7.69ms | 7.78ms |
| ? ?/td> | 15.69ms | 18.27ms |
| 最?/td> | 26.13ms | 44.41ms |
7. l论
我们已经建立、实现ƈl护的存储系l，可以提供可~性、高性能与广泛的适用?我们的经验表 ?Cassandra可以在提供低延时(low latency)的同时提高非帔R的更新吞吐量(thoughput).后期的工作涉及增加压~功能、跨多个键的原子操作支持以及辅助烦引支?
8. 致谢
Cassandra极大地受益与Facebook公司内部许多同事的反?另外q要特别感谢Karthik Ranganathan,他对MySQL中的所有数据徏立了索引q将q些数据q移到Cassandra中作为我们第一份正式部|?另外q要感谢来自 EPFL的Dan Dumitriu,感谢他对我们提出的宝贵徏?关于[19]与[8]).
9. 参考文?/strong>
[1]
MySQL AB. Mysql.
[2] Atul Adya, William J. Bolosky, Miguel Castro,
Gerald Cermak, Ronnie Chaiken, John R. Douceur, Jon Howell, Jacob R.
Lorch, Marvin Theimer, and Roger P. Wattenhofer. Farsite: Federated,
available, and reliable storage for an incompletely trusted environment.
In In Proceedings of the 5th Symposium on Operating Systems Design and
Implementation (OSDI, pages 1-14, 2002.
[3] Mike Burrows. The chubby
lock service for loosely-coupled distributed systems. In OSDI ‘06:
Proceedings of the 7th symposium on Operating systems design and
implementation, pages 335-350, Berkeley, CA, USA, 2006. USENIX
Association.
[4] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C.
Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes,
and Robert E. Gruber. Bigtable: A distributed storage system for
structured data. In In Proceedings of the 7th Conference on USENIX
Symposium on Operating Systems Design and Implementation – Volume 7,
pages 205-218, 2006.
[5] Abhinandan Das, Indranil Gupta, and Ashish
Motivala. Swim: Scalable weakly-consistent infection-style process group
membership protocol. In DSN ‘02: Proceedings of the 2002 International
Conference on Dependable Systems and Networks, pages 303-312,
Washington, DC, USA, 2002. IEEE Computer Society.
[6] Giuseppe de
Candia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Alex
Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels.
Dynamo: amazonO? s highly available key-value store. In Proceedings of
twenty-first ACM SIGOPS symposium on Operating systems principles, pages
205-220. ACM, 2007.
[7] Jeffrey Dean and Sanjay Ghemawat. Mapreduce:
simplified data processing on large clusters. Commun. ACM,
51(1):107-113, 2008.
[8] Xavier D?efago, P?eter Urba?n, Naohiro
Hayashibara, and Takuya Katayama. The φ accrual failure detector. In RR
IS-RR-2004-010, Japan Advanced Institute of Science and Technology,
pages 66-78, 2004.
[9] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak
Leung. The google file system. In SOSP ‘03: Proceedings of the
nineteenth ACM symposium on Operating systems principles, pages 29-43,
New York, NY, USA, 2003. ACM.
[10] Jim Gray and Pat Helland. The
dangers of replication and a solution. In In Proceedings of the 1996 ACM
SIGMOD International Conference on Management of Data, pages 173-182,
1996.
[11] David Karger, Eric Lehman, Tom Leighton, Matthew Levine,
Daniel Lewin, and Rina Panigrahy. Consistent hashing and random trees:
Distributed caching protocols for relieving hot spots on the world wide
web. In In ACM Symposium on Theory of Computing, pages 654-663, 1997.
[12]
Matthew L. Massie, Brent N. Chun, and David E.Culler. The ganglia
distributed monitoring system: Design, implementation, and experience.
Parallel Computing, 30:2004, 2004.
[13] Benjamin Reed and Flavio
Junquieira. Zookeeper.
[14] Peter Reiher, John Heidemann, David
Ratner, Greg Skinner, and Gerald Popek. Resolving file conflicts in the
ficus file system. In USTC’94: Proceedings of the USENIX Summer 1994
Technical Conference on USENIX Summer 1994 Technical Conference, pages
12-12, Berkeley, CA, USA, 1994. USENIX Association.
[15] Robbert Van
Renesse, Yaron Minsky, and Mark Hayden. A gossip-style failure detection
service. In Service,Tˇ Proc. Conf. Middleware, pages 55-70, 1996.
[16]
Mahadev Satyanarayanan, James J. Kistler, Puneet Kumar, Maria E.
Okasaki, Ellen H. Siegel, and David C. Steere. Coda: A highly available
file system for a distributed workstation environment. IEEE Trans.
Comput., 39(4):447-459, 1990.
[17] Ion Stoica, Robert Morris, David
Liben-nowell, David R. Karger, M. Frans Kaashoek, Frank Dabek, and Hari
Balakrishnan. Chord: a scalable peer-to-peer lookup protocol for
internet applications. IEEE/ACM Transactions on Networking, 11:17-32,
2003.
[18] D. B. Terry, M. M. Theimer, Karin Petersen, A. J. Demers,
M. J. Spreitzer, and C. H. Hauser. Managing update conflicts in bayou, a
weakly connected replicated storage system. In SOSP ‘95: Proceedings of
the fifteenth ACM symposium on Operating systems principles, pages
172-182, New York, NY, USA, 1995. ACM.
[19] Robbert van Renesse, Dan
Mihai Dumitriu, Valient Gough, and Chris Thomas. Efficient
reconciliation and flow control for anti-entropy protocols. In
Proceedings of the 2nd Large Scale Distributed Systems and Middleware
Workshop (LADIS ‘08), New York, NY, USA, 2008. ACM.
[20] Matt Welsh,
David Culler, and Eric Brewer. Seda: an architecture for
well-conditioned, scalable internet services. In SOSP ‘01: Proceedings
of the eighteenth ACM symposium on Operating systems principles, pages
230-243, New York, NY, USA, 2001. ACM.
No related posts.
]]>