参考：[链接][链接][链接][链接][链接][链接]IntroductionRocksDB的Iterator在通过高度封装后，能够像C++ stl库为每一个容器结构的迭代器的iterator一样被应用，它能够定位到某个key，并能够从这个key开始进行scan，它也能够被用来进行反向scan。如果在创立迭代器时，ReadOptions.snapshot被给定，迭代器将返回该snapsho…

参考：[链接][链接]SST File Format之前在LSM-Tree局部有提过，但过后理解的比拟浅 {代码…} 与BlockBasedTableBuilder相干的类有以下几个BlockBasedTable, 该类封装了用于读取磁盘BlockBasedTable类型的SST表的逻辑。BlockBasedTableBuilder, 该类用于在磁盘上构建一个BlockBasedTable类型的SST表。BlockBasedTableFac…

Remote Compaction机制使近程地Compaction成为可能，它能够是一个不同的过程，甚至是在近程的主机上。通过将Compaction服务迁徙到近程的主机上，不会有后盾的Compaction服务去影响read和write申请，进步了性能和稳定性。而专用于Compaction的近程主机能够只对Compaction做优化，并用来给不同的DB做Compaction。

Compaction是RocksDB中很重要的机制，而RocksDB默认采纳Leveled Compaction策略。因而先着重剖析Leveled Compaction

B+树最大的性能问题是会产生大量的随机IO，随着新数据的插入，叶子节点会缓缓决裂，逻辑上间断的叶子节点在物理上往往不间断，甚至拆散的很远，但做范畴查问时，会产生大量随机读IO。对于大量的随机写也一样，新插入的数据在磁盘上的地位可能相隔很远，会产生大量的随机写IO。

问题形容编译环境MacOSM1 Progcc {代码…} 解决问题百思不得其解 最初终于在google搜到了和我一样问题的老哥[链接]可能真的是gcc导致的问题换成clang后，问题解决。

2011年中时，Dhruba Borthakur曾经在HBase/HDFS方面做了五年的开发工作，他十分青睐Hadoop优良的生态，但同时他想挑战一些新的货色：晋升HBase/HDFS的查问服务工作负载。

前文提到，所有进入RocksDB的数据，会先进入内存，再flush进disk。本文，我们会学习到，RocksDB 如果管理和存储内存中的数据。

单机基于SSTable。适用于与SSD一起使用。整体[链接]。mysql写入千条/s，读万应该没问题。redis 写入 万条/s 7M/s(k+v 700bytes，双核)读是写入的1.4倍 mem 3gb 2核。这两个网上搜的，不保证正确，就看个大概吧。S…

Titan 是由 PingCAP 研发的一个基于 RocksDB 的高性能单机 key-value 存储引擎，其主要设计灵感来源于 USENIX FAST 2016 上发表的一篇论文 WiscKey。WiscKey 提出了一种高度基于 SSD 优化的设计，利用 SSD 高效的…