fastdfs和ceph对比
需求是图片，视频等文件的存储
属于少写多读的场合，修改操作较少。文件粒度是大小文件都有。
fastdfs
先谈谈fastdfs，我在公司已经应用了两年了，对他的基本特性比较熟悉，在这种场合下有这些优缺点
优点：
1 机器配置要求低。毕竟号称“穷人的解决方案不是白来的”。不管是上传下载，同步恢复，都对机器的负载要求非常低。
2 上传速度快。因为是弱一致性模型，上传不需要强写副本才能返回。（强一致性模型对网络和机器要求都不会低）
3 已知的大规模成功案例较多，公司内部运维时间长
缺点：
1 小文件的故障恢复时间长，100GB/hour。
2 存在上传成功但丢失文件的可能性。弱一致性模型是双刃剑，如果在刚上传文件后，副本文件尚未产生，此时文件是单点状态。
该状态有两种情况：
一种是文件在磁盘中，等待被同步到其他机器，该情况下宕机，文件还存在（磁盘损毁就不存在了）；
一种是文件还在系统内存中尚未被写入磁盘，此时宕机会导致数据彻底无法恢复
3 没有元数据管理。这一部分我写的fastdfs网关已经解决了。
4 大文件直接存储不进行分片，从而分布在整个集群中，当大文件存在热点数据时，压力会出现再整个集群的某组机器上。
这个问题在fastdfs网关上加上切片上传的API可以缓解
ceph
ceph在某种角度上和fastdfs相当接近，都是想通过文件名，直接算出文件的所属位置。
优点：
1 强一致性模型保证数据可靠性
ceph的上传成功，是在数据被写入所有副本后返回的，这保证了数据不会在刚上传主节点后就丢失。
2 有元数据管理，甚至有现成的ceph网关来提供对象存储
3 大文件进行文件分片，默认4MB，对用户透明
缺点：
1 已知的大规模成功案例较少。
2 机器配置要求较高，参见官方文档硬件配置
摘抄其中原话“OSD 的日常运行不需要那么多内存（如每进程 500MB ）差不多了；然而在恢复期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。”
携程的配置（携程在 2015/10/18 SH Ceph Day 上的分享）：硬件：CPU(2 channels & 32 Core)、Mem128GB、disk（123TB/SATA disk +2256GB raid1 SSD）、NIC(4*Gigabit LAN, bond 2 in 1 pair)
3 无法充分发挥硬件性能
1）数据双倍写入。Ceph本地存储接口（FileStore）为了支持事务，引入了日志（Journal）机制。所有的写入操作都需要先写入日志（XFS模式下），然后再写入本地文件系统。
如果一份数据是三副本，那么客户端每上传1MB的数据，会产生4MB的磁盘流（网上有测试结果，3副本+日志一共4份数据），才算写入成功，如果对时延敏感，那么对网络和磁盘要求都高
2）IO路径过长。这个问题在Ceph的客户端和服务器端都存在。以osd为例，一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对IO进行处理时还要进行内存拷贝，导致整体性能不高。
4 扩容需要迁移文件，小文件迁移时间长
由于crush算法是变种哈希，因此当集群扩容后，需要迁移文件，迁移文件时间很长。
原文表述“文件平均大小100KB。”“一个OSD加入之后，迁移的IO压力几乎全部在这一个磁盘上，由于文件小，平均吞吐在2MByte/s，一个OSD需要迁移约1.5TB数据，耗时约一个星期，只想说F U C K。”
5 小文件的故障恢复时间长
这部分我没有做测试，但是ceph对小文件是没有合并存储的优化的，这部分和fastdfs在一个水平线，甚至由于他的复杂性，可能实际效率比fastdfs还要低。
故障恢复的速度和迁移文件的速度一致。
总结
总的来说，个人认为，直接用ceph上PB级别的数据，有点步子太大的感觉。很多地方感觉都hold不住。另外由于ceph代码的复杂性，出BUG以后是无法立刻解决的。
而fastdfs的两个主要问题：
1 恢复时间长，这部分ceph也存在。只要恢复时期不是单点，个人认为影响没有那么大。
2 可能丢失刚上传的数据。
可以在上传到fastdfs前，先缓存在一个cache池中，用于可能的故障恢复。
也可以把fastdfs做成强一致性的方案，在fastdfs这一层彻底根除这个问题
题外话
fastdfs和ceph方案是相当接近的，有些地方可以参考ceph。
例如把tracker做成ceph montior的结构，只有当缩扩容时，才通知客户端节点变化，而不是每次上传客户端都需要连tracker
另外fastdfs可以做成强一致性的方式，这在整体架构上是没有影响的。