在泰国工做那一年，我对象可好了，固然，象对我也很好，O(∩_∩)O哈哈~数据库
今天呢，我是来兑现我原来的承诺，和你们来解剖一下各大门派的对象（存储），看看哪一个才是你（非结构化数据）的梦中情人，嘿嘿。缓存
今天，咱们来说讲历史悠久的EMC家族的对象存储ECS，这里ECS可不是二传手的意思，而是指Elastic Cloud Storage。
安全
为何说ECS历史悠久呢，由于EMC在2001年就推出了内容存储Centera，后来在2008年推出Atmos，到2014年推出的ECS已是第三代对象存储了。因为2014年之后，S3已经成为对象存储的事实标准，所以，EMC从ECS才支持S3协议的。但因为现网中有众多的Centera和Atmos的用户，所以，ECS被迫支持原来的不少API，能够想象，ECS的历史包袱仍是很重的。
微信
ECS的产品架构层次仍是比较清晰的，从上到下依次是：
架构
ECS门户和供应服务- 基于Web的GUI，容许自我服务，自动化，报告和管理ECS节点。它还处理许可，身份验证，多租户和配置服务。app
数据服务- 支持对象，HDFS和NFSv3协议的服务，工具和API。负载均衡
存储引擎- 负责数据存储和检索，管理事务，数据保护和复制。运维
Fabric - 提供群集，运行情况，软件和配置管理，升级功能和警报。异步
基础架构- ECS的基本操做系统是SUSE Linux Enterprise Server 12或更高版本，用于交钥匙设备或用于商用硬件的合格Linux风格操做系统。分布式
硬件- 交钥匙设备或合格的商品硬件。
在数据服务上，前面咱们讲过，ECS除了支持S3外，还向下兼容CAS和Atmos，并且，也支持Swift。不过，若是是新用户，确定只用S3，不会选择那些过气的协议了。还有，ECS也支持HDFS和NFS协议，这个咱们后面再讲。
不过，ECS在对HDFS的支持这块，没有和其余对象存储同样，采用社区的S3A协议，而是本身作了一个专用的ECS HDFS Client。
这样的好处就是本身来实现HDFS语义对本身对象的访问，通常都会比S3A有更好的性能和更多的功能。业界对象存储采用专用HDFS Client来链接对象存储除了EMC外，还有华为和XSKY，也是这个思路。
因为对象存储大部分都具备多站点的能力，所以，Hadoop用户通常采用ECS对象存储来作灾备，也能够实现多个数据中心同时分析。
采用存算分离，好处不少，特别是EC（纠删码）在对象存储里面很是成熟，可是在Hadoop里面算是比较新的特性，不多看到用户在生产系统里部署，主要是硬盘故障的时候重构时间太长，运维比较复制。生产系统用三副本，形成几乎全部的Hadoop项目都面临空间不足的问题，但若是一直扩容容量，则有HCI同样的问题，计算也要跟着作无谓的扩容，形成资源的大量浪费。
ECS内置了对NFS协议的支持，而且支持8个站点的统一命名空间，支持全局锁，支持NFS|HDFS|S3之间的互访。
ECS的Chunk是固定的128M，管理的粒度有点大。咱们知道Ceph的缺省Chunk大小是4M。
ECS的数据管理采用B+树，支持用户自定义属性反查，可是限制比较多，每一个桶只能有5个索引段，并且建立完成后就不能修改了。（原来的版本手册写了这些限制，但最近ECS今年又发布了新版本，不知道是否仍是有这些限制，你们测试一下就知道了）。
因为ECS不支持SSD作写缓存，和其余SDS很不同，它用内存作写缓存。但因为内存没有掉电保护，所以，ECS须要和Oracle数据库同样，在回应写完成前，必须完成日志的落盘。这种机制形成了数据双写，性能比较差。所以，EMC也打算在今年的新版本也要支持SSD作写缓存了。
ECS的索引数据采用3副本的方式来保证其安全性。
但数据保存所有采用EC（不支持副本）。写以前数据会压缩，若是对象大约128MB（Chunk的大小），就直接EC。若是不是，就先写三副本，而后异步作EC。这样作的好处就是提升小文件的性能。
而读嘛，接受读请求的节点先找索引所在的节点，而后再找数据所在节点读取数据，返回给host。所以，通常状况，一个读流程须要通过三个节点处理，IO访问路径长，请求访问一个对象须要作屡次重定向磁盘访问，虽然能够借助于缓存元数据改善，但大规模随机访问状况下，缓存效果可能通常。
ECS还支持跨站点作EC，这种状况虽然空间利用率上升了，但对站点的带宽时延都有比较高的要求，特别是某个站点故障的状况下。所以，国内我了解不多这样的部署方式。
后来，EMC也认识到这样的问题，在3.1版本推出了第三站点容灾only特性，解决用户想花比较少的钱实现三站点容灾的问题。
ECS的数据复制虽然是异步的，可是元数据复制是同步的。这样，从用户角度看，数据是强一致的。但在这种方式若是主站点故障，仍是会丢数据的。
Box-Carting是ECS的小文件归并功能，ECS在内存里把小文件归并为2MB大小再落盘，提升写性能。
至于本地数据保护，ECS只支持12+4和10+2两种保护方式，灵活性比较差。
ECS也支持和IBM同样的紧凑型EC，减小初始节点数。不过，ECS要求4节点起，而通常分布式存储都是三节点起。
因为ECS支持跨站点EC，所以，站点越多，利用率反而越高，这和通常传统存储数据复制的弊端正好是反过来的。不过，前面也讲过，中国好像这样部署的企业客户很少（公有云比较多）。
ECS的数据可用性只宣传3个9，太实在了，实在是泥石界的一股清流啊。其余的厂商巴不得都宣传6个9以上。不过，可贵EMC不怕友商拿来控标的吗？O(∩_∩)O哈哈~
ECS的组件都是封装成容器，采用容器的方式部署。
ECS虽然支持纯SDS的方式，但销售更喜欢推广一体机，这样销售额比较大啦。ECS没有内置负载均衡功能，并且5节点起步，价格有点小贵。
ECS在扩容这块特性不是太丰富，重平衡的时间可能比较长。
咱们看到，ECS今年有两个小版本，在3.3支持SSD作Cache等重要特性，3.4支持新硬件。我前面的分析都是基于去年的版本，新版本我尚未拿到太多资料。
从长远来讲，ECS将来会支持全闪，支持混合云等特性。
ECS都是Gartner和IDC相关象限的领导者。
Gartner对ECS的UI和容器架构比较欣赏，但仍是指出一些问题。
在产品关键能力得分上，只有管理能力作到了业界最佳。
总体来讲，我感受ECS功能仍是比较丰富的，好比在跨站点EC和数据强一致这块作了很多工做，可是，因为国外厂商通常把对象存储定位在保存温冷数据上，其对性能不够重视。好比ECS刚刚才支持SSD作Cache，小文件归并策略太简单了，不支持副本作数据保护，不支持整池扩容和重构QoS等。
好了，我今天就和你们分享一下个人ECS学习笔记。再次声明一下，全部的资料都是我在6月份我在美国期间，从网上收集相关素材学习概括出来的，全部的观点仅表明我我的观点，其中确定有不少错误的地方，欢迎你们指正。
若是你们这样的分享对你们有用，我打算下一篇写IBM COS。之后我每写完一篇，就发起一个调查，看看你们是否找到了本身理想的对象，^_^
若是你们以为ECS不够理想，具体哪些方面知足不了你的要求呢？欢迎在留言里留言。惋惜微信的投票只能作选择题，不能作填空题，哎。
好了，今天就简单解剖到这里。若是你们还有须要当面和我探讨的，我将在12月4日的中国存储峰会等候你们。4日下午有一个容器存储的分论坛，我有一个关于容器存储接口历史演进的演讲，欢迎你们来捧场。
你们能够扫描上面的二维码参会，如今会议日程已经出来了。
本文分享自微信公众号 - 高端存储知识（High-end_Storage）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。