NoSQL数据库笔谈.doc
《NoSQL数据库笔谈.doc》由会员分享,可在线阅读,更多相关《NoSQL数据库笔谈.doc(66页珍藏版)》请在咨信网上搜索。
1、(word完整版)NoSQL数据库笔谈NoSQL数据库笔谈颜开v0。22010.21. 序2. 思想篇1. CAP2. 最终一致性1. 变体3. BASE4. 其他1. I/O的五分钟法则2. 不要删除数据3. RAM是硬盘,硬盘是磁带4. Amdahl定律和Gustafson定律5. 万兆以太网3. 手段篇1. 一致性哈希1. 亚马逊的现状2. 算法的选择2. Quorum NRW3. Vector clock4. Virtual node5. gossip1. Gossip (State Transfer Model)2. Gossip (Operation Transfer Model)
2、6. Merkle tree7. Paxos1. 背景8. DHT9. Map Reduce Execution10. Handling Deletes11. 存储实现12. 节点变化13. 列存1. 描述2. 特点4. 软件篇1. 亚数据库1. MemCached1. 特点2. 内存分配3. 缓存策略4. 缓存数据库查询5. 数据冗余与故障预防6. Memcached客户端(mc)7. 缓存式的Web应用程序架构8. 性能测试2. dbcached1. Memcached 和 dbcached 在功能上一样吗?2. 列存系列1. Hadoop之Hbase2. 耶鲁大学之HadoopDB3.
3、GreenPlum4. FaceBook之Cassandra1. Cassandra特点2. Keyspace3. Column family(CF)4. Key5. Column6. Super column7. Sorting8. 存储9. API5. Google之BigTable6. Yahoo之PNUTS1. 特点2. PNUTS实现1. Record-level mastering 记录级别主节点2. PNUTS的结构3. Tablets寻址与切分4. Write调用示意图3. PNUTS感悟7. 微软之SQL数据服务3. 非云服务竞争者4. 文档存储1. CouchDB1. 特性
4、2. Riak3. MongoDB4. Terrastore5. ThruDB5. Key Value / Tuple 存储1. Amazon之SimpleDB2. Chordless3. Redis4. Scalaris5. Tokyo cabinet / Tyrant6. CT。M7. Scalien8. Berkley DB9. MemcacheDB10. Mnesia11. LightCloud12. HamsterDB13. Flare6. 最终一致性Key Value存储1. Amazon之Dynamo1. 功能特色2. 架构特色2. BeansDB1. 简介2. 更新3. 特性4
5、. 性能3. Nuclear1. 两个设计上的Tips4. Voldemort5. Dynomite6. Kai7. 未分类1. Skynet2. Drizzle8. 比较1. 可扩展性2. 数据和查询模型3. 持久化设计5. 应用篇1. eBay 架构经验2. 淘宝架构经验3. Flickr架构经验4. Twitter运维经验1. 运维经验1. Metrics2. 配置管理3. Darkmode4. 进程管理5. 硬件2. 代码协同经验1. Review制度2. 部署管理3. 团队沟通3. Cache5. 云计算架构6. 反模式1. 单点失败(Single Point of Failure)
6、2. 同步调用3. 不具备回滚能力4. 不记录日志5. 无切分的数据库6. 无切分的应用7. 将伸缩性依赖于第三方厂商7. OLAP1. OLAP报表产品最大的难点在哪里?8. NOSQL们背后的共有原则1. 假设失效是必然发生的2. 对数据进行分区3. 保存同一数据的多个副本4. 动态伸缩5. 查询支持6. 使用 Map/Reduce 处理汇聚7. 基于磁盘的和内存中的实现8. 仅仅是炒作?6. 附1. 感谢2. 版本志3. 引用序日前国内没有一套比较完整的NoSQL数据库资料,有很多先驱整理发表了很多,但不是很系统。不材尝试着将各家的资料整合一下,并书写了一些自己的见解。本书写了一些目前的
7、NoSql的一些主要技术,算法和思想。同时列举了大量的现有的数据库实例。读完全篇,相信读者会对NoSQL数据库了解个大概.另外我还准备开发一个开源内存数据库galaxydb.本书也是为这个数据库提供一些架构资料。思想篇CAP,BASE和最终一致性是NoSQL数据库存在的三大基石.而五分钟法则是内存数据存储了理论依据。这个是一切的源头.CAP C:Consistency 一致性 A:Availability 可用性(指的是快速获取数据) P: Tolerance of networkPartition 分区容忍性(分布式)10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth
8、Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们,一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。熊掌与鱼不可兼得也。关注的是一致性,那么您就需要处理因为系统不可用而导致的写操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好CAP理论.作为架构师,一般有两个方向来利用CAP理论1. keyvalue存储,如Amaze Dynamo等,可根据CAP三原则灵活
9、选择不同倾向的数据库产品。2. 领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。我准备提供第三种方案:实现可以配置CAP的数据库,动态调配CAP。 CA:传统关系数据库 AP:key-value数据库而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。不同数据对于一致性的要求是不同的.举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一
10、致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。CAP理论的证明:Brewers CAP Theorem最终一致性一言以蔽之:过程松,结果紧,最终结果必须保持一致性为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分: 存储系统存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。 Process AProcessA主要实现从存储系统write和read操作 Process B 和ProcessCProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。下面以
11、上面的场景来描述下不同程度的一致性: 强一致性强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值 弱一致性假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间. 最终一致性最终一致性是弱一致性的一种特例.假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗
12、口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。变体 Causal consistency(因果一致性)如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性. Read-your-writes consistency如果Process A写入了最
13、新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。 Session consistency此种一致性要求客户端和存储系统交互的整个会话阶段保证Readyour-writes consistency。Hibernate的session提供的一致性保证就属于此种一致性. Monotonic read consistency此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。 Monotonic write consistency此种一致性保证系统会序列化执行一个Process中的所有写操作。BASE说起来很有趣,
14、BASE的英文意义是碱,而ACID是酸.真的是水火不容啊。 Basically Availble -基本可用 Softstate -软状态/柔性事务”Soft state” 可以理解为无连接的, 而 Hard state” 是面向连接的 Eventual Consistency 最终一致性最终一致性, 也是是 ACID 的最终目的。BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性: Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步,异步。 Eventu
15、ally consistent最终一致,最终数据是一致的就可以了,而不是时时一致。BASE思想的主要实现有1.按功能划分数据库2.sharding碎片BASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。其他I/O的五分钟法则在 1987 年,Jim Gray与 Gianfranco Putzolu 发表了这个”五分钟法则的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问.这个临界点就是五分钟。 看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入
16、成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个”新的旧硬件”可能带来的影响。随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只
17、不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时).不要删除数据Oren Eini(又名Ayende Rahien)建议开发者尽量避免数据库的软删除操作,读者可能因此认为硬删除是合理的选择。作为对Ayende文章的回应,Udi Dahan强烈建议完全避免数据删除.所谓软删除主张在表中增加一个IsDeleted列以保持数据完整.如果某一行设置了IsDeleted标志列,那么这一行就被认为是已删除的.Ayende觉得这种方法“简单、容易理解、容易实现、容易沟通”,但“往往是错的。问题在于:删除一行或一个实体几乎总不是简单的事件。它不仅影响模
18、型中的数据,还会影响模型的外观.所以我们才要有外键去确保不会出现“订单行”没有对应的父“订单”的情况。而这个例子只能算是最简单的情况。当采用软删除的时候,不管我们是否情愿,都很容易出现数据受损,比如谁都不在意的一个小调整,就可能使“客户”的“最新订单”指向一条已经软删除的订单。如果开发者接到的要求就是从数据库中删除数据,要是不建议用软删除,那就只能硬删除了。为了保证数据一致性,开发者除了删除直接有关的数据行,还应该级联地删除相关数据。可Udi Dahan提醒读者注意,真实的世界并不是级联的:假设市场部决定从商品目录中删除一样商品,那是不是说所有包含了该商品的旧订单都要一并消失?再级联下去,这些
19、订单对应的所有发票是不是也该删除?这么一步步删下去,我们公司的损益报表是不是应该重做了?没天理了。问题似乎出在对“删除”这词的解读上。Dahan给出了这样的例子:我说的“删除”其实是指这产品“停售”了。我们以后不再卖这种产品,清掉库存以后不再进货。以后顾客搜索商品或者翻阅目录的时候不会再看见这种商品,但管仓库的人暂时还得继续管理它们。“删除”是个贪方便的说法。他接着举了一些站在用户角度的正确解读:订单不是被删除的,是被“取消”的。订单取消得太晚,还会产生花费。员工不是被删除的,是被“解雇的(也可能是退休了)。还有相应的补偿金要处理。职位不是被删除的,是被“填补”的(或者招聘申请被撤回)。在上面
20、这些例子中,我们的着眼点应该放在用户希望完成的任务上,而非发生在某个实体身上的技术动作。几乎在所有的情况下,需要考虑的实体总不止一个。为了代替IsDeleted标志,Dahan建议用一个代表相关数据状态的字段:有效、停用、取消、弃置等等.用户可以借助这样一个状态字段回顾过去的数据,作为决策的依据。删除数据除了破坏数据一致性,还有其它负面的后果。Dahan建议把所有数据都留在数据库里:“别删除。就是别删除。”RAM是硬盘,硬盘是磁带Jim Gray在过去40年中对技术发展有过巨大的贡献,“内存是新的硬盘,硬盘是新的磁带”是他的名言.“实时”Web应用不断涌现,达到海量规模的系统越来越多,这种后浪
21、推前浪的发展模式对软硬件又有何影响?Tim Bray早在网格计算成为热门话题之前,就讨论过以RAM和网络为中心的硬件结构的优势,可以用这种硬件建立比磁盘集群速度更快的RAM集群。对于数据的随机访问,内存的速度比硬盘高几个数量级(即使是最高端的磁盘存储系统也只是勉强达到1,000次寻道/秒)。其次, 随着数据中心的网络速度提高,访问内存的成本更进一步降低。通过网络访问另一台机器的内存比访问磁盘成本更低.就在我写下这段话的时候,Sun的 Infiniband产品线中有一款具备9个全互联非阻塞端口交换机,每个端口的速度可以达到30Gbit/sec!Voltaire产品的端口甚至更多;简直不敢想象。(
22、如果你想了解这类超高性能网络的最新进展,请关注Andreas Bechtolsheim在Standford开设的课程.)各种操作的时间,以2001年夏季,典型配置的 1GHz 个人计算机为标准:执行单一指令1 纳秒从L1 高速缓存取一个字2 纳秒从内存取一个字10 纳秒从磁盘取连续存放的一个字200 纳秒磁盘寻址并取字8 毫秒以太网2GB/sTim还指出Jim Gray的名言中后半句所阐述的真理:“对于随机访问,硬盘慢得不可忍受;但如果你把硬盘当成磁带来用,它吞吐连续数据的速率令人震惊;它天生适合用来给以RAM为主的应用做日志(logging and journaling).”时间闪到几年之后
23、的今天,我们发现硬件的发展趋势在RAM和网络领域势头不减,而在硬盘领域则止步不前.Bill McColl提到用于并行计算的海量内存系统已经出现:内存是新的硬盘!硬盘速度提高缓慢,内存芯片容量指数上升,inmemory软件架构有望给各类数据密集的应用带来数量级的性能提升.小型机架服务器(1U、2U)很快就会具备T字节、甚至更大量的内存,这将会改变服务器架构中内存和硬盘之间的平衡.硬盘将成为新的磁带,像磁带一样作为顺序存储介质使用(硬盘的顺序访问相当快速),而不再是随机存储介质(非常慢)。这里面有着大量的机会,新产品的性能有望提高10倍、100倍.Dare Obsanjo指出如果不把这句真言当回事
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- NoSQL 数据库 笔谈
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【天****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【天****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。