nosql数据库比较大全文档格式.docx

nosql数据库比较大全文档格式.docx

《nosql数据库比较大全文档格式.docx》由会员分享，可在线阅读，更多相关《nosql数据库比较大全文档格式.docx（67页珍藏版）》请在冰豆网上搜索。

1.Gossip（StateTransferModel）

2.Gossip（OperationTransferModel）

6.Merkletree

7.Paxos

1.背景

8.DHT

9.MapReduceExecution

10.HandlingDeletes

11.存储实现

12.节点变化

13.列存

1.描述

2.特点

4.软件篇

1.亚数据库

1.MemCached

1.特点

2.内存分配

3.缓存策略

4.缓存数据库查询

5.数据冗余与故障预防

6.Memcached客户端（mc）

7.缓存式的Web应用程序架构

8.性能测试

2.dbcached

1.Memcached和dbcached在功能上一样吗?

2.列存系列

1.Hadoop之Hbase

2.耶鲁大学之HadoopDB

3.GreenPlum

4.FaceBook之Cassandra

1.Cassandra特点

2.Keyspace

3.Columnfamily（CF）

4.Key

5.Column

6.Supercolumn

7.Sorting

8.存储

9.API

5.Google之BigTable

6.Yahoo之PNUTS

2.PNUTS实现

1.Record-levelmastering记录级别主节点

2.PNUTS的结构

3.Tablets寻址与切分

4.Write调用示意图

3.PNUTS感悟

7.微软之SQL数据服务

3.非云服务竞争者

4.文档存储

1.CouchDB

1.特性

2.Riak

3.MongoDB

4.Terrastore

5.ThruDB

5.KeyValue/Tuple存储

1.Amazon之SimpleDB

2.Chordless

3.Redis

4.Scalaris

5.Tokyocabinet/Tyrant

6.CT.M

7.Scalien

8.BerkleyDB

9.MemcacheDB

10.Mnesia

11.LightCloud

12.HamsterDB

13.Flare

6.最终一致性KeyValue存储

1.Amazon之Dynamo

1.功能特色

2.架构特色

2.BeansDB

1.简介

2.更新

3.特性

4.性能

3.Nuclear

1.两个设计上的Tips

4.Voldemort

5.Dynomite

6.Kai

7.未分类

1.Skynet

2.Drizzle

8.比较

1.可扩展性

2.数据和查询模型

3.持久化设计

5.应用篇

1.eBay架构经验

2.淘宝架构经验

3.Flickr架构经验

4.Twitter运维经验

1.运维经验

1.Metrics

2.配置管理

3.Darkmode

4.进程管理

5.硬件

2.代码协同经验

1.Review制度

2.部署管理

3.团队沟通

3.Cache

5.云计算架构

6.反模式

1.单点失败（SinglePointofFailure）

2.同步调用

3.不具备回滚能力

4.不记录日志

5.无切分的数据库

6.无切分的应用

7.将伸缩性依赖于第三方厂商

7.OLAP

1.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:

Toleranceofnetwork 

Partition分区容忍性（分布式）

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

最终一致性

一言以蔽之：

过程松，结果紧，最终结果必须保持一致性

为了更好的描述客户端一致性，我们通过以下的场景来进行，这个场景中包括三个组成部分：

∙存储系统

存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。

∙ProcessA

ProcessA主要实现从存储系统write和read操作

∙ProcessB和ProcessC 

ProcessB和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思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为