bluestore 对 rocksdb 的优化
| 代号 | 版本 | 发布日期 |
|---|---|---|
| Firefly | 0.80版本（LTS） | 2014年 5月 |
| Giant | 0.87版本（Stable） | 2014年 10月 |
| Hammer | 0.94版本（LTS） | 2015年 4月 |
| Infernalis | 9.x 版本（Stable） | 2015年 11 月 |
| Jewel | 10.x版本（LTS） | 2016年 4月 |
| Kraken | 11.x 版本（Stable） | 2017年 1月 |
| Luminous | 12.x版本（LTS） | 2017年 8月 |
| Mimic | 13.x 版本（Stable） | 2018年 6月 |
| Nautilus | 14.x版本（LTS） | 2019年 3月 |
| Octopus | 15.x 版本（Stable） | 2020年 3月 |
| Pacific | 16.x版本（LTS） | 2021年 3月 |
BlueStore 在L版被引入，用于取代以前的FileStore，BlueStore 最大的特点是OSD可以直接接管裸设备，并且将对象数据存储在该设备当中，对象有很多Key-Value属性信息，这些信息之前都是存储在文件的扩展属性或者 LevelDB 当中，而在BlueStore中，这些信息存储在RocksDB当中。但是RocksDB是运行在文件系统之上的，因为为了使用RocksDB，我们需要开发一个简单的简单的文件系统，即：BlusFS。
BlusFS 是一个简单的用户态日志型文件系统，其完整地实现了 Rocksdb:Env 所定义的全部API 。 这些 API 主要应用于固化 Rocksdb 运行过程中产生的 .sst( 对应 SSTable) 和 log(对应WAL 文件）。
由于 WAL 对 Rocksdb 的性能影响最为关键, 所以 BlueFS 在设计上支持将 .sst 和 .log 文件分开存储，以方便将 .log 文件单独保存在速度更快的固态存储介质上。(NVME SSD）由此，在引入 BlueFs 后，Bluestore 将所有存储空间从逻辑上划分为 3 个层次：
-
慢速 ( Slow ) 空间
这类空间主要用于存储对象数据, 可由普通大容量的机械磺盘提供，由 Bluestore 进行管理。 -
高速 (DB) 空间
这类空间主要用于存储 BlueStore 内部产生的元数据 ( 例如 onode)，可由普通 SSD提供，容量需求比Slow 空间要小，由于 Bluestore的元数据都交由 Rocksdb 管理，而 Rocksdb 最终通过 BlueFS 保存数据，所以这类空间由 BlueFS 直接管理 -
超高速 ( WAL) 空间
这类空间主要用于存储 Rocksdb 内部产生的 .log 文件，可由 NVME SSD 时延较低的设备充当，其容量需求和 DB 空间相当。 同时，超高速空间也是由 BlueFS 直接管理。需要注意的是，上述的高速，超高速空间的需求不是不变的，其大小与慢速空间的使用情况息息相关。 如果上述两类空间规划得比较保守，BlueFS 也允许使用慢速空间进行数据转存，因此在设计上，BlueStore 将自身管理的部分慢速空间和 BlueFS 共享, 并在运行过程中实时监测和动态调整，其具体策略为:
BlueStore 通过自身周期性的被唤醒的同步线程实时查询 BlueFS 的可用空间，如果 BlueFS 的可用空间在整个 BlueStore 可用空间中占比过小，则新分配一定的空间至 BlueFS，反之如果 Bluers 的可用空间在整个 BlueStore 可用空间中占比过大, 则需要从 BlueFS 中收回部分空间。
综上, 如果 3 类空间分别使用不同的管理设备，那么 BlueFS 中的可用空间一共有3种：
-
对于 .log 文件以及自身产生的日志 ( BlueFS 本身也是一种日志型本地文件系统)、 BlueFS 总是优先选择使用 WAL 类型的设备空间，如果 WAL 空间不存在或者空间不足则选择 DB 类型的设备空间；如果 DB 空间不存在或者空间不足，则选择Slow类型的设备空间。
-
对于.sst文件优先使用DB类型的设备空间，如果 DB 类型的设备空间不存在或者空间不足, 则选择Slow类型的设备空间。
在实际使用中，通常配置基 于 BlueStore 存储引擎的OSD，按照 block(100) : db(1) ：wal(1) 的大小比例要求来划分逻辑区的大小。按照上述比例配置出的 OSD 性能经过实验验证是较好的, 也是行业内推荐的比例。
