内存和磁盘的双存储引擎架构
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% 左右的硬件成本。