Downloaded 58 times
Uploaded byTony Deng
No sql数据库杂谈—理论篇
本文件探讨了NoSQL数据库的概念、理论基础、分类及其与传统关系型数据库的比较。NoSQL数据库提供了非关系型的数据存储解决方案，旨在解决关系型数据库在扩展性和可用性方面的不足，同时强调了一致性和可用性之间的取舍。文件还介绍了CAP理论、BASE模型及具体的数据库类型，如键值存储、文档存储和列存储。
![[译]No sql生态系统](https://cdn.slidesharecdn.com/ss_thumbnails/nosql-110624114358-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
No sql数据库杂谈—理论篇
- 1.
- 2. • NoSQL概念介绍 • NoSQL的理论基础 •为什么要用NoSQL数据库 • NoSQL数据库分类
- 3.
- 4. 什么是NoSQL • 一般的解释 – Notonly SQL,不限于SQL，是一类范围非常广泛的数据持久化解决方案，它 们不遵循关系数据库模型，也不使用SQL作为查询语言。 • 更加正确的解释 – NoREL -- http://en.wikipedia.org/wiki/Nosql – NoSQL的重点是non-relational，而传统的数据库是relational • 1998年开始的一个由Carlo Strozzi发起的一项运动，这项运动的主 旨就是“要找到存储和检索数据的其他高效的途径，而不是盲目地在 任何情况下都把关系数据库当作万金油” • 非关系型数据库我们基本上都认为它是NoSQL数据库。 • http://nosql-database.org/
- 5.
- 6. 传统关系型数据库的缺陷 • 最大的缺陷就是扩展性 – 虽然各个数据库厂商都有cluster的解决方案，但是不管share storage或sharenothing的解决方案，扩展性都是很有限的。 • 目前解决数据库扩展性的思路主要有两个 – 水平分区（数据分片 sharing）或垂直分区（功能业务分区） • 这样虽然可以很好解决数据库的扩展性问题，但是在实际使用中，一旦 采用了数据分片或者功能分区，必然导致牺牲“关系型”数据库的最大 优势-join，对业务的局限性会很大，而且数据库也退化成为一个简单的 存储系统。 – Master-Slave复制方式 • 通过读写分离在某种程度上解决扩展性的问题，但是这种方案中，由于 每个数据库节点必须保存所有的数据，这样每个存储的IO必然会成为扩 展的瓶颈，并且master也是一个瓶颈 • 总的来说，传统的关系型数据库的扩展能力都是十分有限 的。
- 7. NoSQL是否会取代关系型数据库 • 应用场景 – 其实，NoSQL的数据库使用场景比较特殊 –NoSQL无法做到通用 – NoSQL对于很多人来说是此之蜜糖，彼之砒霜 • 使用习惯 – 更多的技术人员更习惯使用关系型数据库 – 关系型数据库也能够伪装成非关系型数据库
- 8.
- 9.
- 10. CAP C: Consistency 一致性： 任何一个读操作总是能够读取之前完成的写操作 A:Availability 可用性(指的是快速获取数据) 每一次操作总是能够在确定的时间返回 P: Tolerance of network Partition 分区容忍性(分布式) 在出现网络分区的情况下，仍然能够满足一致性和可用性。
- 11. 取舍 • 10年前，Eric Brewer教授指出了著名的CAP理论，后来SethGilbert 和 Nancy lynch两人证明了CAP理论 的正确性。 • CAP理论告诉我们:一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满 足两个。 • 熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况， 而如果您关注的是可用性，那么您应该知道系统的read操 作可能不能精确的读取到write操作写入的最新 值。 • 因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用 好 CAP理论。 – CA：传统关系数据库 – AP：key-value数据库 • 而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后 通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式 系统，而是应该进行取舍。 • 不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间 的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过 10秒的价格不一致。 • CAP理论的证明：Brewer‘s CAP Theorem
- 12. 一致性 • 强一致性 – ACID –在单机环境中，强一致性可以由数据库的事务来保证。 – 在多机环境中，强一致性很难做到。 • 分布式事务：性能太差，在互联网的应用中不适合 • 弱一致性（包括最终一致性） – 通过提交处理的半同步、半异步或全异步，取得最终一致性效果。 – 最终一致性使得数据的提交具有延时性，而在一定范围的延时性范围内（比 如一秒），应用的可用性是OK的 • 一言以蔽之：过程松，结果紧，最终结果必须保证一致性 • http://www.allthingsdistributed.com/2008/12/eventually_consi stent.html
- 13. 一致性的场景描述 • 为了更好的描述客户端一致性，我们通过以下的 场景来进行，这个场景包括三个组成部分： – 存储系统 •存储系统可以理解为一个黑盒子，它为我们提供了可用性和持 久性的保证 – ProcessA • ProcessA主要实现从存储系统write和read操作 – ProcessB和ProcessC • ProcessB和C是独立于A，并且B和C也相互独立，它们同时也 实现对存储系统的write和read操作
- 14. 不同程度的一致性处理方式 • 强一致性 – 强一致性（即时一致性）假如A先写入一个值到存储系统，存储系统保证后续的A,B,C的 读操作都返回最新值 •弱一致性 – 假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能够读到最 新值。 – 这种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取 到最新值这一段时间。 • 最终一致性 – 最终一致性是弱一致性的一种特例 – 假如A首先write了一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其 他写操作更新同样的值的话，最终所有的读取操作都会读取到A写入的最新的值。 – 这种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖以下的几个因素： • 交互延迟 • 系统的负载 • 复制架构中replica的个数（可以理解为master/slave模式中，slave的个数） • 在最终一致性方面最出名的应该是DNS系统 – 但更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都 可以看到最新的域名和IP的映射
- 15. 其他一致性变体的处理方式 • Causal consistency(因果一致性) –如果Process A通知Process B它已经更新了数据，那么Process B的后续读取 操作则读取A写入的最新值，而与A没有因果关系的C则可以最终一致性。 • Read-your-writes consistency(过程一致性) – 如果Process A写入了最新的值，那么Process A的后续操作都会读取到最新 值。但是其它用户可能要过一会才可以看到。 • Session consistency(会话一致性) – 此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your- writes consistency – Hibernate的session提供的一致性保证就属于此种一致性。 • Monotonic read consistency(简单读一致性) – 此种一致性要求如果Process A已经读取了对象的某个值，那么后续操作将不 会读取到更早的值。 • Monotonic write consistency(简单写一致性) – 此种一致性保证系统会序列化执行一个Process中的所有写操作。
- 16. 服务器一致性 • 概念 – N：节点的个数 –W：更新的时候需要确认已经被更新的节点个数 – R：读数据的时候读取数据的节点个数 • 如果W+R>N，那么分布式系统就会提供强一致性的保证，因为读取数据节 点和被写入的节点是有重叠的。 • 在一个RDBMS的复制模型中(Master/Slave)，假如N=2，那么W=2，R=1， 此时是一种强一致性，但是这样造成的问题就是可用性的减低，因为要想写 操作成功，必须要等2个节点都完成以后才可以。 • 在分布式系统中，一般都要有容错性，因此一般N都大于3的，此时根据CAP 理论，一致性，可用性和分区容错性最多只能满足两个，那么我们就需要在 一致性和分区容错性之间做一个平衡。 – 如果要高的一致性，那么就配置为N=W，R=1，这个时候可用性就会大大降低 – 如果想要高的可用性，那么此时就需要放松一致性的要求，此时可以配置W=1，这样 使得写操作延迟最低，同时通过异步的机制剩余的N-W个节点
- 17. 服务器一致性 • 当存储系统保证最终一致性时，存储系统的配置一般是 W+R<=N，此时读取和写入操作是不重叠的。 • 不一致窗口就依赖存储系统的异步实现方式，不一致窗口 大小也就等于从更新开始到所有节点都异步更新完成之间 的时间 •N,R,W的例子 – (N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性 – W = 1, R = N,对写操作要求高性能高可用。 – R = 1, W = N , 对读操作要求高性能高可用，比如类似cache之 类业务。 – W = Q, R = Q where Q = N / 2 + 1 一般应用适用，读写性能之 间取得平衡。如N=3,W=2,R=2
- 18. BASE • BASE（Basically Available,Softstate,Eventually consistent）是对 CAP中的AP的衍生 – 在单机环境中，ACID是数据的属性 – 而在分布式环境中，BASE就是数据的属性 • BASE模型完全不同于ACID模型，它通过牺牲高一致性，获得可用性 和可靠性（容错性） • BASE思想主要实现有 – 按功能划分数据库 – Sharing • BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯 粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案 在性能上还是有潜力可挖的。
- 19. 五分钟法则 • http://queue.acm.org/detail.cfm?id=1413264 • http://developers.solidot.org/article.pl?sid=09/07/06/052 210 •1987年发表的这个“五分钟法则” – 评估了在内存中保留数据和在硬盘上储存数据之间的利益权衡：如果 数据被频繁访问，那么它应该放在内存里；否则就储存在硬盘内，其 临界点便是五分钟——在内存中保持1KB的数据成本相当于硬盘中存 储同样大小数据400秒的开销 • 随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较 慢的内存（extended buffer pool ）使用还是当成较快的硬盘 （extended disk）使用。小内存页在内存和闪存之间的移动 对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出 的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适 合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现 了计算机硬件工艺的发展，以及带宽、延时)。
- 20.
- 21.
- 22. NoSQL数据库分类 • 一般来说，基本上分为以下几种： – Key/ValueStores （键/值存储库） • Amazon SimpleDB – http://aws.amazon.com/simpledb/ • Berkeley DB – http://www.oracle.com/database/berkeley-db/db/index.html • MemcacheDB – http://memcachedb.org/ • Redis – http://code.google.com/p/redis/ – Document Stores （文档库） • CouchDB – http://couchdb.apache.org/ • MongoDB – http://www.mongodb.org/ – Graph Database （图形数据库） • Neo4j – http://www.neo4j.org/ – Wide Column Stores （列存储库） • Hadoop – http://hadoop.apache.org/ • Cassandra – http://incubator.apache.org/cassandra/
- 23.
- 24. 接口层（Interfaces） • 这层的主要作用是为上层应用提供合适和方便的数据调用 接口，而且提供的选择远多于传统的关系型数据库，主要 有六大类接口： – 其一是常见的REST（Representational State Transfer），采用 REST的产品有HBase和CouchDB等。 – 其二是源自Facebook的RPC协议Thrift，支持Thrift的产品 有 HBase和Cassandra等。 – 其三是用于大规模数据处理的Map Reduce，其相关产品有 HBase，CouchDB和MongoDB等。 – 其四是类似于Memcached的Get/Put方式，采用Get/Put的 产品 有Voldemort等。 – 其五是提供语言特定（Language Specific）的API，比如Java， 在这方面做的不错是MongoDB。 – 最后一个是提供SQL的子集，虽然“Join”在NoSQL属于禁忌， 但 是提供一个SQL的基本子集来方便用户也是一个不错的想法。
- 25. 数据逻辑模型层（Logical Data Model） •这层的主要作用是描述数据的逻辑表现形式，而且与关系型数 据库相比NoSQL在逻辑表现形式方面相当灵活，主要有四种形 式： – 最普通的Key- Value形式，这种形式在表现形式是比较单一，但是 在扩展方面很有优势，采用Key-Value形式产品的有Voldemort等。 – 列式 （Column Family），这种形式与Key-Value相比其能支持更 复杂的数据，但是在扩展方面稍逊一筹，其相关产品有BigTable， HBase和 Cassnadra等。 – 文档（Doucument）形式，文档形式源自于著名协作软件Lotus Notes，并且本质上与Key-Value形式非常相似，主要区别在于是那 个Value只能存储文档形式的数据，同时文档形式在对复杂数据的支 持和扩展 这两方面表现都还可以，采用文档形式的产品有Couch DB 和MongoDB等。 – 图（Graph）式，图式的使用场景不是很广，主要是为基于图数据结 构的数据“度身定做”的，比如SNS应用中的关系等，其最知名的产 品就是 Neo4j。
- 26. 数据分布层（Data Distribution Model） •这层的主要作用是定义了数据是如何分布的，和 关系型数据库不同的是NoSQL数据库可选择的机 制比较多，主要有三种： – 其一是用于水平扩展的CAP机制，支 持CAP的产品有 HBase，MongoDB和Cassandra等。 – 其二是对多数据中心的支持，通过这个机制能够保证 横跨多数据中心的NoSQL数据库 能非常平稳地运行， 相关的产品有Cassandra等。 – 其三是支持动态部署，也就是能在一个生产集群中能 动态并且平滑地添加或者删去一个节点
- 27. 数据持久层（Data Persistence） • 这层主要作用是定义了数据的存储形式，主要有四种 形式： –基于内存形式，这种形式速度最快，但是存在丢失数据的可 能性，采 用内存的有Redis等。 – 基于硬盘形式，这种形式，在数据耐久性方面表现不错，但 是在速度方面远不如基于内存的，其相关产品有MongoDB 等。 – 基于 内存和硬盘的形式，因为这种形式主要结合前面两者 的优点，所以其在速度上表现不错，同时数据也不会丢失， 而且常被认为是最合适的方案，采用这种形式的产品 有 HBase和Cassandra等。 – 定制可插拔（Custom Pluggable）形式，这种形式以灵活 著称
- 28.
- 29.