rocksdb

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

I'm working with Kafka that save the data into rocksdb. Now I want to have a look at the db keys and values that created by Kafka. I downloaded FastNoSQL and tried but failed. The folder contains: .sst files .log files CURRENT file IDENTITY file LOCK file LOG files MANIFEST files OPTIONS files How can I watch the values? Keylord (since version 5.0) can open RocksDB databases. For example here is Kafka stream of Wordcount application : For RocksDB db files you can use FastoNoSql . It looks like the reason you have data stored in RocksDB files is because you are using Apache Kafka's Streams API.

作者：Yi Wu TiKV 是一个开源项目，我们一直都欢迎和感激开源社区对 TiKV 所作出的贡献。但我们之前对开源社区的合作主要是在代码审阅和散落在各种社交媒体的线下讨论，开发者并没有合适的途径去了解和影响 TiKV 的开发计划。怎么才能更好的帮助大家找到组织，更好地参与到 TiKV 的开发中来呢？我们的设想是搭建公开的平台，邀请对 TiKV 中特定领域感兴趣的开发者加入其中，与我们一起探讨和推进相应工作。Special Interest Group（SIG）就是这样的平台。 TiKV Engine SIG 是继 Coprocessor SIG 之后成立的第二个 TiKV SIG 社区组织，主要职责是对 TiKV 的存储引擎的未来发展进行讨论和规划，并进行相关开发和维护。 目前 TiKV 仅支持默认存储引擎 RocksDB，但是通过扩展接口，希望未来 TiKV 可以支持更多的存储引擎，我们也期待这部分工作可以得到社区的支持，在社区的讨论和贡献中得到更好的完善。此外，Engine SIG 也会对已有的存储引擎进行相关的开发和完善工作。 Engine SIG 的工作主要涉及的模块包括： Engine Trait： TiKV 中存储引擎的抽象层。 RocksDB：包括维护 TiKV 所使用的 RocksDB 分支，以及 rust-rocksdb 封装。 Titan：提供 KV

其实每一种数据库，它都是一种抽象的数据结构的具体实现。 随着 rocksDB（facebook的）,levelDB（google的），以及我们熟知的hbase，他们都是使用的LSM树结构的数据库。 它的核心思路其实非常简单，就是假定内存足够大，因此不需要每次有数据更新就必须将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到最后多之后，再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的，可以通过合并排序的方式快速合并到一起)。下图是最简单的二层LSM Tree. 图来自 lsm论文 lsm tree，理论上，可以是内存中树的一部分和磁盘中第一层树做merge，对于磁盘中的树直接做update操作有可能会破坏物理block的连续性，但是实际应用中，一般lsm有多层，当磁盘中的小树合并成一个大树的时候，可以重新排好顺序，使得block连续，优化读性能。 一般数据库的存储一定要保持有序，有序是一个非常重要的概念（当然hash结构的除外, hash 不支持顺序扫描 ，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,如果不需要有序的遍历数据，哈希表就是your Mr.Right ）. LSM树相比于B+树（大量的叶节点操作， 不仅支持单条记录的增、删、读、改操作

典型的3种存储引擎 1、hash： 代表：nosql的redis/memcached 本质为： 基于(内存中)的hash； 所以支持 随机 的增删查改，读写的时间复杂度O(1)； 但是无法支持顺序读写(注，这里指典型的hash，不是指如redis的基于跳表的zset的其他功能)； 基本效果：在不需要有序遍历时，最优 2、磁盘查找树： 代表：mysql 本质为：基于(磁盘的)顺序查找树，B树/B+树； 基本效果：支持有序遍历；但数据量很大后，随机读写效率低(原因往下看)； 3、lsmtree： 代表：hbase/leveldb/rocksdb 本质为： 实际落地存储的数据按key划分，形成有序的不同的文件； 结合其“先内存更新后合并落盘”的机制，尽量达到磁盘的写是顺序写，尽可能减少随机写； 对于读，需合并磁盘已有历史数据和当前未落盘的驻于内存的更新，较慢； 基本效果：也可以支持有序增删查改；写速度大幅提高；读速度稍慢； B树 B树是一种平衡多路搜索树，B树与红黑树最大的不同在于，B树的结点可以有多个子女，从几个到几千个。那为什么又说B树与红黑树很相似呢?因为与红黑树一样，一棵含n个结点的B树的高度也为O（lgn），但可能比一棵红黑树的高度小许多，应为它的分支因子比较大。所以，B树可以在O（logn）时间内，实现各种如插入（insert），删除（delete）等动态集合操作。

一个StateBackEnd 包括以下几个部分： 1.CheckPointStreamFactory 构造流用于写出Checkpoint 数据 不同的StateBackEnd会有不同的实现,返回不同的CheckpointStateOutputStream实现，比如 FsStateBackEnd 就会构造文件流, 而MemoryStateBackEnd就会构造ByteArraOutputStream CheckpointStateOutputStream 会作为IO代理包含在KeyedStateCheckpointOutputStream 和 OperatorStateCheckpointOutputStream内. KeyedStateCheckpointOutputStream 和 OperatorStateCheckpointOutputStream 分别需要记录额外的状态. KeyedStateCheckpointOutputStream 需要记录每个keyGroup起始在流中的位置, OperatorStateCheckpointOutputStream 需要记录每个partition起始在流中的位置, 这些信息都会体现在对应的StreamStateHandle中. CheckpointStateOutputStream 定义了 closeAndGetHandle

