NoSQL数据库详细介绍入门经典

NoSQL数据库详细介绍入门经典databases,appdir,node,paper颜开,v0.2,2010.2序思想篇CAP最终一致性变体BASE其他I/O的五分钟法则不要删除数据RAM是硬盘,硬盘是磁带Amdahl定律和Gustafson定律万兆以太网手段篇一致性哈希亚马逊的现状算法的选择QuorumNRWVectorclockVirtualnodegossipGossip(StateTransferModel)Gossip(OperationTransferModel)MerkletreePaxos背景DHTMapReduceExecutionHandlingDeletes存储实现节点变化列存描述特点软件篇亚数据库MemCached特点内存分配缓存策略缓存数据库查询数据冗余与故障预防Memcached客户端（mc）缓存式的Web应用程序架构性能测试dbcachedMemcached和dbcached在功能上一样吗?列存系列Hadoop之Hbase耶鲁大学之HadoopDBGreenPlumFaceBook之CassandraCassandra特点KeyspaceColumnfamily（CF）KeyColumnSupercolumnSorting存储APIGoogle之BigTableYahoo之PNUTS特点PNUTS实现Record-levelmastering记录级别主节点PNUTS的结构Tablets寻址与切分Write调用示意图PNUTS感悟微软之SQL数据服务非云服务竞争者文档存储CouchDB特性RiakMongoDBTerrastoreThruDBKeyValue/Tuple存储Amazon之SimpleDBChordlessRedisScalarisTokyocabinet/TyrantCT.MScalienBerkleyDBMemcacheDBMnesiaLightCloudHamsterDBFlare最终一致性KeyValue存储Amazon之Dynamo功能特色架构特色BeansDB简介更新特性性能Nuclear两个设计上的TipsVoldemortDynomiteKai未分类SkynetDrizzle比较可扩展性数据和查询模型持久化设计应用篇eBay架构经验淘宝架构经验Flickr架构经验Twitter运维经验运维经验Metrics配置管理Darkmode进程管理硬件代码协同经验Review制度部署管理团队沟通Cache云计算架构反模式单点失败（SinglePointofFailure）同步调用不具备回滚能力不记录日志无切分的数据库无切分的应用将伸缩性依赖于第三方厂商OLAPOLAP报表产品最大的难点在哪里？NOSQL们背后的共有原则假设失效是必然发生的对数据进行分区保存同一数据的多个副本动态伸缩查询支持使用Map/Reduce处理汇聚基于磁盘的和内存中的实现仅仅是炒作?附感谢版本志引用序日前国内没有一套比较完整的NoSQL数据库资料，有很多先驱整理发表了很多，但不是很系统。不材尝试着将各家的资料整合一下，并书写了一些自己的见解。本书写了一些目前的NoSql的一些主要技术，算法和思想。同时列举了大量的现有的数据库实例。读完全篇，相信读者会对NoSQL数据库了解个大概。另外我还准备开发一个开源内存数据库galaxydb.本书也是为这个数据库提供一些架构资料。思想篇CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储了理论依据。这个是一切的源头。CAPC:Consistency一致性A:Availability可用性(指的是快速获取数据)P:ToleranceofnetworkPartition分区容忍性(分布式)10年前，EricBrewer教授指出了著名的CAP理论，后来SethGilbert和Nancylynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。作为架构师，一般有两个方向来利用CAP理论key-value存储，如AmazeDynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。领域模型+分布式缓存+存储（Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。我准备提供第三种方案：实现可以配置CAP的数据库，动态调配CAP。CA：传统关系数据库AP：key-value数据库而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着A、P的方向设计，然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过10秒的价格不一致。CAP理论的证明：Brewer'sCAPTheorem最终一致性一言以蔽之：过程松，结果紧，最终结果必须保持一致性为了更好的描述客户端一致性，我们通过以下的场景来进行，这个场景中包括三个组成部分：存储系统存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。ProcessAProcessA主要实现从存储系统write和read操作ProcessB和ProcessCProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。下面以上面的场景来描述下不同程度的一致性：强一致性强一致性（即时一致性）假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值弱一致性假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。最终一致性最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为master/salve模式中，salve的个数），最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都会看到最新的值。变体Causalconsistency（因果一致性）如果ProcessA通知ProcessB它已经更新了数据，那么ProcessB的后续读取操作则读取A写入的最新值，而与A没有因果关系的C则可以最终一致性。Read-your-writesconsistency如果ProcessA写入了最新的值，那么ProcessA的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。Sessionconsistency此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writesconsistency.Hibernate的session提供的一致性保证就属于此种一致性。Monotonicreadconsistency此种一致性要求如果ProcessA已经读取了对象的某个值，那么后续操作将不会读取到更早的值。Monotonicwriteconsistency此种一致性保证系统会序列化执行一个Process中的所有写操作。BASE说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。BasicallyAvailble--基本可用Soft-state--软状态/柔性事务Softstate可以理解为无连接的,而Hardstate是面向连接的EventualConsistency--最终一致性最终一致性，也是是ACID的最终目的。BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：BasicallyAvailable基本可用。支持分区失败(e.g.sharding碎片划分数据库)Softstate软状态状态可以有一段时间不同步，异步。Eventuallyconsistent最终一致，最终数据是一致的就可以了，而不是时时一致。BASE思想的主要实现有1.按功能划分数据库2.sharding碎片BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。其他I/O的五分钟法则在1987年，JimGray与GianfrancoPutzolu发表了这个五分钟法则的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持1KB的数据成本相当于硬盘中存据400秒的开销(接近五分钟)。这个法则在1997年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对SSD这个新的旧硬件可能带来的影响。随着闪存时代的来临，五分钟法则一分为二：是把SSD当成较慢的内存（extendedbufferpool）使用还是当成较快的硬盘（extendeddisk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的20年之后，在闪存时代，5分钟法则依然有效，只不过适合更大的内存页(适合64KB的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。不要删除数据OrenEini（又名AyendeRahien）建议开发者尽量避免数据库的软删除操作，读者可能因此认为硬删除是合理的选择。作为对Ayende文章的回应，UdiDahan强烈建议完全避免数据删除。所谓软删除主张在表中增加一个IsDeleted列以保持数据完整。如果某一行设置了IsDeleted标志列，那么这一行就被认为是已删除的。Ayende觉得这种方法“简单、容易理解、容易实现、容易沟通”，但“往往是错的”。问题在于：删除一行或一个实体几乎总不是简单的事件。它不仅影响模型中的数据，还会影响模型的外观。所以我们才要有外键去确保不会出现“订单行”没有对应的父“订单”的情况。而这个例子只能算是最简单的情况。……当采用软删除的时候，不管我们是否情愿，都很容易出现数据受损，比如谁都不在意的一个小调整，就可能使“客户”的“最新订单”指向一条已经软删除的订单。如果开发者接到的要求就是从数据库中删除数据，要是不建议用软删除，那就只能硬删除了。为了保证数据一致性，开发者除了删除直接有关的数据行，还应该级联地删除相关数据。可UdiDahan提醒读者注意，真实的世界并不是级联的：假设市场部决定从商品目录中删除一样商品，那是不是说所有包含了该商品的旧订单都要一并消失？再级联下去，这些订单对应的所有发票是不是也该删除？这么一步步删下去，我们公司的损益报表是不是应该重做了？没天理了。问题似乎出在对“删除”这词的解读上。Dahan给出了这样的例子：我说的“删除”其实是指这产品“停售”了。我们以后不再卖这种产品，清掉库存以后不再进货。以后顾客搜索商品或者翻阅目录的时候不会再看见这种商品，但管仓库的人暂时还得继续管理它们。“删除”是个贪方便的说法。他接着举了一些站在用户角度的正确