注：本文内容引用自张洋老师的微博https://weibo.com/thinksoft，他现在是云和恩墨分布式存储研发专家。
读Understanding Write Behaviors of Storage Backends in Ceph Object Store。
Ceph中涉及到写操作的包含以下几类：
1）用户数据（data）；
2）元数据，描述数据的数据（metadata）；
3）日志，保证原子性和一致性的数据（journal）。
4）文件系统元数据，本地文件系统的元数据（FS metada）。
5）文件系统日志，文件系统保障内部数据原子性和一致性的数据（FS journal）。
6）KVDB压缩（compaction）。
7）清零（zero-filled）。ceph写一份数据会有13X的写放大，便是涉及到这几类数据和操作。
我们知道ceph为了保障数据的可靠性，存放数据通常是三副本策略（另有EC策略）。那么无论是data，metadata，journal都是三份。因此在应用端写入一个IO，在ceph内部实际上会额外产生许多内部IO，不同的存储后端差异很大。
Ceph提供了FileStore、KStore和BlueStore三种存储后端以供选择，那么以FileStore为例，来看看13X的写放大的来由。FileStore中ceph的数据被存放在XFS或者ZFS等本地文件系统中。这些文件系统本身又会记录日志（FS journal），以及还有它自己的元数据（FS metadata）。
一个典型的场景，采用FileStore，4KB随机写，长时间测试。由于ceph的三副本策略，数据就需要写入3份；metadata写入0.702份；journal写入5.994份；FS metadata写入0.419份；FS journal写入3.635份；合计起来，写放大超过13X。
具体到不同的存储后端。先来看看不同的存储后端都会写入哪些类型的数据：
1）FileStore。日志、数据、元数据、文件系统元数据和文件系统日志。
2）KStore。数据、元数据、压缩、文件系统元数据和文件系统日志。
3）BlueStore。数据、清零数据、RocksDB DB、RocksDB WAL。
（其中压缩指的是RocksDB或LevelDB压缩时产生的数据写操作；清零数据指的是OSD填入的0数据。）
论文作者先后在16块HDD和16块SSD上以4KB随机写做测试。测量了ceph三种不同存储后端的写放大情况。以下是基于SSD的数据：
1）FileStore。数据3+元数据（文件）0.702+日志5.994 +文件系统元数据0.419+文件系统日志3.635=13.750；
2）KStore(with LevelDB)。数据3+元数据（文件）5.012+压缩19.362+文件系统元数据0.040+文件系统日志2.236=29.650；
3）BlueStore。数据3+元数据（RocksDB）1.615+元数据（RocksDB WAL）7.436+压缩4.165+清零2.865=19.081；
无论是采用哪种存储后端，写放大都超过了13X。在FileStore上，额外的ceph journal使得写的传输量达到了3X，本地文件系统的开销超过了原本的数据量。对于KStore来说，主要的写放大因素来自于kvdb的压缩（compaction）。最后对于BlueStore来讲，小的写请求是写入了RocksDB的WAL中；另外数据清零（zero-filled）和压缩（compaction）也是不可忽视的。
以上是基于4KB随机写小IO情况来测试和计算的。如果增大IO大小，写放大倍数是会迅速变小的。这是因为在大IO情况下，无论是object的元数据、KV对、还是文件系统元数据等相对于IO请求大小来讲，比例就比较小了。当IO为4MB大小时，FileStore的写放大收敛于6X，KStore收敛于3X，BlueStore也收敛于3X。可见在大IO情况下，BlueStore对于优化FileStore上写双重日志的问题，还是颇为有效的。
参考资料
https://pan.baidu.com/s/1zjCrBh48dkwXJ2j1j5kNiQ?pwd=c1g2
作者：张洋
原文：企业存储技术
推荐阅读
欢迎关注企业存储技术极术专栏
