这是Ceph开发每周谈的第八十八篇文章，记录从17年8月14号到17年8月20号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
一句话消息
很多用户问 CephFS 的多 Filesystem 特性是否安全，John 之前回应了这个特性并不是很好的测试覆盖，而且存在漏洞，用户在安全层面仍然能够访问所有 FS，而且不排除存在明显问题。
Ceph 12.1.2 和 12.1.3 存在严重性能衰退，请避免使用这两个版本测试。
-
RocksDB Multi Column Family Performance
RocksDB Column Family 是一套独立的运行环境用户区分不同的数据场景，他跟多个 RocksDB 唯一的差别就是一个事务仍然能够跨越多个 Column Family 并保证原子性，因为用一个 WAL。
图来自(http://blog.csdn.net/linuxheik/article/details/52702169)
Ceph BlueStore 是 RocksDB 重度使用者，受限于 RocksDB 的薄弱同步写入问题，很多开发者思考如何优化 RocksDB 的性能。实际上在很早就有 Samsung 的 Huohuo 和 Intel Jianpeng 提出这个优化，但是一直没有具体结果，这次来自 Intel 和 Alibaba 的开发者提出基于 Column Family 来分离 BlueStore 中对于不同数据的分别对待(https://github.com/ceph/ceph/pull/16606)。PR 测试了不使用 CF，使用 3 个 CF，以及 10 个 CF 的性能差别。总的来说，性能差距不是很大，3个 CF大致领先。
在 BlueStore 中，不同的数据采用了不同的键前缀，比如对象元数据，OMAP，PG 元数据，系统元数据，WAL 对象等等，最多有 10 个 CF，所以这里有 10 个 CF 的测试。而 3 个 CF 主要是为了把日志对象，对象元数据和 OMAP 区分开，形成较少的 CF，但是有明显的特征。
在 IOPS，延迟，99%延迟的比较中可以明显看出 3CF确实有一些优势，但是由于这个 PR 需要兼容旧版本，以及调整出合适的接口，便于其他代码利用，仍然需要一些工作，应该不会在 Luminous 版本进入。