没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
43页
系统的可扩展性是推动NoSQL运动发展的的主要理由,包含了分布式系统协调,故障转移,资源管理和许多其他特性。这么讲使得NoSQL听起来像是一个大筐,什么都能塞进去。尽管NoSQL运动并没有给分布式数据处理带来根本性的技术变革,但是依然引发了铺天盖地的关于各种协议和算法的研究以及实践。正是通过这些尝试逐渐总结出了一些行之有效的数据库构建方法。在这篇文章里,我将针对NoSQL数据库的分布式特点进行一些系统化的描述。
资源推荐
资源详情
资源评论
NoSQLFan
关注 NoSQL 相关的新闻与技术
NoSQL
书籍
分类列表
关于本站
NoSQL
讨论区
NoSQL 数据库的分布式算法
作者:nosqlfan on 星期四, 十一月 22, 2012 ·
评论本文
【阅读:8,511
次】
本文英文原文发表于知名技术博客《Highly Scalable Blog》,对 NoSQL 数
据库中的分布式算法和思想进行了详细的讲解。文章很长,由@juliashine 进
行翻译投稿。感谢译者的共享精神!
译者介绍:Juliashine 是多年抓娃工程师,现工作方向是海量数据处理与分析,
关注 Hadoop 与 NoSQL 生态体系。
英文原文:《Distributed Algorithms in NoSQL Databases》
译文地址:《NoSQL
数据库的分布式算法 》
系统的可扩展性是推动 NoSQL 运动发展的的主要理由,包含了分布式系统协
调,故障转移,资源管理和许多其他特性。这么讲使得 NoSQL 听起来像是一
个大筐,什么都能塞进去。尽管 NoSQL 运动并没有给分布式数据处理带来根
本性的技术变革,但是依然引发了铺天盖地的关于各种协议和算法的研究以及
实践。正是通过这些尝试逐渐总结出了一些行之有效的数据库构建方法。在这
篇文章里,我将针对 NoSQL 数据库的分布式特点进行一些系统化的描述。
接下来我们将研究一些分布式策略,比如故障检测中的复制,这些策略用黑体
字标出,被分为三段:
数据一致性。NoSQL 需要在分布式系统的一致性,容错性和性能,低延
迟及高可用之间作出权衡,一般来说,数据一致性是一个必选项,所以
这一节主要是关于数据复制和数据恢复。
数据放置。一个数据库产品应该能够应对不同的数据分布,集群拓扑和
硬件配置。在这一节我们将讨论如何分布以及调整数据分布才能够能够
及时解决故障,提供持久化保证,高效查询和保证集群中的资源(如内
存和硬盘空间)得到均衡使用。
对等系统。像 leader election 这样的的技术已经被用于多个数据库
产品以实现容错和数据强一致性。然而,即使是分散的的数据库(无中
心)也要跟踪它们的全局状态,检测故障和拓扑变化。这一节将介绍几
种使系统保持一致状态的技术。
数据一致性
众所周知,分布式系统经常会遇到网络隔离或是延迟的情况,在这种情况下隔
离的部分是不可用的,因此要保持高可用性而不牺牲一致性是不可能的。这一
事实通常被称作“CAP 理论”。然而,一致性在分布式系统中是一个非常昂贵的
东西,所以经常需要在这上面做一些让步,不只是针对可用性,还有多种权衡。
为了研究这些权衡,我们注意到分布式系统的一致性问题是由数据隔离和复制
引起的,所以我们将从研究复制的特点开始:
可用性。在网络隔离的情况下剩余部分仍然可以应对读写请求。
读写延迟。读写请求能够在短时间内处理。
读写延展性。读写的压力可由多个节点均衡分担。
容错性。对于读写请求的处理不依赖于任何一个特定节点。
数据持久性。特定条件下的节点故障不会造成数据丢失。
一致性。一致性比前面几个特性都要复杂得多,我们需要详细讨论一下
几种不同的观点。 但是我们不会涉及过多的一致性理论和并发模型,因
为这已经超出了本文的范畴,我只会使用一些简单特点构成的精简体系。
o 读写一致性。从读写的观点来看,数据库的基本目标是使副本趋
同的时间尽可能短(即更新传递到所有副本的时间),保证最终
一致性。除了这个较弱的保证,还有一些更强的一致性特点:
写后读一致性。在数据项 X 上写操作的效果总是能够被后
续的 X 上的读操作看见。
读后读一致性。在一次对数据项 X 的读操作之后,后续对
X 的读操作应该返回与第一次的返回值相同或是更加新的
值。
o 写一致性。分区的数据库经常会发生写冲突。数据库应当能处理
这种冲突并保证多个写请求不会被不同的分区所处理。这方面数
据库提供了几种不同的一致性模型:
原子写。假如数据库提供了 API,一次写操作只能是一个
单独的原子性的赋值,避免写冲突的办法是找出每个数据
的“最新版本”。这使得所有的节点都能够在更新结束时获
得同一版本,而与更新的顺序无关,网络故障和延迟经常
造成各节点更新顺序不一致。 数据版本可以用时间戳或是
用户指定的值来表示。Cassandra 用的就是这种方法。
原子化的读-改-写。应用有时候需要进行 读-改-写 序列操
作而非单独的原子写操作。假如有两个客户端读取了同一
版本的数据,修改并且把修改后的数据写回,按照原子写
模型,时间上比较靠后的那一次更新将会覆盖前一次。这
种行为在某些情况下是不正确的(例如,两个客户端往同
一个列表值中添加新值)。数据库提供了至少两种解决方
法:
冲突预防。 读-改-写 可以被认为是一种特殊情况下
的事务,所以分布式锁或是 PAXOS [20, 21] 这样
的一致协议都可以解决这种问题。这种技术支持原
子读改写语义和任意隔离级别的事务。另一种方法
是避免分布式的并发写操作,将对特定数据项的所
有写操作路由到单个节点上(可以是全局主节点或
者分区主节点)。为了避免冲突,数据库必须牺牲
网络隔离情况下的可用性。这种方法常用于许多提
供强一致性保证的系统(例如大多数关系数据库,
HBase,MongoDB)。
冲突检测。数据库跟踪并发更新的冲突,并选择回
滚其中之一或是维持两个版本交由客户端解决。并
发更新通常用向量时钟 [19] (这是一种乐观锁)
来跟踪,或者维护一个完整的版本历史。这个方法
用于 Riak, Voldemort, CouchDB.
现在让我们仔细看看常用的复制技术,并按照描述的特点给他们分一下类。第
一幅图描绘了不同技术之间的逻辑关系和不同技术在系统的一致性、扩展性、
可用性、延迟性之间的权衡坐标。 第二张图详细描绘了每个技术。
剩余42页未读,继续阅读
资源评论
- 普通网友2014-07-01nosql 缓存用的多.内存数据库现在...
tghdlut
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功