内存和磁盘的双存储引擎架构

1.1 使用场景描述

OpenMLDB 的线上服务部分为了满足不同的性能和成本需求，提供了两种分别基于内存和磁盘的存储引擎。关于这两种存储引擎的使用考量，和推荐匹配场景，见如下表。

1.2 存储引擎架构

1.2.1 内存存储引擎架构

内存存储引擎的详细架构参考：在线模块架构 – 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% 左右的硬件成本。