开放的项目

  • 可插入的 WAL
  • 数据加密
  • 以一种智能的方式在刷新和压缩之后热块缓存
  • 可查询备份
  • 通过使数据分区更均匀来改进子压缩
  • 将操作收集到数据库并重放它们的工具
  • 为数据块定制bloom过滤器
  • 为时间序列数据库优化构建新的压缩样式
  • 在db_bench中实现YCSB基准测试场景
  • 当WAL文件较大时提高DB恢复速度(并行重放WAL)
  • 使用线程池执行读前+解压和压缩+写后，伊戈尔开始这么做了。当手动压缩是多线程的时候，我们可以使用RocksDB作为一个快速的外部排序器—-按随机顺序加载键，禁用compaction压缩，然后手动compaction压缩。
  • 在 MongoDB + RocksDB 中暴露合并操作。
  • SQLite + RocksDB
  • WAL 写 为快速压缩。也许只适用于较大的写操作，也许我们向WriteOptions添加一个字段，以便用户可以请求它。

研究项目

自适应write-optimized算法

  1. RocksDB中的调优粒度是一个列族(CF)，它本质上是一个独立的LSM树。然而，很多时候，列族中的数据由具有不同特性的各种工作负载组成。
  2. 每个工作负载都需要不同的调优。在MyRocks的情况下，这可能是因为CF存储多个索引--有些重点操作，有些重范围操作，有些重读取，又些只读，有些重读+写。
  3. 即使在索引中，也有各种各样的情况--会有一些热点被写入，一些数据被写入一次，一些被写入N次，然后它变成只读的。
  5. 将工作负载调优并将索引划分到不同的列族将占用太多资源。当一个指数有多种变化时，目前能做的就不多了。一个聪明的算法应该能够处理这种情况。

自调优 DBs

  1. 每个LSM树都有许多配置参数，这使得即使是专家也很难对它们进行优化。典型的黑盒机器学习算法依赖于许多数据点的可用性，但在这里无法工作，因为生成每个新数据点需要大规模运行数据库，
  2. 这需要大量的时间和资源预算。从现在生产系统收集数据点也是不实际的，因为需要将这些数据共享给组织外部，这涉及到安全问题。

非最佳、不可调整的LSM

  1. 有一长串工作负载小的用户，他们可以接受次优性能，但是没有足够的工程资源对其进行优化。配置的默认值列表也并不总是适用于它们，因为它可能会给某些特定工作负载带来无法接受的糟糕性能。
  2. 没有任何调优旋钮的LSM树对于任何给定的工作负载（甚至是角落的情况）都提供了合理的性能，对于有一长串工作负载小的用户非常实用。

用于范围查询的Bloom过滤器

  1. LSM树有读取放大不良的缺点。为了解决这个问题，Bloom过滤器对于LSM树来说是必不可少的。Bloom过滤器可以很好地判断SST文件中是否存在KEY，然而，在服务SQL查询时，许多查询不仅仅是点查找，而且涉及键上的范围说明符。
  2. 一个例子是"Select * from T when 10 < c1 < 20",当特定建(由c1组成)不可用时。在这种情况下，可以对范围进行操作的 Bloom过滤器可能会有所帮助。

RocksDB 在纯NVM上

  1. 当RocksDB使用非易失性内存（NVM）作为存储设备时，如何优化它？

分层存储上的RocksDB

  1. RocksDB 通常在两级存储设置上运行：RAM + SSD 或 RAM + HDD，其中RAM是易失性存储，SSD和HDD是非易失性存储。
  2. 关于如何在两个存储之间分割数据，有一些有趣的设计选择。例如，RAM可以单独使用，一个缓存块，也可以预加载的所有索引和过滤器，
  3. 或给定的分区索引/过滤器只顶级预加载到RAM中。当我们有一个多层存储设备层次结构时，设计选择就变得更加有趣了:RAM + NVM + SSD + HDD(或者它们的任何组合)，每个都具有不同的存储特性。在层次结构中分割数据的最佳方法是什么？

时序 DBs

  1. 如何根据时间序列数据库的特点对RocksDB进行优化？例如，知道键是按升序排列的整数，我们能更好地对键进行编码？
  2. 如果知道这些值是浮点数，而且相邻数之间具有很高的相关性，我们能更好地对它们进行编码吗？
  3. 给定时间序列DB中的数据分布模式，什么是最优压缩策略？这些数据在LSM树的不同层次上显示出不同的特征吗？
  4. 我们可以利用这些信息为每个层次提供更有效的数据布局吗？等