虽然 Ceph 在逻辑上看起来是“随机写”，但实际上 Ceph 的设计在多个层面上优化了随机写对底层磁盘性能的影响。
Ceph 写入是否真的是随机的？
逻辑上的随机性：
- Ceph 使用 CRUSH 算法将数据分布到不同的 OSD（Object Storage Daemon）中，避免了集中式的元数据管理，从而实现了去中心化。
- 对于用户来说，看起来数据被“随机地”写入到不同 OSD。
物理上的优化：
- 每个 OSD 后端存储的实现会将随机写转化为更高效的顺序写，特别是在 HDD（机械硬盘）场景下，写入性能的优化尤为重要。
如何解决随机写的性能问题？
1. 使用写入日志（Journal/WAL）
- Ceph OSD 默认使用 写入日志 来缓冲写操作：
- 数据先写入高速存储介质（如 SSD 上的 Journal 或 WAL）。
- 日志写入完成后，数据再批量刷入 HDD。
- 效果:
- 随机小写变成顺序批量写，大幅减少磁盘寻道时间，提高写入性能。
2. 使用蓝店（BlueStore）
- Ceph 默认使用 BlueStore 存储引擎（从 Ceph Luminous 开始）：
- 数据直接写入设备，跳过文件系统（如 XFS）。
- 利用内置的 WAL 和 RocksDB 进行元数据管理和小数据优化。
- 效果:
- BlueStore 可以更高效地管理随机写，减少 I/O 放大，优化磁盘性能。
3. 使用高性能的存储介质（如 SSD 或 NVMe）
- 如果底层磁盘是机械 HDD，可以通过以下方式改善随机写性能：
- 使用混合存储架构：SSD（或 NVMe）用于日志或缓存，HDD 存储大块数据。
- 在 SSD-only 环境中，随机写对性能的影响相对较小。
4. 数据批量写入
- Ceph 在内部通过批量写入（batch write）机制，将多个小写合并为一次大的顺序写操作。
5. 调整对象大小
- Ceph 默认将数据分成 4MB 的块（对象），这种较大的对象大小可以减少写入的随机性，并更好地利用 HDD 的顺序写性能。
实际测试中随机写的表现
- 如果使用机械硬盘（HDD）并没有优化（如 Journal 配置不当），随机写性能可能会较低。
- 在优化配置下，随机写性能往往不会成为瓶颈，尤其是在使用 SSD/NVMe 或者 BlueStore 的环境中。
总结
- 写入模式： Ceph 表面上看是随机写，但通过写日志、BlueStore、缓存机制等优化，大部分随机写都会转化为底层的顺序写。
- 性能优化： 在合理配置 Ceph 集群后，底层存储的随机写性能影响会被极大降低，甚至对用户透明。
- 实践建议： 在 HDD 集群中，确保使用 Journal 或混合存储；在 SSD 集群中，随机写问题基本可忽略。
