sstable, bigtable,leveldb,cassandra,hbase的lsm基础

先看懂文献1和2

1. 先了解sstable.SSTable: Sorted String Table

[2] [10]

WiscKey:  类似myisam, key value分离, 根据ssd优化,降低io放大.

2. 再了解Compaction

三种 from 太阁技术秀：一起聊聊cassandra

1）SizeTieredCompactionStrategy (STCS)：每四个数据块压一块，对于insert多的系统好。

2）LeveledCompactionStrategy(LCS)：对于update多的系统好 .When to Use Leveled Compaction

3）DataTieredCompactionStrategy (DTCS)：根据时间进行compaction

3. Bloomfilter 布隆过滤器

大数据下的判断逻辑,类似hashSet, 但是 1. 不保存原value,节省空间; 2.多个hash算法共同使用 . 允许少量错误率. 用bit来作为桶[11],

[12]文献中含有 推导公式 . 利用于缓存穿透. [ 不存在的有业务含义 ] 还有一种做法是增加一个标记位, 不用 null 表征.

a、Bloom filter: 就是个带随即概率的bitmap,可以快速的告诉你，某一个小的有序结构里有没有指定的那个数据的。于是就可以不用二分查找，而只需简单的计算几次就能知道数据是否在某个小集合里啦。效率得到了提升，但付出的是空间代价。

即使 布隆过滤器告知有,但是查了没有也没有关系,继续到磁盘上查找. 允许少量的判断出错.

4. memtable

LevelDb的Memtable类只是一个接口类，真正的操作是通过背后的SkipList来做的，包括插入操作和读取操作等，所以Memtable的核心数据结构是一个SkipList [2]

读数据时分别读Memtable和SStable的数据合并后返回。

     如果更新的key不在memtable怎么办?

        而作为称职的存储工具，常见的调用接口无非是新增KV，删除KV，读取KV，更新Key对应的Value值这么几种操作。LevelDb的接口没有直接支持更新操作的接口，如果需要更新某个Key的Value,你可以选择直接生猛地插入新的KV，保持Key相同，这样系统内的key对应的value就会被更新；或者你可以先删除旧的KV， 之后再插入新的KV，这样比较委婉地完成KV的更新操作。[2]

由于读算法,这种更新无所谓.

       查询一个不存在的key的耗时?

总的读取原则是这样的：首先从属于level 0的文件中查找，如果找到则返回对应的value值，如果没有找到那么到level 1中的文件中去找，如此循环往复，直到在某层SSTable文件中找到这个key对应的value为止（或者查到最高level，查找失败，说明整个系统中不存在这个Key)。[2]

4. 理解lsm-tree[1]

仅仅SSTable数据结构本身仍然无法support高效的range query和random r/w的场景,还需要一整套的机制来完成从memory sort, flush to disk, compaction以及快速读取……这样的一个完成的机制和架构称为,"The Log-Structured Merge-Tree" (LSM Tree) . 名字很形象, 首先是基于log的, 不断产生SSTable结构的log文件, 并且是需要不断merge以提高效率的.

另一篇lsm,对比阅读.WiscKey: Separating Keys from Values in SSD-Conscious Storage [读后整理]

目前的KV存储引擎中，对写性能要求比较高的大多数都采用了LSM，典型的有BigTable/LevelDB-->RocksDB[5,对比调研]/Cassandra/HBase//PNUTS/Riak。[3]

下图很好的描绘了LSM Tree的结构和大部分操作:

4. lsm 和 innodb的区别?

innodb的更新是先读页再更新, lsm是直接插入代替更新.

5. 数据分布扩展性问题

一致性hash [其实是 range 分区 + 将key hash + 虚拟节点的另外一种形式] . 本质上还是 range partition 分区.

从 "最初的直接hash到节点" 演进到  "一次hash+一次索引"

和dht区别 [13]

6. 一致性问题

Cassandra 架构简述 有用的翻译 http://www.cnblogs.com/hxdong/category/489178.html gossip 算法实现[14] [15]

Internode communications (gossip) gossip的其他应用,P2P大规模直播与GOSSIP协议

snitch. (告密者) 可以知道集群中的每个节点所属数据中心和机架. 方便cassandra来进行副本存放选择

Snitches按实现分为三种：

（1）SimpleSnitch：这种策略不能识别数据中心和机架信息，适合在单数据中心使用；

（2）NetworkTopologySnitch：这种策略提供了网络拓扑结构，以便更高效地消息路由；

（3）DynamicEndpointSnitch：这种策略可以记录节点之间通信时间间隔，记录节点之间通信速度，从而达到动态选择最合适节点的目的。
SimpleSnitch比较简单就不用介绍了，此类只是一个默认实现。下面主要介绍NetworkTopologySnitch和DynamicEndpointSnitch两种策略。

Repairing nodes  有三种方案：

read repair，

hinted handoff，

anti-entropy repair

Merkle Tree及其应用 .快速检测数据变动的hash值数. 而不是之前的raid6. 还能检测.

datastax 用来检测data inconsistency 并完成anti-entropy repair达到最终一致性

W + R > N 见太阁技术秀：一起聊聊cassandra  另[11] 时间戳问题.

6. 为什么cassendra性能好.

6. 进阶 再看复杂的sstable格式详解 [7], sstable详细接口[8]

参考文献

先看[1] [2]就够了

[1] 详解SSTable结构和LSMTree索引

[2] leveldb 完全阐释了lsm 基于sstable实现快速的思想LevelDB设计与实现

[3] WiscKey: Separating Keys from Values in SSD-Conscious Storage [读后整理] 根据ssd优化的sstable lsm

[4] Original Paper on LSM: The Log-Structured Merge-Tree (LSM-Tree)

[5] 理解了什么是lsm后再看 对LevelDB的“升级版”存储引擎RocksDB的调研成果

[6] tidb和rocketDB关系 高性能Key/Value存储引擎levelDB, rocksDB, TiDB,InnoDB

[7] sstable格式详解[6]

[8] sstable详细接口

[9] 太阁技术秀：一起聊聊cassandra

[10] sstable的实现 网易视频云：HBase – 存储文件HFile结构解析 解析

[11] 分布式数据库的取舍——Cassandra的选择及其后果 https://yangzhe1991.org/blog/2015/10/%E5%88%86%E5%B8%83%E5%BC%8F%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E5%8F%96%E8%88%8D-cassandra%E7%9A%84%E9%80%89%E6%8B%A9%E5%8F%8A%E5%85%B6%E5%90%8E%E6%9E%9C/

[11] 那些优雅的数据结构(1) : BloomFilter——大规模数据处理利器

[12] 含数据公式,Bloom Filter概念和原理 http://blog.csdn.net/jiaomeng/article/details/1495500

[13] Gossip、DHT和传说中的W+R>N 内含SWIM协议

[14] https://github.com/apache/incubator-gossip

[15] serf是出自Hashicorp的开源项目， 实现了去中心化的gossip(八卦)协议 内含SWIM协议