LSMT存储引擎丨青训营笔记

炼铁术士
232 阅读4分钟

这是我参与「第四届青训营 」笔记创作活动的的第14天

LSMT与存储引擎介绍

Parquet和ORC格式 LSMT是Log-Structured Merge-Tree的缩写，在1996年幼Patrick提出，在2000年之后诞生的数据库例如Google BigTable、HBase、Canssandra等大多采用LSMT索引，2000前的如MySQL等就用相对而言更早的B-Tree结构

关于LSMT可以用一句话来解释，通过Append-only Write+择机Compact来维护结构的索引树

image.png

这里顺便解释一下存储引擎，以单机数据库MySQL为例，存储引擎大致可以分为计算层和存储层（存储引擎层），计算层主要负责SQL解析、查询优化、计划执行，数据库著名的ACID特性，在MySQL中全部强依赖于存储引擎，至于ACID特性这里就不多赘述了。

除了保障ACID以外，存储引擎还要负责屏蔽IO细节以提供更好的抽象，提供统计信息于PredicatePush Down能力。

存储引擎不掌握IO细节，让操纵系统接管，例如使用mmap，会有如下问题：

  • 落盘时机不确定造成的事务不安全
  • IO Stall
  • 错误处理繁琐
  • 无法完全发挥硬件性能

LSMT存储引擎的优势与实现

LSMT与B+Tree的异同

在B+Tree中，数据插入是原地更新的，B+Tree在发生不平衡或者节点容量达到阈值后，必须立即进行分裂来平衡，而LSMT与B+Tree可以用统一模型描述，从高层次的数据结构角度来看，二者没有本质的不同，可以互相转化

而工程实践上还是用LSMT来表示一个Append-only和Lazy Compact的索引树，B+Tree来表示一个Inplac-Update和Instant Compact的索引树，这是因为Append-only和Lazy Compact这两个特性更符合现代计算机设备的特性

为什么采用LSMT模型？

ALL problems in computer science can be solved by another level of indirection

目前在计算机存储乃至整个工程界都在利用Indirection处理资源的不对称性，存储引擎面对的资源不对称性在不同时期是不同的

在HDD时代，顺序与随机操作性能不对称，由于机械硬盘需要磁盘旋转和机械臂移动来进行读写，顺序写吞吐是随机读的25倍

而在SSD时代，顺序写与随机写性能不对称，由于SSD随机写会给主控带来GC压力，顺序写吞吐是随机写的6倍

这二者的共性是顺序写是一个对设备很友好的操作，LSMT符合这一点，而B+Tree依赖原地更新，导致随机写

LSMT存储引擎调优案例与展望

TerarkDB

TerarkDB aka LavaKV是字节跳动内部基于RocksDB深度定制优化的自研LSMT存储引擎，其中完全自研的KV分离功能，上线后获得了巨大的收益，

KV分离简单的来说就是Value较长的记录的Value单独存储

image.png

Flink

在字节内部Flink流处理状态存储场景实测 收益结论：

  • 平均CPU开销在3给作业上降低了26%~39%,
  • 峰值CPU开销在广告作业上有明显的收益，降低了67%,
  • 平均容量开销在3个作业上降低了17%~31.2%
  • 直播业务某集群容量不收缩，TDB的schedule TTL GC 彻底解决了该问题

随着硬件的发展，软件设计也会随之发生改变。近年来，出现了许多新的存储技术，例如SMR HDD ,Zond SSD /OpenChanned SSD,PMem等。如何在这些新硬件上设计/改进存储引擎是一大研究热点

而经典LSMT模型是比较简单的，有时候不能应对所有工况，可以提出新的模型来解决问题。

总结

  • 单机数据库的ACID特性依赖于存储引擎
  • LSMT存储引擎的顺序写特性更适合现代计算机体系结构
  • LSMT和B+Tree可以用同一模型描述并互相转化
  • Level Compaction策略，降低了读放大和空间放大，增加了写放大。
  • Tier Compaction策略，降低了写放大，增大了读放大和空间放大
  • 分布式KV存储，如HBase，背后的理论模型与单机存储引擎RocksDB一样都是LSMT
avatar
文章
阅读
粉丝