目录
CAP定理
分布式数据库的局限性可以用所谓的 CAP 定理来描述
- Consistency 一致性：每个节点在任何给定实例上总是看到相同的数据（即严格一致性）
- Availability可用性：系统继续运行，即使节点崩溃，或某些硬件或软件部件因升级而停机
- Partition Tolerance 分区容忍度：系统在存在网络分区的情况下继续运行
CAP 定理：任何具有共享数据的分布式数据库，最多可以拥有三个理想属性中的两个，C、A 或 P
让我们假设网络分区两侧的两个节点：
- 可用性 + 分区容丧失一致性，因为当系统被分区时，就地更改无法传播。
- 一致性 + 分区容错性意味着分区的一侧必须表现得好像它不可用，从而丧失可用性
- 只有在没有网络分区的情况下才能实现一致性 + 可用性，从而丧失分区容错性
大型数据库
当谷歌和亚马逊等公司设计大型数据库时，24/7 可用性是关键
- 几分钟的停机时间意味着收入损失
数据库在 1000 台机器中，节点或网络故障的可能性大大增加
因此，为了对 Availability 和 Partition Tolerance 有很强的保证，他们不得不牺牲“严格”一致性（CAP 定理所暗示的）
一致性类型
• 强一致性
– 更新完成后，任何后续访问都将返回相同的更新值。
• 弱一致性
– 不保证后续访问将返回更新后的值。
• 最终一致性
– 弱一致性的具体形式
– 保证如果没有对对象进行新的更新，最终所有访问都将返回最后更新的值（例如，以惰性方式将更新传播到副本）
最终一致性变化
• 因果一致性
– 具有因果关系的过程将看到一致的数据
• 读写一致性
– 进程总是在更新操作后访问数据项并且永远不会看到旧值
• 会话一致性
– 只要会话存在，系统就保证读写一致性
– 保证不重叠会话
• 单调读取一致性
– 如果进程看到了数据项的特定值，任何后续进程将永远不会返回任何先前的值
• 单调写入一致性
– 系统保证通过同一进程序列化写入
• 在实践中
– 许多这些属性可以组合
– 单调阅读和读写一致性是最可取的
异质性：分割 C 和 A
• 没有单一的统一要求
– 某些方面需要强一致性
– 其他需要高可用性
• 将系统分割成不同的组件
– 每个提供不同类型的保证
• 总体上既不保证一致性也不保证可用性
– 服务的每个部分都得到它所需要的
• 可沿不同维度进行分区
分区示例
数据分区
• 不同的数据可能需要不同的一致性和可用性
• 例子：
• 购物车：高可用性、响应迅速，有时会出现异常
• 产品信息需要可用性，库存略有变化是可以承受的
• 结帐、计费、运输记录必须一致
如果没有分区怎么办？
• 一致性和延迟之间的权衡：
• 由分布式系统出现故障的可能性引起
– 高可用 -> 复制数据 -> 一致性问题
• 基本理念：
– 可用性和延迟可以说是一回事：不可用 -> 极高的延迟
– 实现不同级别的一致性/可用性需要不同的时间
权衡一致性
保持一致性应该在严格的一致性与可用性/可扩展性之间取得平衡
--足够好的一致性取决于应用
宽松的一致性：更容易实施，效率更高
严格的一致性：一般难以实施，效率低下
BASE基础属性
CAP定理证明在能够容忍网络分区的同时保证严格的一致性和可用性是不可能的
这导致数据库具有宽松的 ACID 保证
特别是，此类数据库应用 BASE 属性：
- Basically Available基本可用：系统保证可用
- Soft-State软状态：系统状态可能会随时间变化
- Eventual Consistency最终一致性：系统最终会变得一致
CAP -> PACELC
• 对分布式系统潜在权衡空间的更完整描述：
– 如果有分区（P），系统如何权衡可用性和一致性（A和C）；否则else (E)，当系统在没有分区的情况下正常运行时，系统如何权衡延迟（L）和一致性（C）？
例子
• PA/EL 系统：为了可用性和更低的延迟而放弃两个 C
• PC/EC 系统：拒绝放弃一致性并为可用性和延迟付出代价
– BigTable, Hbase, VoltDB/H-Store
• PA/EC 系统：发生分区时放弃一致性并在正常操作中保持一致性
– MongoDB
• PC/EL 系统：发生分区时保持一致性，但在正常操作中因延迟而放弃一致性
NoSQL 数据库的类型
以下是 NoSQL 数据库的有限分类法：
- 文件存储
- 图数据库
- 键值存储
- 列式数据库
文件存储
文档以某种标准格式或编码存储（例如，XML、JSON、PDF 或 Office 文档）
--这些通常称为二进制大对象 (BLOB)
文档可以被索引
--这允许文档存储优于传统文件系统
例如，MongoDB 和 CouchDB（都可以使用 MapReduce 查询）
图数据库
数据表示为顶点和边
图数据库对于类似图的查询非常强大（例如，找到两个元素之间的最短路径）
例如， Neo4j and VertexDB
键值存储
键被映射到（可能）更复杂的值（例如，列表）
键可以存储在哈希表中，并且可以轻松分发
此类存储通常支持常规 CRUD（创建、读取、更新和删除）操作
--也就是说，没有连接和聚合函数
例如， Amazon DynamoDB and Apache Cassandra
列式数据库
列式数据库是 RDBMS 和键值存储的混合体
-- 值存储在零个或多个列的组中，但按列顺序（与行顺序相反）
-- 通过匹配键查询值
例如，HBase and Vertica
概括
CAP 定理指出，任何具有共享数据的分布式数据库最多可以具有以下三个理想属性中的两个：
-- 一致性
-- 可用性
--分区容错
CAP 定理导致了各种具有宽松 ACID 保证的数据库设计
NoSQL（或 Not-Only-SQL）数据库遵循 BASE 属性：
--Basically Available 基本可用
--Soft-State 软状态
--Eventual Consistency 最终一致性
好嘞，今天关于CAP就到这里拉，感谢大家观看！有问题随时评论区交流哦，也欢迎大家关注哦，后面也会在其他版块持续更新！敬请关注。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
