NoSQL数据库-CAP-BASE-最终一致性.ppt

NoSQL数据库CAP/BASE/最终一致性 NoSQL概念介绍 NoSQL的理论基础 为什么要用NoSQL数据库 NoSQL数据库分类 NoSQL概念介绍 什么是NoSQL 一般的解释 Not only SQL,不限于SQL，是一类范围非常广泛的数据持久化解决方案，它们不遵循关系数据库模型，也不使用SQL作为查询语言。 更加正确的解释 NoREL -- /wiki/Nosql NoSQL的重点是non-relational，而传统的数据库是relational 1998年开始的一个由Carlo Strozzi发起的一项运动，这项运动的主旨就是“要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油” 非关系型数据库我们基本上都认为它是NoSQL数据库。 / 为什么要用NoSQL数据库 传统关系型数据库的缺陷 最大的缺陷就是扩展性 虽然各个数据库厂商都有cluster的解决方案，但是不管share storage或share nothing的解决方案，扩展性都是很有限的。 目前解决数据库扩展性的思路主要有两个 水平分区（数据分片 sharing）或垂直分区（功能业务分区） 这样虽然可以很好解决数据库的扩展性问题，但是在实际使用中，一旦采用了数据分片或者功能分区，必然导致牺牲“关系型”数据库的最大优势-join，对业务的局限性会很大，而且数据库也退化成为一个简单的存储系统。 Master-Slave复制方式 通过读写分离在某种程度上解决扩展性的问题，但是这种方案中，由于每个数据库节点必须保存所有的数据，这样每个存储的IO必然会成为扩展的瓶颈，并且master也是一个瓶颈 总的来说，传统的关系型数据库的扩展能力都是十分有限的。 NoSQL是否会取代关系型数据库 应用场景 其实，NoSQL的数据库使用场景比较特殊 NoSQL无法做到通用 NoSQL对于很多人来说是此之蜜糖，彼之砒霜 使用习惯 更多的技术人员更习惯使用关系型数据库 关系型数据库也能够伪装成非关系型数据库 NoSQL理论基础 一切的源头 CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。 而五分钟法则是内存数据存储了理论依据。这个是一切的源头。 CAP C: Consistency 一致性： 任何一个读操作总是能够读取之前完成的写操作 A: Availability 可用性(指的是快速获取数据) 每一次操作总是能够在确定的时间返回 P: Tolerance of network Partition 分区容忍性(分布式) 在出现网络分区的情况下，仍然能够满足一致性和可用性。 取舍 10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。 CAP理论告诉我们:一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。 熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操 作可能不能精确的读取到write操作写入的必威体育精装版值。 因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好 CAP理论。 CA：传统关系数据库 AP：key-value数据库 而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。 不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过10秒的价格不一致。 CAP理论的证明：Brewer‘s CAP Theorem 一致性 强一致性 ACID 在单机环境中，强一致性可以由数据库的事务来保证。 在多机环境中，强一致性很难做到。 分布式事务：性能太差，在互联网的应用中不适合 弱一致性（包括最终一致性） 通过提交处理的半同步、半异步或全异步，取得最终一致性效果。 最终一致性使得数据的提交具有延时性，而在一定范围的延时性范围内（比如一秒），应用的可用性是OK的 一言以蔽之：过程松，结果紧，最终结果必须保证一致性 /2008/12/eventually_consistent.html 一致性的场景描述 为了更好的描述客户端一致性，我们通过以下的场景来进行，这个场景包括三个组成部分： 存储系统 存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证 Proce