该文档即讲实打实的技术问题，又说了心贴心的生态现状，产品决策和技术选型人员都可以来看看。
1. 前言和背景说明
能搭建和使用PB级存储一直是强悍但无用的屠龙绝技，我们更多将其用于炫耀和吹嘘。但最近两三年，我接触了数十家存储量到PB级的客户，深感屠龙绝技已经不再是摆设。
下列变化导致了PB级存储需求的横空出世，连带着CDN、大数据、AI技术一并发展。
首先看数据是因何产生的：
4G和光纤网络普及，带宽提速但资费降价，UGC和PGC都如鱼得水。
智能终端的硬件竞赛让摄像头更清晰、传感器更灵敏。
物联网设备入网，例如传感器数据、医疗影像、基因测序、气象数据。
数据保存下来不代表有价值，曾经我们保留几百TB的日志，却只能做最简单的加减乘除统计，或者用于出问题后扒日志堆找证据；我们可以下载数万部影视剧，但一个人一辈子都看不完这些视频。
现在某些营销云已经可以做到毫秒级响应做精准广告投放，用户的日志更有价值了；人工智能逐渐参与辅助医疗，医学影像数据值得保存十年了。随着技术进步价格降低，无论是监管政策还是客户需求，都在推动着数据总量越来越大。比如说现在您买理财产品已经要求全程录像防止误导消费者了，比如说人脸识别已经应用到手机转账审核中。
我们在一个风口时代，无数从不联网的设备、从不收集的数据都跃上云端，已联网设备信息量也大大增加，作为技术决策人，必须有应对PB级存储需求的前瞻性。
假设你做ToC的App，只要你有爆款的梦想，就要存储爆仓的数据。
假设你是智能终端的设计者，现在生成的多媒体数据不仅仅可以被自然人拿来看了，我们还有很多想象空间把数据进行统计和处理。
假设你是物联网综合方案规划者，数据从存5天变成了存5年，你们能做出多少更合理更有长远性的决策？
PB级存储需求来了，但是市面上有多少成熟可用的PB级存储案例哪？
传统厂商会说我没问题，请上200个存储柜吧！但是就算我砸锅卖铁买了200个存储柜，存储服务不是简单的磁盘堆叠啊；而且提速降价的号角是2015年才的吹响的，传统存储设备的测试和成熟周期要5年时间吧。
前些年大量的个人网盘宣称自己有EB级别的数据，1EB的存储空间可是要用掉30-100万块4T盘啊，这些EB级网盘关停以后，这么多闲置硬盘居然没导致盘价跳水。专用的网盘客户端遮住了实现细节，你的存储技术能否复用到我的项目中？即使接口可以复用，你是在存储群集层面真做到了PB级别，还是无数个50T小群集简单加成的1EB？跟个人客户做过的市场宣传，不应该拿到企业客户这里当做正式承诺。
我有幸在某牛和某度两个云存储厂商呆过，也亲手搭建和维护过单一命名空间过PB的存储系统。在此我和大家分享三方面的知识：
为什么PB级存储必须是对象存储？
如何采购和使用对象存储。
如何设计和实现一个PB级对象存储。
2.大存储必须是对象存储
2.1目录树的无奈
当我们还是儿童的时候，想的是挣大钱了买什么？绝对不是买房买车买彩票，而是买玩具食物和小衣服。当我们从GB级用户变成PB级用户时，传统存储用法已经过时，为通用需求设计的的PB级存储都必须用对象存储接口。
假设你有10PB存储，每个文件100M大，那么你会有1亿个文件。一亿个文件你该如何组织目录结构？我们不考虑文件系统设计上限，我们也假设inode没有耗尽，无论你是每个目录下放100万个文件，还是套十万层目录去存储文件，这种文件访问和管理方式是特别笨拙和无奈。实际情况会比1亿个文件残酷的多，我们常见的文件只有1M左右，大型客户一个项目能有数百亿个文件，这是目录树的设计者们从未考虑过的大变局。
据上文推理，具有普遍适用性的PB级存储，硬件存储厂商从未实现过，因为他们不参与解决过亿文件的管理问题。开源存储方案求一直在谈自己的技术先进性，如何做出又大又快的存储，但很少有人介绍自己元数据系统在百亿Metadata的性能设计。
当前能支撑PB级存储需求的访问方式只有对象存储形式，比如http://mytest.baiduoss.com/ab/cd/ef.txt&token=asdf 。当客户向存储群集提交这个get请求时，hostname部分可以被存储系统定位到出该存储群集上某个租户，在确认该租户的token=asdf有效以后，会通过查询metadata数据库的方式，快速得到“ab/cd/ef.txt这个key值存储在第80组存储的第15个扇区”，然后存储服务器将文件取出发给客户，客户浏览器下载的文件会命名为“ef.txt”。
这种访问形式不用担心一个目录下有100万个文件，也不用一层一层遍历目录，即使1000亿个文件，我们要定位文件也只做一次数据库查询。
2.2对象存储对程序员友好
我们习惯了点开文件夹的访问方式，对象存储对人类并不友好，但这种方式对程序很友好。
曾经你写程序必须要知道公用数据存在哪里能不能访问，你要关心ext4和nfs的权限问题，偶发网络波动会让你的所有应用全部hang住；现在你只需要拼接一个url并签发一个token，你编写的任何联网应用都可以读写数据，数据读写成功都有日志，即使读取失败也有可以理解的http返回值。资源可以被简单描述、简单调用、调用结果可信赖、即使调用失败也能catch异常，这才是程序员想过的日子嘛。
对象存储不仅仅让读写一个文件变得简单优雅，还让管理一群文件不那么复杂。市面上通用的对象存储系统都包含下列文件信息，可以快速的管理大批文件。
filename / key value，就是文件的名字，存储资源的描述。
filesize 和createtime，文件大小和文件创建时间，文件管理和统计费用，也可用于文件筛选和判断。
Hash/MD5等等文件指纹，文件校验和去重使用。
Filehandle，描述文件实际在存储系统中的位置，这可能是物理或逻辑位置，这个信息一般不暴露给客户。
Mimetype或者其他的自定义文件标识，这是个扩展位，方便大存储顺路做简单数据处理。
Last Modified time其实是文件的createtime或meta信息的修改时间，对象存储所有的文件都没有修改，只有同名新文件。
不提供Owner信息，访问域名已经标识了多租户级别的Owner信息，开发者给自己的用户颁发token的过程中就完成了对应用级Owner的标识。
常规文件系统也提供了这些信息（hash值除外），但文件系统在亿万文件管理是太缓慢了，而且很多程序员并不熟悉如何调用这些信息，哪怕只有几万个文件，他们也更习惯把这些信息存在数据表里。现在有一个方便调用的API接口，这比自己维护数据表的成本更低了。
2.3 PB数据的业务场景
上文阐述清楚PB级存储必须用对象存储这种接口方式，什么样的场景会产生PB数据？即使我们现在只有10GB数据，我们也要做好成为PB用户的规划。
如果你要做个有百万以上用户级别的ToC应用，或者出货量过百万的智能硬件，每客户每月产生100M持久存储数据，一年就是1PB。最早的PB级用户大都是图床相册类用户，每月100M数据过去是100张低清照片，现在摄像头升级只能存30张照片了；中国的Icloud付费用户都在增加，其他有用户自生数据的应用就更多了。
在中国这么大人口基数的国家，只做一个百万级用户的ToC应用是很务实的小目标了。在没有高性价比存储的时代，这些应用只能牺牲用户感受限制用户存储数据，只能放弃有价值的客户行为日志。现在时代变了，该帮客户存的数据存起来，该为自己记得日志记下来吧。某些智能硬件厂商通过分析日志来精准广告投放和运营APP市场，他们已经可以赔钱卖硬件靠广告赚钱，但这有个前提你要先存下来几个P的用户日志。
ToB业务的用户规模远不如ToC应用，但文件的存储周期和可靠性要求十倍于个人娱乐用户。ToB业务涉及人员请注意一下，带宽和存储已经都降价了，连带着大数据和AI技术都在进步，以前不敢想的业务场景可以去实践了。比如高清企业视频会议和无人机航拍后人工智能做设备点检，还有一套套呼之欲出的IOT方案，这都是在促进生产力的进步。
近几年自然数据的产生和处理能力急剧提升，PB存储俱乐部里也有了一批高科技新玩家，我们愿意帮着他们改变世界。比如医疗信息化整改，一个区域的所有PX影像要集中存十年以上，而且随着医疗器械的更新换代，这些影像数据会越来越大。以前我们拍个CT片子是横着切5片，一个胶片20MB，现在我们拍个CT是纵切30片，一个胶片是200M。比如基因测序，每家基因公司都立志将全人类的基因记录一遍，录完人类的还有其他生物可以搞。比如气象和地质活动，现在有了更新的监测手段、更密集的监测网点，数据记录量也翻倍增加。这类方案对存储要求长周期平滑扩容，云服务厂商的对象存储会是这类客户的最佳方案。
2.4变通和妥协
对象存储并不是万能解决方案，它有解决不了的问题，也愿意为适应现状做兼容和妥协。
基于HTTP协议的文件传输，天然无法满足“大文件的小范围修改且实时落盘”这一需求，最典型的场景就是数据库的DBfile，以及视频原片的现编操作。即使我们费尽心力让对象存储把自己模拟成本地磁盘，不严谨的兼容POSIX接口，当你打开一个1G的文件修改1k并保存时，本地文件系统只修改1k文件，而对象存储会上传一个1G大的新文件。
数据库这类低延迟应用天生和HTTP协议不投缘，而数据库活跃文件也不可能到PB级，所以DBfile很难去尝试兼容对象存储接口。视频剪辑软件倒是有兼容对象存储接口的技术可行性，他们可以把20G大的原片分散成2000个小文件，但客户的需求还不够强烈，本地的带宽还是不够稳定，这需要假以时日。
对象存储会主动用Fuse/NFS/FTP等手段来服务工业级数据产生设备；比如厂家几千万卖出的医疗仪器只支持FTP协议，这些仪器不可能主动去兼容对象存储，那对象存储就来主动适应这些工业设备。这些数据生产设备对存储的需求也很简单，就像投递邮件一样写数据，根本不关心已经写入的数据如何管理，也极大降低对象存储兼容模拟的实现难度。
对象存储还会用Fuse/NFS/FTP等手段来服务一些传统客户的低负载低需求需求，以保证尽量减少客户的业务变化。比如说银行里依赖一套存储的应用有50个，其中5个高性能应用必须改用对象存储接口，而另外45个低需求应用可以沿袭旧的访问方式，否则换个存储要改50套应用是推不下去的。
3.如何采购对象存储服务
各家公有云都做对象存储服务，那么该从哪些维度选存储服务，我有一些思考和建议。不用带任何情怀和理想，一年内能达到的存储容量是用户分类的唯一标准，GB/TB和PB。同样也不带任何理想和情怀，企业采购云服务就是公平交易，不要奢求免费的蛋糕，我们只期望能物有所值就够了。
3.1 小型用户宽松心态
如果你是一个GB级用户，一年内存储量都不会达到1TB，这时候用对象存储只是为了方便开发应用，不用太多思考存储自身特性。
首先谈价格，100G数据的存储成本每天就几毛钱，我不想讨论如何节约一毛钱的问题。
对象存储和云主机没任何直接技术关联，它是一个独立到孤立的服务，典型互联网架构中，对象存储甚至不和云主机交互任何业务数据，云存储直通客户APP。
对象存储一般会接CDN，CDN是最成熟透明的云应用，你可以CDN和存储选一家，也可以只用存储做源站，技术上不会有任何限制。
云存储都对接多媒体处理，市面上的多媒体处理大都套用imagemagick和ffmpeg，各家的主体功能趋同，细节毛刺上区别的这个级别的用户感觉不出来，有新需求也会被礼貌性无视。
对象存储的业务形态很容易被平台方窃取数据，即使你做了数据加密也可以根据你的计费日志评估你的业务量，但你现在只有G级别的数据，暂时不用考虑太多厂商中立性。
小容量数据也很容易迁移，假设你要从云存储迁移100G的数据到虚拟机，总成本不超过300元，迁移时间也可以控制在一天以内。有了方便迁移这个特性，云存储平台有什么让你不爽的，直接迁走。
3.2 中型用户三思后行
GB级用户不在意的坑，TB级用户全部要踩一遍；而TB级客户在面对繁杂市场宣传，很难看透云存储服务的本质内容。对象存储都是用API接口调用，普通用户看不到也不关心群集规模和技术细节。大家读完本文以后可以更理性和警惕的评估云存储供应商。
首先说数据持久性和安全性不用太关心。云存储厂商都宣称数据可靠性超过10个9，在我看来各种SLA超过8个9就已经比第三次世界大战的几率还小了； 平台说自己能到多少个9，我们都笑笑就好，故障出来了平台总能找到理由的。你买最贵的EMC存储柜也不能保证100%不丢数据，怕丢数据要设计备份方案而不是寄希望于单一硬件或服务。
TB级用户同样不用太关心存储群集的性能，因为你是用HTTP协议访问一个广域网服务，广域网和客户端才是网络吞吐性能的瓶颈。几家云存储厂商在SLA里都没承诺速率，上行带宽本来就免费，而下行带宽都会走CDN。但是这类客户已经出现迁移困难了，假设你有200T数据要从某云迁到自己机房，如果你的迁移用IDC带宽是1000M需要20天才能完成任务。
上文是拨开一些企宣烟幕弹信息，下文是TB级用户最关注的问题。
1. 价格问题。
假设你有200T数据，每年的开销在30万左右；这里说谈价格不是让你死抠存储的价格是10万还是40万，而是注意存储会带来其他消费，比如说现在存储要计算CDN回源带宽了，比如说两个云存储互为备份带宽同步费用有多少。当前存储厂商是按需付费定期调价，短周期看大家都是在不计成本的降价获取客户，但长周期看寡头形成竞争会淡化，存储涨价是合法商业行为，而你数据量大且深度耦合平台业务很难搬走。企业服务市场没有免费蛋糕，我们要适当考虑超低价服务的风险。
2. 云端处理和分发能力。
当你的数据量到TB以后，单台服务器已经无法承载和处理这些数据了，你需要尽量借助云存储平台的处理和分发能力。我本来以为这些功能大家都会各平台都有，但试读者反馈还是建议我加上这一段。
云存储直接处理数据都是这样一个形态：文件输入来自于云存储，参数输入来自于客户的get和post请求，在云端做一些无状态处理，文件可以下载或存储到云存储，参数输出或者接口回调。常见的例子是图片实时打水印有损压缩后下载，视频异步转码另存，涉广告图片检查后返回特征码，日志文件检索特定字段，文件自定义加密解密等等。这些服务使用方便收费低廉，甚至在改变原有的开发模式，成为存储必备的核心功能点，但是这些服务使用过程中小坑不断。
比如说实时有损压缩图片这个功能可极大节省CDN带宽提高资源加载速度，客户端可以根据自己的设备、网络、应用场景决定要什么分辨率的图片，此功能带来了无与伦比的灵活性。但用户不可能是多媒体处理专家，很多应用场景细节根本就想不到的。比如你往我的平台塞个200M大图我是拒绝处理的，友商不管图片多大都敢去切图，但有30%几率是后台切图程序崩溃，让你等是十分钟才收到个50X的报错；比如说某些音频编解码规范应用了半个世纪，某款新出的手机可能会出兼容性问题。这类技能太生僻，云厂商培养技术人员都很困难，客户要靠自己评估厂商就更难了。我的建议是多发几个工单，看接工单的是技术人员还是商务客服，看工单处理周期和结果吧。
分发能力好理解，某网盘厂商一开始是把云存储挂载服务器后端，由服务器端的BGP带宽来负责网盘文件下载，后来改成云存储通过CDN直接给网盘客户端发数据，带宽成本降低到以前的20%。
3. 厂商的职业操守
前文刚一本正经的说云计算是企业服务，现在怎么突然又提到操守了？国内的云平台都是做互联网ToC业务起家，习惯用摆布个人用户的伎俩去招揽企业生意，近几年大型云平台屡屡爆出蛮横管理狡诈运营的丑闻。云计算是企业服务，云平台是我们的供应商不是我们的管理者。TB级用户正是业务高速发展的关键时刻，我们更要防备某些吃相难看的混蛋。
云存储相对业务简单，遇到野蛮运营的问题主要集中在窃取数据、估算业务量、恶意不兼容其他服务这三方面。
窃取用户数据指的是监守者自盗后自用，要是泄露给第三方那是安全事故可以直接报警抓人，但平台方自用用户数据很难抓现行。云存储里大都是多媒体数据，谁敢盗播打官司就好；日志文件加密了就用不了云端大数据分析了，但不挂个人信息的基因测序样本被偷了也不怕。如果客户真的特别害怕丢数据，云平台确实没手段能自证清白，谁偷过用户数据只能听业内风闻。
真正让用户头疼的是平台方会根据计费日志估算你的业务规模，就像小区保安总共能看到你何时出门一样。据不可靠传闻，某厂商本来能拿到某云厂商母公司数亿美元投资，自吹数据量有数PB，该司投资部去调了一下他们的消费金额就取消投资了。单一个消费总金额就这么麻烦,访问日志可以看文件数量、用户规模分布和大致的动作类型，一个新兴企业最好还是把业务分散在两个厂商那里，毕竟他们两家不能核对你的账单。
最后一条就是有些领先大厂直接压制，故意做技术无关的不兼容、甚至拒绝服务、甚至从其他层面正面打压业务。这里就不举例了，太明显针对单一厂商。如果只是技术不兼容那算和其他云平台恶意竞争，如果到了云平台明抢客户自身业务的阶段，技术采购决策人请把风险告知公司决策层，该妥协还是硬扛不是你的职责范围。
3.3 大型用户谨慎选型
大型用户即使只存储1PB，每年也要花100多万了；中小型客户只要做选型，而大项目不仅要选型和定制，还有更多技术以外的东西要考量。
首先同样说价格问题，大型客户比中小客户更难办，小客户是嫌价格贵，大客户却怕低价砸场。云存储服务不能违背商业服务的本质，甲方没蠢到敢让乙方赔钱做服务，但采购决策层更喜欢看谁的报价最低。数十PB的数据上云后基本下不来，平台方无论是提价还是降速，有的是追加预算的手段；如果对方真是赔本卖吆喝，成功了就会甩开这个包袱，失败了就直接倒闭。我谈PB级存储项目时，我很愿意分享不同底层技术带来的实际成本构成，为什么同样的价格我们还能挣钱而友商已经在贴钱，相关内容会在第四章节详细说明。
成功案例是很重要的决策依据，但这个依据很难考证真实性。厂商做过PB级项目但其实是一小群TB项目做的计费融合，厂商确实做过数百P的项目却和标准对象存储功能不通用，这类事情太多了，对象存储合同上不会有总容量，发票存根也只是简单的信息服务费。客户的成功案例必须是单一命名空间容量达到PB级别，并简要说明文件数量和主要读写场景。考察案例真实性的方法主要靠听对方能否自圆其说，甚至让多个厂商当面质疑，能逻辑自治的厂商终归还是靠谱一些。
大客户对云端数据的处理的要求比中小客户更简单，因为复杂业务功能可以自己做，还可以要求厂商为自己做定制开发。
大客户的数据一般都是存在于旧系统的，其迁移方案比小客户复杂，拉专线、寄设备、追增量、切业务等等方面都要考虑到。一般迁移方案是现有数百T数据，规划未来3年到10PB，数十个轻量应用对接代理网关继续使用，几个核心高负载应用改成直接访问存储。为了更好的发挥对象存储优势，厂商还要诱导客户使用云平台的各种新功能。迁移方案要靠谱必须说清楚所依赖环境、操作时间规划、各步风险评估、验证验收标准等信息。
大客户同样在于云平台的职业操守，但其反击能力要强于中小客户，因为他们不会用云平台的标准合同，而是自己订制合同内容。法律合同上能震慑平台的一部分小动作，但计费统计数据云平台还是会拿到，客户可以考虑多分几个供应商多做几个存储池。
3.4 何时选择私有云
对象存储一般是公有云服务，但是超大型国企、电信运营商、国家级项目、大型独立互联网企业、金融行业、智慧城市、基因、气象、医疗等行业都因特定原因使用私有云存储。
对象存储适用于私有云主要基于这三方面考虑：
建设成本。
公有云建设成本有三大头，服务器、IDC和公网带宽。公有云对比对中小型客户在这三方面成本有巨大优势，但也给自己保留了利润空间。很多客户能拿到比云厂商更低价格的资源，那可以拿掉给云平台留的利润，自建私有云存储。
网络通信成本。
这里提的网络通讯成本和前文的公网带宽并不重复，公网带宽是面向分散的广域网客户的，网络通讯成本是强调几个固定的大带宽消耗对象。假设你某个应用的数据读写速度是10Gb/s，云存储和客户端两侧的广域网带宽成本是巨大的，某些弱势运营商甚至要考虑网间结算费用。大读写速率的客户端和云存储会是固定长期合作关系，无论是内网互联、同IDC光纤、同城专线的成本都比互联网通讯的成本低很多。
数据安全等合规需求。
有些客户连计费日志都不想让公有云看到，或者确实有强安全性法规限制，或者只让采购资产不认可采购服务，那也会采用私有云的建设方式。如果本地数据做云端的容灾备份，或者多云厂商之间的权威数据源，这也是可行的方案。
私有云的输出形式有三类，分别是远程代维护、买软件和软硬一体化。买软件和软硬一体化交付大家很熟悉，厂商需要提供非常详实的交付文档，应对一切异常情况。但当前云存储软件的可维护性并不高，交付文档可能写不出来，远程代维护才是最便利的交付方式。按过去买硬件的习惯，离线运维系统都要巡检和计划内停机，其可用性比在线运维要低很多。厂商的驻场工程师只能做日常响应工作，让核心技术人员远程代维好过停业务等人来现场。现在几个硬件存储厂商也用类似的远程维护方案，他们的智能诊断程序会将群集状态信息自动发送给厂商，这泄密的风险和远程代维护是相同的。
4.自建/评估对象存储群集
免泄密声明：此文是我基于已知公开常识写的内容，我的工作经历是让我验证这些观点并感觉到了客户痛点，此文只谈架构不谈具体实现方法，并不涉及技术机密。
本章节都是架构技术干货，无论是要自建对象存储群集、采购私有云还是采购PB级公有云都需要评估厂商的技术架构是否可靠，如果您做其他分布式系统也可能会有所收获。
4.1 群集总览
计算机只是一个应用技术，最近几十年少有颠覆性技术革新，我们做的是架构选型和调优，通过放弃某些功能来获得更高更可靠的性能，而非设计一个新模式。为了实现高性能高容量的对象存储，只有将其在HTTP访问场景下做深度优化定制，让底层组件的功能简单甚至笨拙，才能实现足够的性能和稳定性。
首先让大家惊讶一下，我喜欢的对象存储每个节点看起来都有点土。
大部分服务器拆了硬盘后价格低于两万元，没有任何吞金怪兽级硬件。
分布式系统网络IO最珍贵，但为省钱我更愿意用几根千兆线做Bond。
只做入门常识级系统优化，没用专用文件系统也没写裸设备，据说每个节点有50%的性能优化余地。
整体结构可以简化到不需要画架构图的地步，群集有几十个功能项，你想合并成几个服务也行，想分成几十个进程也对。
因为有超高的容错性，所以群集自协商机制比较简单，嗯，应该说是简陋。
我们不买高配服务器，因为我们的技术是做公有云过来的，公有云定价不看成本只看友商的价格，合理花钱才能生存下去持续服务；我们不做单点极限性能优化，那是招不到架构师才走的歪路。这是最有性价比最务实的架构方案，我们练得是一招致命的杀敌功夫，不是翩若惊鸿的表演性武术。
一个基于http对象存储的架构场景有三个主要角色：读写代理、元数据、存储服务。
读写代理，客户端直接访问的Web server，它不存数据只是代理。
元数据，客户可见的Metadata信息和不可见的Filehandle等信息都在这里。
存储服务，实际数据落盘在这些服务器上，有不同的存储形式。
此外还有些辅助角色，简单列一下但不细聊了。
客户端SDK，简化客户访问，还能做一些容错遮蔽。
群集状态同步服务，99%类似Zookeeper。
鉴权认证系统
计费系统以及附属的计费日志搜集系统。
运维监控系统和资产管理系统。
核心组件设计
坚持有中心设计
很多分布式系统都宣称无中心设计，说有中心架构里到处是性能瓶颈和高可用单点。但我坚持有中心设计，有中心设计非常容易做文件管理和统计，群集的修复和扩容范围可控，支持异构存储。而所谓的性能瓶颈和高可用单点，在Http对象存储场景下都有成熟的解决方案。
为了让下文的系统设计更有目标性，我们先预设一个通用访问场景：
当前10PB的存储群集已有200亿个500k的文件，群集并发带宽20G，并发链接（含等待链接）5万个，客户每秒写入5000个文件，读取5000个文件，查询2万个文件的fileinfo，有5个客户在做五千万文件的list操作。
4.2.2 给元数据减负
元数据服务是个数据库，存储每个文件的key值、所属bucket、metadata、filehandle以及一些特殊标识。客户每次读访问、写访问、列表统计都会访问元数据服务，我们要充分考虑其性能和高可用问题。
首先元数据服务选型，因为各条用户数据的关联不大，没有任何全局排序对比算平均数的需求，推荐用文档型或列族型NoSql，但继续用关系型数据库少做些索引也没问题。
文档型Nosql一般是三个节点自协商谁是主从，且客户端会旁观整个选举过程，关系型数据库也有成熟的高可用方案，现在元数据的高可用问题算解决一多半了，读写代理来解决另一小办高可用问题。
我们看看元数据的访问需求究竟有多大？上文场景说的是每秒对数据库做5000个读和写操作，再加上2万个获取fileinfo的操作，用户猛然一看这频率很低啊！但每个文件500KByte大，5000个文件就等于20Gbit带宽了，有多少应用群集能是超过20Gbit带宽接入的？
在写库的时候，假设群集每秒接5000个创建文件的请求，在数据库看来就是在表尾做5000条数据的appended操作；单台Mongodb只要做一些常识性优化，配块SSD盘轻松达到1万QPS，案例中的5000个写请求对数据库没任何压力。
用户要读取单条Metadata数据的时候也只有文件名一个筛选条件，没有任何复杂的排序对比操作，这代表数据可以轻易分库分表，25000个读请求分到4个实例还有压力吗？
任何数据库都讨厌list操作，但存储计费和用户需求都会扫表。结合对象存储的list需求，我们可以做几个只读的从库就可以查询99.9%的准实时数据，如果你怕从库数据同步慢还可以单独做个最热数据表，在最热表上合并一下0.1%的新数据。当我们贴合场景去想，平台计费list操作不要求实时高精确数据啊，我给1000个文件晚计费1分钟很重要吗？一个客户要下载自己2000万条fileinfo信息，按5条信息1k算，这2000万条 fileinfo信息有4GB大，就算云存储能精确的0.1秒查完，客户有能力0.1秒下载完这些信息吗？
如果你觉得元数据服务压力还是大，那还可以让计费系统、读写代理都对查询结果做缓存，或者将数据库挂在成熟的Proxy背后做分库和调度。
我们的数据库能低压力运行，就是设计时充分理解适应了对象存储元数据这一简单需求。
4.2.3 灵活的读写代理
读写代理是整个群集保持松耦合高性能的关键点，这也离不开对场景的深度理解。
首先说读写代理的高可用、负载均衡和高性能，我们会在读写代理前面加几台Nginx，客户端到读写代理都是无状态连接。客户端可以通过LVS、单域名DNS轮询、多域名分散业务等方式将请求分散到多台Nginx，Nginx将请求交给任意读写代理都是能得到相同结果的。单个读写代理服务崩溃了SDK端会后台重试，直接访问API的用户会以为是自己网慢重新刷新。这么灵活的访问方式，有性能问题多堆几台机器就好了，20G带宽5万个链接很容易消化。
读写代理在访问客户时代表存储服务端，在群集内部扮演的可信客户端。一个分布式系统中，客户端是可控可信，可以知晓群集内其他服务状态，则群集设计会非常简单，可以做到所有组件都自动协商、自宣告状态、有序引导流量以及异常错误重试。
读写代理要访问元数据时可以看到主从库的选举结果，还可以从状态服务获取存储群集的自宣告信息。它不会访问已经宕机的数据库，也不会往已满的存储内写入数据。自宣告的状态信息总有意外时效的情况，这没关系，局域网内重试速度很快的，客户感觉只是多了几毫秒延迟。
读写代理还可以将一些读写策略、缓存策略写入自身配置属性，比如100k以下文件写到SSD存储池，优先写入新扩容存储服务器，某Bucket文件自动做异地复制，某后缀名的文件不缓存，某账户有特殊API语法等等。
综上所述，读写代理是元数据和存储系统的可控可信可减负的好朋友好客户。
4.2.4 存储的硬功夫
存储在元数据和读写代理的保护和调度下过滤了外部访问压力，每个节点都只关心存储本职工作就好。
对象存储群集内部存储可以分为四种，可四种混用也可只用一两个。
三副本存储，读写代理将数据写入到member1，member1一边落盘一边将数据通过网卡复制给member2，member2将数据传递给member3。这种存储实现原理简单，单链接速度上限就是单盘顺序读写速度，磁盘再慢也比网络块，插上十几块盘就能跑满本机网卡。这类存储大多作为纠删码大存储池的持久化写缓冲组件，单独使用三副本消耗太多硬盘了，即使不在意硬盘的价格，硬盘越多机器就越多组网就越麻烦。
数据库型存储，读写代理将数据文件处理成N多kb级碎片，然后塞入数据库中做持久化写缓冲组件，后端有消费者服务将数据取出另存到纠删码大存储池。我实践中不太推荐这种方式，因为对三副本存储没太大优势。
纠删码存储是老技术了，大家买的超强纠错的VCD盘片就用的本地纠删码技术。我们可以简单把纠删码技术类比成网络版Raid5，这种技术大大的节省磁盘，而且可以设置多块校验盘来提高数据安全性，是PB级存储的主力存储池。但它的缺点也很明显，因为数据要做聚合条带后重新编码，写入速度较慢；Raid5磁盘修复时IO放大问题在EC里同样严重；而且纠删码回收已删除文件的空间难度很大速度很慢。
SSD小文件存储，这其实是标准三副本存储的SSD版本，一般用来存储小文件，SSD盘再贵也比缓存服务的内存便宜。小文件存储的数据总量不大，一般在本盘存储即可，不用导入纠删码存储中。
上述存储手段只是落盘手段，作为存储组件还要通盘考虑下列问题。
磁盘故障时的修复性能。
商用磁盘都是按照36-60个月的使用周期设计的，假设你有6000块磁盘每个月要坏100块盘，天天坏盘天天修盘已经成为常态。厂商要保证损坏磁盘快速修复，避免修复周期内另外几块冗余盘一并损坏，又要保证磁盘修复时群集性能受不了太大影响。
当前大家都采购4T8T硬盘，按照磁盘顺序写入300M的速率，填满一个磁盘的数据需要10个小时以上，最通用的处理方案是将一块4T盘分为40个小PG，40个PG逃逸到40块新盘上速度就在30分钟以内,而且没消耗新磁盘太多IO。磁盘修复时的IO放大有解决方案但很复杂且涉密，本文不提及。我只透露前文不让做单节点性能压榨就是防着这类异常情况，http下载场景中引入缓存可以减少重复读取的压力。
群集动态扩容能力。
很少有项目是上线就建设50PB的容量，并在半个月内全部数据就位。对象存储群集刚建成只有几十个机柜几千兆带宽，后续群集容量和性能都要动态扩容。存储系统扩容后不要做无意义的数据重新分布，因为数据重新分布可以理解成磁盘修复，太容易出性能类故障了。我们不做数据再平衡，但磁盘写入时要有优先级，否则群集内各存储节点会受力不均而出现新的瓶颈，比如当前有四组存储，第一组用量90%，第二组50%，第三组10%，第四组刚新增用量0%。我们在读写代理那一层可以做策略控制，第一组存储不再写入数据，第二组存储低优先级写入数据，第三第四组存储主力写入数据。
如何提升读写性能。
对象存储场景里很少出现一个链接读写100G文件的情况，而常见的是几万个链接去竞争带宽资源，大家都慢慢读写。只要有100个并发连接，群集的访问压力会分布均匀。一个PB级存储系统，存储机怎么也有20台以上，每台主机提供1000Mb带宽用于对外服务，这就是20Gb总出口带宽了，群集默认性能就不会太差。数据都是顺序写入硬盘，SATA盘也能达到极高写入性能。读取数据的性能也不是大问题，互联网类型数据的缓存命中功率极高，一台缓存可以减负一大堆元数据和存储服务；大数据一下要读几百T的数据必然是多链接，每个存储节点都会分到数据读取任务的，而且应用要读这么多数据不会要秒级完成任务，五分钟内完成下载就是闪电速度了。
回收空间的性能
前文提到数据都是顺序写硬盘，这样文件删除时回收空间很慢，但4T盘浪费50%的空间也比买15K盘或者SSD合算，某些小规模或超有钱云存储都没做回收空间这个功能。
当文件有计划内滚动删除需求需求，比如说互联网安防监控，一般是用两副本或单副本群集扛性能，为回收空间要浪费50%空间，也有公司在开发快删专用的环形存储结构。如果数据进了纠删码才被删掉，比如说走了个PB级相册客户，那浪费磁盘空间的损失可能要持续半年以上。
数据去重问题
对象存储不做数据去重功能，看着简单的功能背后都有蛛网一样的复杂考量，元数据服务、计费服务、存储服务、增数据逻辑、删数据逻辑、回收空间逻辑、用户资源隔离逻辑都会因为这个很炫的功能被彻底改变。真正要去重的文件就是那些电影，随着版权保护的加深，电影只存原片盗版减少会是趋势，其他文件即使做切片去重，命中率也非常低。我们提供hash值让客户判断该不该删文件，该不该做文件映射就够了。
长周期软硬件换代
对象存储是付费企业级服务，并不是终身免费但匆匆关张的个人网盘。我们必须考虑十年为刻度的长周期维护问题，某种硬件停产了怎么办，假设系统内核停止维护怎么办？我强烈反对极端优化单点性能，就是因为单点性能极限优化必然和硬件、内核、文件系统都有深度关联。我推荐存储主力服务是应用层服务用户态进程，老中青三代服务器和谐运行，群集性能瓶颈本来就不在单点，不要给自己的软件无故设限。
冷存储问题
冷存储分真冷和低温两种类型，真冷存储就是用磁带、蓝光盘、可离线存储节点来存储数据，这样可以节省机柜电量，但这是个工程学问题不是计算机问题了。低温存储就是标准存储换更大更慢更省电的磁盘，通过硬件选型来降低硬件和机柜成本。
4.3 存储测试标准
前文我大量篇幅介绍对象存储和传统存储的不同，如果搭建一个私有对象存储群集，我们该做的测试也要贴合场景。
存储系统交付时，我会推荐做如下测试：
用户侧标准功能测试，如文件读、写、删除、获取metadata信息。
单链接读写速率测试。
一万并发连接读写速率测试。
群集长周期并发写入测试，既要击穿写缓冲池，又为其他测试积累数据。
群集长周期随机读取测试，注意是随机读取避免命中缓存。
随机关一台存储服务器，观测群集读写性能是否受影响，观察群集修复速率。
通过读取文件Metadata信息对元数据服务进行读取和并发性能压测。
随机关闭各角色服务器各一台，看群集功能和性能是否受影响。
同名文件大范围替换测试，观察文件频繁修改后是否会性能降低。
根据厂商承诺的空间回收策略做空间回收测试。
某些厂商没话题可聊就强调自己的IO和IOPS非常高，这就非常不专业了，HTTP接口的存储要谈性能也该谈并发连接和总带宽。
4.4 运营成本问题
当你要建设一个存储群集时，没有存储技术可以去买，但建完赔钱就不行了。评估TCO成本是要上公有云还是私有云，用哪家公司方案最合理的主要依据。
我们不能像买个存储柜一样简单算TCO成本，对象存储群集的成本有五大块：
硬件采购成本，一般占总成本的20-30%。
服务器和硬盘是一次性投入，按照五年报废周期折算。
机柜电力成本，一般占总成本的20-30%。
存储节点经常插几十块磁盘，都是高功耗的电老虎，五年机柜成本不比硬件低。
带宽接入成本，一般占总成本的是5-50%。
根据这个存储的业务类型可以确定带宽接入成本，最低可能只是个维护带宽加几光纤，最高可能是运营商的大客户。
资源闲置成本，一般占总成本的5-50%。
私有群集要计算多久才能填满空间，公有群集要为潜在需求预留足够资源。
人力/软件成本，一般占总成本的20-30%。
开发一套对象存储然后公有云磨练几年，这需要投入亿元以上，分摊到一个项目也有数百万投入。厂商的人力成本很多是用在压缩硬件、机柜、带宽、闲置成本上，节省了人力成本其他开销就会增大。
在千万级别项目投入里，金融成本也是很大的成本。建设一个存储群集的总成本会和买一套硬件存储柜的价格差不多，报价不便宜但考虑金融成本就很合算了。假设客户买一套硬件存储柜是一次性掏5000万；而对象存储群集硬件占比不高，机柜、带宽人力等成本都是按月缴纳五年才凑到5000万的。
拿着上述数据我们已经可以预估出新建一个存储群集的实际成本，我们拿这些钱和公有云价格进行对比，如果私有云成本比公有云高太多，我们也能说服采购决策层继续用公有云。
在群集运营过程中规模会受到IDC环境的限制，机柜和带宽不是想买就有的。电力也好机柜也好，IDC都是卖不出去资源就愿意接大客户，哪怕零利润总好过闲置；但如果资源都卖给一个大客户了，这个IDC也就没资源接其他客户了。我很少考虑100PB以上的存储问题，也有这方面考虑。有些工程师吹牛皮说做过EB级存储，让他基于常识说一下自己的硬件投了多少。
结束语
上文为我对PB级对象存储知道的一切常识，PB级存储需求离你我业务越来越近，大家早做准备各自努力吧。
