内存和磁盘的双存储引擎架构
1.1 运用场景描绘
OpenMLDB 的线上服务部分为了满意不同的功能和成本需求，供给了两种分别依据内存和磁盘的存储引擎。关于这两种存储引擎的运用考量，和引荐匹配场景，见如下表。
1.2 存储引擎架构
1.2.1 内存存储引擎架构
内存存储引擎的详细架构参阅：在线模块架构 – 4.2 Storage Engine
1.2.2 磁盘存储引擎架构
OpenMLDB 磁盘存储引擎底层依据 RocksDB 完成。RocksDB 本质上是一个依据磁盘的 KV 数据库，其完成的根本逻辑为将创立表格时的索引所对应的 KEY 和 TS （OpenMLDB 列索引）组合起来，成为 RocksDB 的 KEY，并且映射到相应的 column family。RocksDB 内的值则即为当前索引键对应的 OpenMLDB 内的一行数据。下图反映了依据 RocksDB 进行存储引擎映射的根本架构。
1.3 运用方式
内存引擎为 OpenMLDB 默许的存储引擎，两种引擎的运用说明如下
- 两种引擎的指定为表等级，即在同一个数据库内，不同表格能够混合运用不同的存储引擎（可是一张表只能对应一种存储引擎）
- 存储引擎的指定通过建表时的参数
storage_mode进行指定，其可选值为Memory,HDD, 或者SSD，比如
CREATE TABLE t1 (col0 STRING, col1 int, std_time TIMESTAMP, INDEX(KEY=col1, TS=std_time)) OPTIONS(partitionnum=8, replicanum=3, storage_mode='HDD');
- 如不指定存储形式，则默许运用内存存储引擎
- 表格创立以后，无法再修正其存储形式
1. 功用支撑比照
虽然在大部分的场景，双存储引擎的功用支撑是共同的，可是在某些场景上还是有所差异。下图列出了相关的功用支撑差异，在做切换之前需求考虑关于业务是否有实践的影响。
2. 功能比照
2.1 硬件配置
- CPU：2x Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
- SSD：Intel DC P4600 Series 2TB，磁盘引擎选用该 SSD 作为存储介质
- DRAM：物理机器内存 512 GB，可是为了便利进行试验，咱们运用工具 Chaosblade (github.com/chaosblade-…) 进行模仿内存占用。终究模仿测验可用的内存为 8/16/32 GB
2.2 布置和负载
- OpenMLDB 运用集群形式布置，采用了两个 tablets 的配置，没有敞开预聚合优化。
- 测验所用数据和脚本运用了 OpenMLDB 内置的测验脚本的默许参数，能够参阅 github.com/4paradigm/O…
- 关于实时恳求，咱们运用了依据全量数据的随机查询，来避免体系缓存所带来的影响。
- 关于某组特定的可用内存参数，咱们不断增大数据量，来查看体系功能和数据量的联系。因为体系缓存的存在，咱们预期当数据量小于内存时，缓存能够很好的避免磁盘 IO 形成的功能阑珊；可是跟着数据量的增大，功能将会呈现继续下降趋势，直到某一个平衡点。这个试验能够帮助咱们学习到不同数据量下的功能体现，以及终究到达的预期最差功能。
2.3 测验成果
拜访推迟的试验成果如上图一所示，咱们能够有以下观察和结论：
- 当数据量小于可用内存时，因为体系缓存的存在，仍然能够保持较高的功能体现（毫秒级推迟）。
- 当数据量变大，功能将会继续下降，直到出现一个相对平衡的状况（拐点根本是当数据量为内存容量的 2-3 倍左右）。进入平衡状况首要是因为因为数据量较大，缓存根本失效，因此由磁盘 overhead 带来的功能阑珊占据了主导。
- 在进入平衡状况以后，功能阑珊到约为最优情况下（数据量较小时）的 20-50%
- 如果数据量小于内存，咱们测验依据 64 GB 物理内存下 16 GB 数据量的内存存储引擎的功能，功能数字对应图上 Mem. table 所示的横虚线。能够看到，内存存储引擎能够相比较于磁盘引擎的最好功能，额定带来拜访推迟大约 25% 的功能改善。该改善首要来自于依据内存存储引擎的双层跳表的索引结构，带来的窗口数据的快速拜访。
- 综上剖析，磁盘存储引擎整体的功能约为内存存储引擎的 15-38%
3. 总结
本文总结了 OpenMLDB 双存储引擎的架构和功用比照，以及体系性的调查了磁盘引擎的功能体现。实践运用中，咱们引荐依据实践的使用场景进行挑选。比如关于咱们所测验的使用场景，如果需求 10 毫秒左右的超低推迟，那么优先挑选内存存储引擎；如果关于内存成本灵敏，一起能够承受如 20-30 毫秒左右的推迟功能，则能够优先考虑磁盘引擎，将会帮你节省 80% 左右的硬件成本。
