扩展rocksdb engine，对标hbase的功能

[mdianjun]

（持续更新）

单机版功能：

• column family
• region
• 多版本
• 单行事务

  在HBase中，一行数据下面有多个Column Family，所谓单行事务就是，HBase能保证该行内的多个Column Family的多个操作的ACID特性。 https://zhuanlan.zhihu.com/p/39427559 https://www.quora.com/How-does-HBase-support-transactions

• 读缓存(BlockCache)：regionserver级别

高级功能：

• WAL(HLog)：regionserver级别，作用：1.防止缓存数据丢失；2.主从复制
• BulkLoad

  If you can pre-process the data offline before inserting. There is a faster way: you can sort the data, generate SST files with non-overlapping ranges in parallel and bulk load the SST files. See https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files .

• snapshot：用于备份与恢复

  https://github.com/facebook/rocksdb/wiki/Snapshot

• 兼容hbase数据格式：HFile, HLog

分布式版功能：

• master服务：管理元数据信息，如regionserver列表、region与regionserver的对应关系
• 数据分布：寻址机制（zk=>meta表=>user表）
• 复制与一致性：hbase不负责对region作副本冗余（依赖存储计算分离）；一个region只被一个regionserver服务，从而保证一致性
• 容错：regionserver宕机或master宕机，怎么处理？
• 负载均衡：region迁移等（需要master）
• region的合并与分裂：master发起合并，regionserver发起分裂，这些变化要同步给master。
• 垃圾回收：被合并的sstable要被清理掉
• 分片

  You can use one RocksDB database per shard/partition. Multiple RocksDB instances could be run as separate processes or within a single process. When multiple instances of RocksDB are used within the single process, some resources (like thread pool, block cache, rate limiter etc..) could be shared between those RocksDB instances (See https://github.com/facebook/rocksdb/wiki/RocksDB-Basics#support-for-multiple-embedded-databases-in-the-same-process)

[mdianjun]

其他资料：

• column family的意义：https://dba.stackexchange.com/questions/166159/what-is-the-point-of-column-families
• Cassandra 数据模型设计最佳实践（上部）：https://www.infoq.cn/article/best-practice-of-cassandra-data-model-design
• Cassandra 数据模型设计最佳实践（上部）：https://www.infoq.cn/article/best-practices-cassandra-data-model-design-part2
• rocksdb源码分析：https://whoiami.github.io/
• LevelDB 和 RocksDB 结构详解：https://daemondshu.github.io/2019/03/21/Programming/Data%20Structure/LevelDB_RocksDB/

[mdianjun]

cassandra的特点：

• 无主架构
• 数据按partition key分布
• 数据副本
• 可配的一致性级别(quorum)：保证最终一致性
• 线性扩展
• 云上部署
• 二级索引

https://cassandra.apache.org/_/cassandra-basics.html

[godliness]

cassandra vs hbase:

https://www.scnsoft.com/blog/cassandra-vs-hbase

Cassandra：

• 擅长写入
• Cassandra的弱点是数据一致性
• 数据存储在本地
• 组件独立，自给自足
• 读写都是经过某一个节点（协调者）进行，每个节点都有全局的meta信息，这里的协调者可以理解成代理，看上去和ck的分布式表很像，但又不完全一样。
• • 无主架构，基于一致性hash圆环和gossip协议做的多副本与数据的分发，根据主键算出hash串来让该数据落到对应的虚拟机器上，每台虚拟节点都有一个hash区间。数据会根据配置的replica_factor参数来决定写入那几个节点。

HBase：

• HBase的弱点是数据可用性，存在单点问题，HMaster
• 擅长密集读取
• 数据存储在HDFS
• 依赖项比较多，zookeeper, hdfs
• 读写都是经过从zookeeper获取具体meta表所在的regionserver的地址，然后客户端发送请求到对应的regionserver再进行并发拉取，CK的分布式表目前没有什么预判策略，都是并发拉取，没有的shard也会收到请求（需要我们优化）。
• 有主架构，一个表横向切分多个region分配到不同的regionserver上，同一个region也可以放到多个regionserver上来做到多副本的功能。

共同点：

• 两者都不会频繁删除和更新数据（数据膨胀），删除和更新是追加操作，会存在短时的存储膨胀，后期都会有后台异步merge的过程来处理这些重复的数据，所以应对偶尔不频繁的删除和更新也是可以的。
• 适合点查，范围查，这点事CK不具备的，因为CK是通过稀疏索引粒度将.bin文件分成多个MarkRangers, 然后把这些MarkRangersa按照8份（默认）切开，比较每份的start end值是否在区间，以此递归下去，一直到步长小与8为止。而Hbase与Casandra是用的二分查找在HFile上锁定具体的block,但block(64K)中的keyvalue是进行遍历的。
• 底层都是LSM结构，写很快，但是两者均不是纯正的列式存储，所以对于单列的聚合操作性能是肯定比CK差很多的，但是CK的WAL以及MemoryTable个人感觉没有LSM那样完善，MemoryTable貌似并不是跳表的结构，不知道为什么会这样实现？
• 二者均不支持Join和子查询，但是CK支持，虽然性能一般。

• 都是可以支持上百万列的稀疏表，空值列不占存储空间, CK Null 貌似也是占用空间的。

  但是在实际项目中应用Cassandra和HBase的主要区别是这样的：Cassandra适用于具有复杂和/或实时分析功能的“始终在线”网络或移动应用程序和项目。但如果不急于得到分析结果(例如，做数据湖实验或创建机器学习模型)，HBase可能是一个不错的选择。特别是如果您已经投资了Hadoop基础设施和技能集。

---

对于CK来融合类似Casandra以及Hbase这些类RocksDB的系统，我有以下一些想法：

1. 给目前已经存在的CK表引擎，EmbeddedRocksDB Engine 我们可以通过分布式表的方式来查询这些表引擎，分布式表根据ZK中对应的range区间来分辨具体查询哪个shard，这样有个问题是CK目前主键在所有shards上并不是全局有序的，这点和hbase不一样，所以前期只能所有shard都查。
2. 给EmbeddedRocksDB表引擎实现ReplicatedEmbeddedRocksDB的功能，确保数据的高可用性。
3. 如果新添加shard, 如何做到数据的rebalance? hbase中hmaster会周期的来进行region在所有regionservers上的balance检查，但是CK是无主的，这点也和后期的上云密切联系，当计算存储分离后，每个shard中若包含所有的元数据？就不需要rebalance了。
4. 给EmbeddedRocksDB实现可配置的Settings方案，目前官方就是实现了简单的读写，连ColumnFamliy都不支持，更别说其他详细的RocksDB的配置了。（ 官方已经添加：https://github.com/cloudnativecube/octopus/issues/136#issuecomment-893195102 ）

---

CK目前是无主架构的，我觉得未来要真正上云，每个CK节点必须要拥有所有的元数据信息，除非我们自己研发给CK开发一个master, 但是这样会不会就跟社区走远了？另外一个优化可以是让CK的主键在全局有序，也可以进一步的优化分布式表的无用请求，未来CK打算将zookeeper放入CK内部是不是就实现了全局元数据存在本地了？

[godliness]

rocksdb与leveldb的关系以及内部结构详解：

https://daemondshu.github.io/2019/03/21/Programming/Data%20Structure/LevelDB_RocksDB/

rocksdb的columnfamily底层物理隔离，一个memtable多个sst文件为一个columnfamily.

[godliness]

目前clickhouse的rocksdb表引擎已经支持了对于rocksdb库的配置变更，包括columnfamilyoptions的配置(仅单CF)；增加system.rocksdb系统表，对rocksdb表引擎进行必要的系统指标记录： https://github.com/ClickHouse/ClickHouse/pull/26821

不过目前看我并没有发现clickhouse的rocksdb引擎对于多columnfamilies的支持，但rocksandra是有的，可以看下代码借鉴,以及对标一下hbase, rocksandra对于rocksdb的扩展的经验和意图。

clickhouse的rocksdb：

• 就一个columnfamily "default"

rocksandra的rocksdb:

• 3个columnfamilies, 分别存储 meta, index, data

https://appinventiv.com/blog/hbase-vs-cassandra/

[mdianjun]

hbase/cassandra读写性能比较：

When the comparison is drawn between Apache Cassandra performance and Apache HBase performance, it is done on the front of read and write capability. Write: Both HBase and Cassandra’s on-server write paths are fairly alike. There are some differences though which makes Cassandra better, like the difference in names for the data structure and the fact that HBase does not write to log and then cache simultaneously. Read: If you are looking for consistent and fast reads, you should go with HBase. Since it writes on only one server, there is never the need of comparison between the various nodes’ data versions. Even though Cassandra can handle over 129,000 reads in one second, the reads are targeted and there are high probability of them being inconsistent.

https://appinventiv.com/blog/hbase-vs-cassandra/