单机存储引擎分类 根据《大规模分布式存储系统：原理解析与架构实战》，有三类单机存储引擎： 哈希存储引擎是哈希表的持久化实现; B树存储引擎是B树的持久化实现; LSM树（Log Structure Merge Tree）存储引擎采用批量转储技术来避免磁盘随机写入。 comdb（百度内部Mola开发的一个单机存储引擎）和文中的Bitcask存储引擎类似，不过更搓一些，没有对索引文件进行固化，启动速度比较慢（小时级别）。 1 写入过程：对日志进行追加写入，更新内存索引，标记老纪录无效，等待定期rewrite。 2 读取过程：检索内存，读盘 3 rewrite 过程：限速读取一个数据分片，顺序读取索引表，写回新文件，切换，删除老文件。 lmdb 利用mmap 直接进行映射，尽量少内存拷贝（可以为只读直接返回引擎中的内存），提高读性能 利用tree 方式组织数据，并且和系统虚拟内存页大小一致的页进行文件组织 优点：专门进行了读优化 缺点：和系统页一样大的组织方式（4k），如果单条record为1k，浪费严重 leveldb 利用层表方式组织数据，优化写入速度 优点：为写入优化，并且进行压缩 缺点：写入太频繁，来不及重写磁盘会爆掉（LSM通病）。最坏落盘7次，不可忍受。 rocksdb: RocksDB是FaceBook起初作为实验性质开发的一个高效数据库软件

概述 在开发过程中，我们经常会遇到并发问题，解决并发问题通常的方法是加锁保护，比如常用的spinlock，mutex或者rwlock，当然也可以采用无锁编程，对实现要求就比较高了。对于任何一个共享变量，只要有读写并发，就需要加锁保护，而读写并发通常就会面临一个基本问题，写阻塞读，或则写优先级比较低，就会出现写饿死的现象。这些加锁的方法可以归类为悲观锁方法，今天介绍一种乐观锁机制来控制并发，每个线程通过线程局部变量缓存共享变量的副本，读不加锁，读的时候如果感知到共享变量发生变化，再利用共享变量的最新值填充本地缓存；对于写操作，则需要加锁，通知所有线程局部变量发生变化。所以，简单来说，就是 读不加锁，读写不冲突，只有写写冲突 。这个实现逻辑来源于Rocksdb的线程局部缓存实现，下面详细介绍Rocksdb的线程局部缓存ThreadLocalPtr的原理。 线程局部存储(TLS) 简单介绍下线程局部变量，线程局部变量就是每个线程有自己独立 的副本，各个线程对其修改相互不影响，虽然变量名相同，但存储空间并没有 关系。一般 在linux 下，我们可以通过以下三个函数来实现线程局部存储创建，存取功能。 int pthread_key_create ( pthread_key_t * key , void (* destr_function ) ( void *)), int pthread

这次的项目我们重点关注RocksDB中的一个环节：Rate Limiter。其实Rate Limiter的思想在很多其他系统中也很常用。 在RocksDB中，后台会实时运行compaction和flush操作，这些都会对磁盘进行大量的写操作。可以通过 Rate Limiter 来控制最大写入速度的上限。因为在某些场景下，突发的大量写入会导致很大的read latency，从而影响系统性能。 Rate Limiter的基本原理是 令牌桶算法 ：系统每秒往桶里丢数量为1/QPS的令牌（满了为止），写请求只有拿到了令牌才能处理。当桶里没有令牌时便可拒绝服务（阻塞）。它在RocksDB中的实现可以参考 这里 。 Rate Limiter中可以调节的有 以下几个参数 ： int64_t rate_bytes_per_sec：控制 compaction 和 flush 每秒总写入量的上限。一般情况下只需要调节这一个参数。 int64_t refill_period_us：控制 tokens 多久再次填满，譬如 rate_limit_bytes_per_sec 是 10MB/s，而 refill_period_us 是 100ms，那么每 100ms 的流量就是 1MB/s。 int32_t fairness：用来控制 high 和 low priority 的请求，防止 low

论开源分布式存储，Ceph大名鼎鼎。用同一个存储池融合提供块存储、对象存储、集群文件系统。在国内有近年使用量迅速攀升，Ceph Day峰会也搬到北京来开了。 大型公司内部研发云虚拟化平台，常使用开源方案Openstack或者Kubernetes，配套的为虚机或容器提供块存储的开源方案，几乎为Ceph莫属。对象存储几年发展迅速，图像、视频、网站资源等皆可适用，有初创公司基于Ceph搭建存储服务方案。企业存储方面，国外有Redhat收购了Inktank，后者由Ceph初创作者Sage Weil创建；国内有XSky星辰天合，聚集了大量从早期就开始专注Ceph的专家。（P.S.关于国内谁在大规模使用Ceph，上Ceph Day看Slides可以知道。） 可以将Ceph理解为分布式管理层，加上每个存储节点（OSD）的存储后端。社区成熟的存储后端使用FileStore，用户数据被映射成对象，以文件的形式存储在文件系统上。文件系统可以是EXT4、BtrFS、XFS等。最近两年，因为FileStore的种种问题，由Sage Wei推动，Ceph社区合力推出了新的存储后端，BlueStore。 BlueStore有独特的架构，解决了Ceph社区一直烦恼的FileStore的日志双写问题，测试性能比FileStore提高了一倍。这让人非常想深入剖析BlueStore。另一方面