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.QuorumNRW3.Vectorclock4.Virtualnode5.gossip1.Gossip(StateTransferModel)2.Gossip(OperationTransferModel)6.Merkletree7.Paxos1.背景8.DHT9.MapReduceExecution10.HandlingDeletes11.存储实现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.GreenPlum4.FaceBook之Cassandra1.Cassandra特点2.Keyspace3.Columnfamily（CF）4.Key5.Column6.Supercolumn7.Sorting8.存储9.API5.Google之BigTable6.Yahoo之PNUTS1.特点2.PNUTS实现1.Record-levelmastering记录级别主节点2.PNUTS的结构3.Tablets寻址与切分4.Write调用示意图3.PNUTS感悟7.微软之SQL数据服务3.非云服务竞争者4.文档存储1.CouchDB1.特性2.Riak3.MongoDB4.Terrastore5.ThruDB5.KeyValue/Tuple存储1.Amazon之SimpleDB2.Chordless3.Redis4.Scalaris5.Tokyocabinet/Tyrant6.CT.M7.Scalien8.BerkleyDB9.MemcacheDB10.Mnesia11.LightCloud12.HamsterDB13.Flare6.最终一致性KeyValue存储1.Amazon之Dynamo1.功能特色2.架构特色2.BeansDB1.简介2.更新3.特性4.性能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.单点失败（SinglePointofFailure）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数据库资料，有很多先驱整理发表了很多，但不是很系统。不材尝试着将各家的资料整合一下，并书写了一些自己的见解。本书写了一些目前的NoSql的一些主要技术，算法和思想。同时列举了大量的现有的数据库实例。读完全篇，相信读者会对NoSQL数据库了解个大概。另外我还准备开发一个开源内存数据库galaxydb.本书也是为这个数据库提供一些架构资料。思想篇CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储了理论依据。这个是一切的源头。CAPC:Consistency一致性A:Availability可用性(指的是快速获取数据)P:ToleranceofnetworkPartition分区容忍性(分布式)10年前，EricBrewer教授指出了著名的CAP理论，后来SethGilbert和Nancylynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。作为架构师，一般有两个方向来利用CAP理论1.key-value存储，如AmazeDynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。2.领域模型+分布式缓存+存储（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觉得这种方法“简单、容易理解、容易实现、容易沟通”，但“往往是错的”。问题在于：删除一行或一个实体几乎总不是简单的事件。它不仅影响模型中的数据，还会影响模型的外观。所以我们才要有外键去确保不会出现“订单行”没有对应的父“订单”的情况。而这个例子只能算是最简单的情况。……当采用软删除的时候，不管我们是否情愿，都很容易出现数据受损，比如谁都不在意的一个小调整，就可能使“客户”的“最新订单”指向一条已经软删除的订单。如果开发者接到的要求就是从数据库中删除数据，要是不建议用软删除，那就只能硬删除了