深度结合云存储的存储引擎设计构想
目录
警告
本文最后更新于 2022-07-07,文中内容可能已过时。
本文由原作者归档自知乎,原文发布于 2022-07-07。原文链接:深度结合云存储的存储引擎设计构想。
最近,TiKV发布了新的存储引擎去适配Multi-Raft和云存储。https://github.com/tikv/raft-engine。在这个设计中,让我最受启发的是对IO的思考。
我们都知道云存储(云盘存储、云文件存储、对象存储)具有着非常大的存储空间、极高的吞吐和QPS性能,但是每次访问的IO时延却很大。虽然,随着云存储的技术发展,IO时延会不断地降低,但是想要做到本地nvme ssd的性能效果,还是有非常大的挑战。既然IO时延不好降低,索性从存储引擎方面入手,尽量减少IO操作、提高QPS和吞吐也能达到不错的效果。
TiKV的Raft-Engine的确也是这么做的,https://docs.pingcap.com/zh/tidb/stable/release-6.1.0

在Raft-Engine里面,还有很多其他的技巧去进一步降低IO次数、提高并发等。比如,多个write请求通过write group方式合并到一起去操作,将多个IO请求搞成1个。
未来应该出现一款新的存储引擎,每次write有极少的IO请求、但单次IO的size可以很大、或者有着极高的并行写能力。比如:
- 云存储本身可以保证数据的可靠性,有什么数据直接写就可以,那么存储引擎里面的block size就不在成为必须。此外,很多计算可以通过内存先buffer再批量写,从而提高吞吐,提高效率
- 云存储本身是分布式管理数据的,那么可以将存储引擎按照table或者region级别管理各自的wal,通过wal并行写的方式来提高QPS,从而提高效率
- 既然云存储的IO延迟不好解决,索性减少IO操作。Rocksdb设计比较好的地方就在于,每次update单行数据只有一个写WAL的IO请求,不好的地方是Flush和Compact会在某个时间占用很多的IO,而且Flush和Compact并不能充分利用云存储高QPS的特点,这是未来结合云需要改造的点。
- 或者,不经过linux的kernel直接操作云存储读写数据
如果有一款存储引擎, 能够按照这样的方式去深度结合云存储的现状去设计,那么上层的数据库server设计将会更简单(毕竟云存储可以保证数据可靠不丢失,那么server层都不需要raft三副本了),这会是有一次颠覆性的产品。