加速DB打开

当用户重新打开数据库时，以下是一些可能比预期花费更长的步骤:

Manifest replay Manifest重放

MANIFEST文件 包含自上次打开DB以来DB的所有文件操作的历史记录，并在DB打开期间重放。如果有太多的更新要重放，就需要很长时间。 当:

  1. 1.SST文件太小，所以文件操作太频繁。如果是这种情况，请尝试解决小型SST文件问题。可能memtable被频繁刷新，从而生成较小的L0文件，
  2. 或者目标文件大小太小，从而压缩生成较小的文件。您可以尝试相应地调整配置
  4. 2.DB只是运行时间太长，积累了太多的历史更新。无论哪种方式，您都可以尝试设置选项。
  5. max_manifest_file_size强制在manifest文件达到最大大小时生成新manifest文件，以避免重放太长时间。

WAL replaying WAL重放

如果包含任何有用的数据，所有的WAL文件都会被重放。

如果您的memtable大小太大，则重放可能会很长。所以尽量缩小memtable的大小。

要重放的WAL文件太大的另一个常见原因是，其中一个列族的写入速度太慢，导致日志无法被删除。当DB重新打开时，将读取所有这些日志文件，以便重放来自这个列族的更新。 在本例中，设置适当的选项。options.max_total_wal_size low-traffic低流量列族将被刷新，以限制总WAL文件重放到这个阈值以下，见 Write Ahead Log(https://github.com/facebook/rocksdb/wiki/Write-Ahead-Log)

Reading footer and meta blocks of all the SST files 读取所有SST文件的页脚和元块

当 options.max_open_files 设置为-1，在DB打开期间，将打开所有SST文件，并读取它们的页脚和元数据块。这是从磁盘随机读取。如果您有很多文件和相对较高的延迟设备，特别是旋转磁盘，那么这些随机读取可能需要很长时间。 有两个选项可以帮助缓解这个问题:

  1.  * options.max_file_opening_threads 允许并行读取这些文件。将这个数字调高通常在高带宽设备上工作的很好，比如SSD。
  2.  * 设置 options.skip_stats_update_on_db_open=false，这允许RocksDB对每个文件少做一次读取。
  3.  * 调优 LSM-Tree 以减少SST文件的数量也很有帮助。

Opening too many DBs one by one 一个接一个的打开太多的DBs

有些用户管理每个服务的多个DBs，并逐个打开DBs。如果他们有多核服务器，他们可以使用线程池并行地打开这些DBs。