cstore

cstore

概述

BaikalStore默认采用行式存储，cstore为BaikalStore的engine模块提供了列存特性，可以设置 FLAGS_rocks_column_based = true 开启。

目前，用户需要根据不同的业务场景选择适当的存储方式，一种普遍的分类如下：

• Row format for OLTP（Online Transactional Processing, 联机事务处理）：Large/batch process
• Column format for OLAP（Online Analytical Processing, 联机分析处理）：point/short access

未来，行存与列存节点可以做到在Raft-Group层面共存，由DB根据SQL执行代价模型自动选择rstore/cstore, 实现HTAP(Hybrid Transaction and Analytical Process，混合事务和分析处理)，这块的设计实现，可以参考TiDB + TiFlash ： 朝着真 HTAP 平台演进。而cstore在实现过程中也保留着与rstore高度的兼容性，非常适合未来的混存方案。

column-store vs row-store

1. features

• Columnar Storage stores data in columns instead of rows
  • Suitable for analytical workload : Possible for column pruning👍
  • Compression made possible and further IO reduction : 1/5 on average storage requirement👍
  • Bad small random read and write : Which is the typical workload for OLTP👎
• Rowstore is the classic format for databases
  • Researched and optimized for OLTP scenario for decades:+1:
  • Cumbersome in analytical use cases:-1:

2. example

3. Demo for OLAP

场景

# 统计每个广告平台的记录数量
SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20

行式

列式

Input/output分析

1. 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
2. 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
3. 由于I/O的降低，这将帮助更多的数据被系统缓存。

设计与实现

Architecture

在BakalDB中Region是存储与调度的基本单位，Region所代表的区间[start_key, end_key)内所有数据（主键聚簇索引，非主键二级索引），均位于同一Region下，参考： 索引的选择。其中：

• primary：主键聚簇索引，可以看为按主键key（primary key）排序value行存的key-value对
• secondaries：非主键索引，可以看为按索引key(second key) 排序value为一级索引指针的key-value对

通过以上分析可以看出，primary是行存的，secondary可以看成关于索引列的列存结构，因为同一索引在rocksdb里是连续存放的，因此我们改造重点在于primary，如何让同一column的数据在kv里进行连续存放。为此我们把primary拆分为 primary + primary_columns来实现列存。