1 避免 给内存管理添堵

1.1 other

如果 数据 仅使用一次的话. POSIX_FADV_DONTNEED and O_DIRECT

2 写 分离

• 日志盘 和 数据盘 分离
• 顺序写 和 随机读写 分离

3 内核参数

• /sys/block/sdx/queue/
• 文件系统参数
• /proc/sys/vm/

减少系统调用

• buffer

• 合并

减少不必要的进程唤醒/切换

• 避免惊群或无效唤醒:

• • pthread_cond_signal 的问题, 以及替代方法
• • epoll_wait 边沿触发

• worker数量, 通常是指进程数, 需要 <= vCPU数

• golang 协程 (当前笔者不熟悉golang)

以下内容未经过源码查验. 如有错误, 欢迎指出.

一块1G的磁盘, 要先划定用来存储 快照的区域, 这样, 实际最大寻址的 就不是1G, 比如说, 只有800MB, 是这样吗?
答: 不是这样的, 而是就没有直接寻址的. 读取都需要查询映射表. 换句话说, 整块磁盘都用来存放快照.

快照是存放在文件系统上, 还是 没有块设备上, 划一块区域 存快照?
答: 不是存放在文件系统上.

live data是写到 实际磁盘位置上(不需要映射), 对吗?
答: 好像不是.

backup 还是 跟 快照存放在同一块磁盘上吗?
答: 不是的. 快照向上层 展示了 线性的磁盘, 而其实现是 映射表. backup是对 快照的整合, 若放在同一个磁盘上, 则会干扰 映射关系.

快照自身是需要存储 地址的, 否则无法通过 快照来构建 backup. backup展示的是 线性的空间, 还是需要映射? 或者说, backup是否需要存储 块的地址(起始地址)?
答: 文档提到 backup每块是2M, 由此可猜想, backup的组织形式 地址是递增的, 但地址可以不连贯, 也就是允许 2M的块 之间有 断开. 所以, 需要存储块的起始地址. disaster recovery (DR) volume 才是不需要起始地址的, 因为是volume.

目录:

1. 避免突发大量压缩, 导致延迟过大

DBImpl::MakeRoomForWrite
{

  if (allow_delay &&
    versions_->NumLevelFiles(0) >= config::kL0_SlowdownWritesTrigger) {
  // We are getting close to hitting a hard limit on the number of
  // L0 files.  Rather than delaying a single write by several
  // seconds when we hit the hard limit, start delaying each
  // individual write by 1ms to reduce latency variance. 与其在达到hard limit后, 延后好几秒, 我们选择在达到soft limit后, 对每个独立的写延后1ms. Also,
  // this delay hands over some CPU to the compaction thread in
  // case it is sharing the same core as the writer. 这样, 也将一些cpu让给压缩线程.
  env_->SleepForMicroseconds(1000);

}

目录:

1. 为什么要compaction?

compaction可以提高数据的查询效率，没有经过compaction，需要从很多SST file去查找，而做过compaction后，只需要从有限的SST文件去查找，大大的提高了随机查询的效率，另外也可以删除过期数据。

删除过期数据? 比如 相同key, 不同时期的value?

2. 压缩基础

https://github.com/facebook/rocksdb/wiki/RocksDB-Basics

The three basic constructs of RocksDB are memtable, sstfile and logfile. The memtable is an in-memory data structure - new writes are inserted into the memtable and are optionally written to the logfile. logfile是可选的. The logfile is a sequentially-written file on storage. When the memtable fills up, it is flushed to a sstfile on storage and the corresponding logfile can be safely deleted. The data in an sstfile is sorted to facilitate easy lookup of keys.