天行健，地势坤

住院期间的一些学习思考... 探索PostgreSQL 以及 RocksDB 的 2PC实现

append-only 存储引擎： leveldb/rocksdb/wiredtiger 写链路优化

rocksdb 基本隔离级别实现 以及 并发场景的冲突解决方案。

PMEM持久化存储引擎：128B 下的读 整个单机能到1.4亿，写也接近1亿

有了Env 这个抽象类，为什么多出来一个 EnvWrapper 这个原封不动重写Env 方法 的Env 子类?

围绕：ZNS: Avoiding the Block Interface Tax for Flash-based SSDs 论文展开ZNS ssd内部的实现原理

1. FileIndexer.2. PinableSlice & Cleanable3. 工业级 LRU Cache & Clock Cache4. ThreadLocalPtr & Version 系统5. JoinBatchGroup6. CoreLocalArray & Statistics

xor-filter 基本原理 以及 更高效的ribbon-filter 高斯消元的大体过程

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

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

Rocksdb 单机 五千万 qps 工业级 LRU-Cache的实现设计

rocksdb社区推出的key-value分离存储组件，无需额外接口，一个参数开启关闭key/value分离。

rocksdb advise_random_on_open 通过 posix_fadvise 关闭操作系统page_cache_sync_read 预读逻辑

Ratelimiter 在titandb Flush/GC 生成blobfiled的过程中无法生效

ingest file方式导入数据，减少系统cpu/io/memory 资源开销

tiandb 的 实现细节 及其 引入的问题，提出了一些适用场景。欢迎讨论交流。

十年前的持久化hash存储引擎 bitcask

真是精心雕琢的引擎啊

又一个简单问题。从获取有效key来看rocksdb的写入逻辑

Rocksdb 日志分析工具 ： 分析LOG日志中出现的性能和稳定性问题，并给出优化建议。手把手教你发布自己的python package，为全球开发者使用。

Rocksdb compaction/flush 线程池实现分享，且个人已实现该线程池基本功能，欢迎试用。

WiredTiger存储引擎编译过程 以及 LT_PREREQ(2.2.6) 问题解决

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

从rate limter 到 auto tune 以及 auto tuned compaction的优化实战，主要为了解决write-stall导致的读长尾以及写吞吐降低问题。

Rocksdb 请求耗时统计，请求计数统计 的优雅实现

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

rocksdb 迭代器如何完成构造并参与scan 过程，其基本架构介绍，DBIter, InternalIter, MergingIterator, MemtableIter, 以及LevelIterator和TwoLevelIterator 实现机制。

我们知道一个完整的监控系统必须存在p99/p999等分位数指标，作为系统可用性的评判标准之一。而像开源监控系统中做的很不错的`grafana`和`prometheus `一定需要工业级的分位数算法。所谓**分位数**(quantile)，比如p99，表示percent of 99，即99% 的数据小于当前p99的指标。使用分位数来统计系统的长尾延时，也是系统可用性的一种衡量指标。

通过本文，能够清楚 rocksdb的读写性能调优，compaction的核心调优，以及一些通用的优化配置。

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

有效的性能问题 既能节约自己与他人的沟通时间，又能展示自己对系统理解的深度和广度。品牌的建立是一辈子的事情，也是十分钟的事情。

LSM 引擎针 的业界相关优化方案已经有很多了，优化的方向也是在不同workload纬度上进行取舍。比如头条的Amap ，中科的dCompaction 是为了降低Compaction的写放大（写放大除了消耗ss）

文章目录背景描述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最佳实践不得不说一群大佬聚集在一起还是能够产生非常优秀的思想和产品的，将一个 数据引擎做到极致，每一个优化细节都精心雕琢，还是能够吐出非常可观的性能和延时指标的。即使在

近期工作中多少会涉及到SQL 相关的内容，尤其是leader在做分布式存储引擎底座的设计过程中提到：各种分布式事务，二级索引，还有剖析B+树的实现 ，并和我们rocksdb 的LSM实现差异等等，真的是让之前对分布式存储领域涉事不深的我云里雾里。特此将SQL相关的知识也做一个总结，在前人已有的积累之下做一个总体的语法入门总结，后续将深入引擎层探索底层数据模型的实现。这里以mysql为切入点，整理了开发人员需要了解的三种语言及其基本使用语法：DDL,DML,DQL本人使用的是mac,所以安装的话直接b

rocksdb 应用中的性能分析小工具：1. rocksdb 内部perf_context , statistics 2. systemtap、perf (on-cpu, off cpu火焰图, probe 子功能等)、 ftrace

作为通用的单机存储引擎，一个基本的crash safe功能是需要提供的，用来保证异常时的数据一致性。像我们rocksdb所在节点出现断电异常，节点死机 等情况，内存中的数据是会丢失的。此时，需要rocksdb提供一种机制，能够在这种异常情况下尽可能挽回多的数据。业界通用的解决方案就是WAL (write ahead log)，接下来通过Rocksdb 的WAL实现来探索一下 WAL怎么能够保证数据的crash safe。1. 概览上层应用针对rocksdb的每一次更新在同步流程之上会存放在两个地方，

Rocksdb的compaction流程可以说是比较核心的流程了，它的存在除了保证不同sst 文件之间的key-value之间的有序性，数据的压缩存储，清理过时数据之外，还需要在存储细节上做一些优化来进一步提升LSM tree的读性能（Range tombstone的构造，提升了deleteRange区间的key-value的判断效率；filter block的创建，提升判断一个key是否存在的概率；index block的创建，支持二分查找和hash map的查找，提升针对普通key-value的查找性

`DeleteRange`接口的设计是为了代替传统的删除一个区间[start,end) 内的key-value的接口