天行健，地势坤

rocksdb 2021 meetup 中 remote compaction 在 rocksdb-cloud中的应用

深入发掘当前业界主流引擎在nvme上的性能痛点

原来 LSM-tree 存储引擎 可以很强

春节要开心过，同样也要充实过。这篇论文解决你对LSM-tree的理解不透彻、优化无从下手、业务该如何选型不知所措等疑难杂症，让你对NoSQL 的理解跨越千山万水。更主要的是希望能够让更多对LSM-tree感兴趣的同学有一个快速入门并深入理解的途径，欢迎一起讨论。内容较多，可选择性阅读/精读。

华为天才少女 153w 年薪 的 华中科技大学博士的顶会论文，这里的优化点主要集中在结合NVM PMEM的LSM的write stall 和 写放大上。

学无止境，不过还好有高手指路，能够发现如此精彩的存储世界，叹之有幸！！！LSM 的作为新生代存储引擎的基础架构，优异的写吞吐，天然支持的冷热分离架构下提供足量的读的优化。有得必有失，Compaction的 数据回收和 merge sort带来的I/O 调度 挑战让后来者想要不断去征服这座性能高峰，为引擎界引入足以和B树相媲美的经典架构。

LSM/Rocksdb 引擎在批量 delete之后 会引入读放大，空间放大，写放大等问题，针对该问题的业界方案做一个代码层级的验证。从rocksdb 到 SIGMOD'20 的 Lethe，欢迎大家讨论。

文章目录背景描述dCompaction设计触发条件 VCT触发VT 合并的条件 VSMT测试数据优化的重心集中在减少写放大上，同时将读性能维持在和rocksdb 原生读性能接近之上，优化思想是中国科学院的2位博士 提出的。论文原地址：dCompaction: Speeding up Compaction of the LSM-Tree via Delayed Compaction背景描述通过YSCB 构造的workload 来统计 三种类型的操作造成的IO：Compaction, Get, Pu

基于skiplist的思想，在LSM通过guard实现FLSM对sst文件的管理。有效得减少了传统LSM的写放大问题，保证了每一层key-value在当前层仅写入一次。但又因为guard内部存在重叠key，在点查方面相比于传统的LSM 需要多读取多个SST文件，降低了读性能。

文章目录1. 前言2. 论文结构2.1 海啸 问题2.2 泄洪 问题2.3 洋流 问题3. X-engine架构1. 前言论文原地址X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing中文介绍x-engine最佳实践不得不说一群大佬聚集在一起还是能够产生非常优秀的思想和产品的，将一个 数据引擎做到极致，每一个优化细节都精心雕琢，还是能够吐出非常可观的性能和延时指标的。即使在

Bigtable 可以说是log-structed以及page-oriented 两种存储引擎的整合体，我们性能优越的单机存储引擎leveldb和rocksdb就是基于google的bigtable存储系统实现的。论文地址Bigtable: A Distributed Storage System for Structured Databigtable是基于分布式的存储系统，支持超大规模PB级别的数据存储，拥有分布式事务。我们的rocksdb则是单机存储引擎，支持分布式事务，但是需要上层适配。在此对

这一节描述了密集型应用的基本思考方式。可靠性。意味着系统发生故障，也能保持正常的运行。故障会集中在三个方面，硬件故障(通常是随机和不相关的)、软件故障(通常是系统性的bug,较难发现，较难处理)，人为故障(不可避免得时不时出错)。提供合理的容错技术能够隐藏某一些类型的故障。可扩展性。意味着在负载增加的情况下也有保持性能的策略。通过推特主页的时间线为例，描述了负载和性能之间的关系。在可扩展的系统下，我们只要通过增加处理容量，来在高负载的情况下保持性能和可靠性。可扩维护性。事关工程师和运维团队的生活.

数据存储系统的经典书籍：从数据系统的特性开始，先讲单机存储引擎 再到 分布式存储系统，最后到一些数据流的处理方式，作者深入浅出，译者更是精雕细琢，本书需要细品。将持续阅读整理，先从理论走一轮，再找一些系统做一做实验。...