云存储技术博客：光头老蒋

为什么要用Cassandra

• MySQL使用太多随机I / O的
• 基于文件的解决方案需要有太多的锁

面对海量数据优势

• 扩展性，无边界
• 在线负载平衡，集群技术
• 灵活的架构
• 以KEY为导向的查询
• CAP理论

CAP定理

CAP定理（ 布鲁尔 ）规定，你必须挑选两个 一致性 ， 可用性 ， 分割容忍度 ：(Consistency, Availability, Partition tolerance) 你不能同时有3个，并得到一个可接受的延迟。

Cassandra选择Availability, Partition tolerance（AP ）。注：Hbase倾向于Consistency，Partition tolerance（ 处长 ）

历史和方法

两个著名的论文

• Bigtable的：一种结构化数据的分布式存储系统，2006
• dynamo：亚马逊的高度可用KeyValue的存储系统，2007年

两种方法

• Bigtable的："我们怎样才能建立在GFS上一个分布式数据库？"
• 发电机："我们如何能够建立一个合适于的数据中心的分布式哈希表数据库？"

Cassandra海量存储总结

• Dynamo分区和复制方法
• 日志结构ColumnFamily类似Bigtable的数据模型的

Cassandra亮点

• 高可用性
• 增量可伸缩性
• 最终一致
• 一致性和延迟性的可调节
• 最小化的管理
• 没有单点故障（SPF）

P2P分发模型 - 模型驱动的一致性 - 意味着没有单点故障。

KEYS分布和分区

Dynamo结构和查找方式

在一个G环的节点A，B，C，D及E，F和 节点B，C和范围Ð存储密钥（ 一 ， b ）包括关键 K表

你可以决定在哪里去的关键应该Dynamo在使用 IntitialToken 你的参数为 分区程序

结构细节

• 为O（1）节点查询
• 明确复制
• 最后一致

架构层

写入

任何节点分区程序Commitlog，memtable SSTable等待的W回应

写模式：

有两种写模式：

• 法定人数写 ：阻塞，直到达到法定人数
• 异步写 ：发送请求给任何节点。 该节点将数据推送到适当的节点，但立即返回到客户端

如果节点已关闭，然后写另一个一种说法在何处，应书面暗示节点。 Harvester经过每15分钟提示，找到并移动到适当的节点数据

写路径

在写的时候，

• 你先写一个 磁盘提交日志 （连续）
• 写入日志后它发送到相应的节点
• 每个节点接收本地日志写在第一个记录它，然后作出适当的更新 memtables （每个家庭一列）。 Memtable是Cassandra的内存中对代表的键/值之前，数据被刷新到磁盘SSTable为。
• Memtables 被刷新到磁盘时：
  • 空间不足
  • 太多key （128是默认值）
  • 到默认时间（客户提供 - 没有群集时钟）
• 当memtables写出两个文件时生成：
  • 数据文件（ SSTable ）。 SSTable（术语借用谷歌）代表字符串排序表和密钥文件是一个键/值排序，串对。
  • 索引文件（ SSTable Index ）。 （类似Hadoop的映射文件/ Tfile）
    • （Key, offset）对应相关数据
• Bloom filter （数据文件中的所有key）。Bloom filter ，是一种节省空间的概率数据结构，是用来测试一个元素是否是一个集成员的。
• 当一个提交日志已全部column families推到它的磁盘，它将被删除
• Compaction ：随着时间的推移积累的数据文件。 定期数据文件合并成一个新的文件排序（并创建新的索引）
  • Merge keys
  • Combine columns
  • Discard tombstones

写属性

• 无读
• 无查询
• 快速
• 原子内ColumnFamily
• 保持能写状态

删除

删除标记（tombstone）必要的抑制过期的SSTables数据，直到压实阅读修理复杂的事情有点最终一致的事情变得更加复杂化解决方案：

读

读路径

• 任何节点
• 分区程序
• 等待答复的R
• 等待中N - 背景ř响应和执行读取修复

卡桑德拉读取属性

• 读取多个SSTables
• 慢于写（但仍快）
• 可以寻求更多的RAM得以缓解
• 行扩展到数十亿

一致性

一致性描述系统如何以及是否是在操作后一致的状态。 在像分布式数据系统，这通常意味着，一旦一个系统写了，所有的客户会看到写。

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

• N — 数据复制的份数
• W — 更新数据是需要保证写完成的节点数
• R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

• 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
• 如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突