为什么说一桶千亿已经是对象存储的基本需求？

单桶千亿需求爆发

随着数据量的增长，存储系统需要不断地扩展，以此满足业务的需求。面对存储扩容场景，主要涉及到数量、容量及性能多维度的扩容，单一地实现某个维度的增长，难以满足业务实际的存储需求，业务应用往往需要适配多套存储系统。例如：

1、某涉密单位，平均文件大小为35KB，日均数据增长1.1亿，为了满足其半年200亿数据存储需求，规划了200块SSD存放元数据信息，受限于硬件选型每个节点只能接入2块SSD，因此需要100台服务器支撑其海量小文件的存储，多数存储厂商都反馈该规模超过单集群上限，性能无法得到保障，需要客户将业务进行拆分；

2、某自动驾驶客户，平均文件大小2MB，日均数据量增长100TB，约5000万文件，数据需要永久存储，在半年内的规划即达到单桶40PB的规格，并且希望这些数据都保存在一个桶内统一管理；

3、某省级视频云平台，接入60万家用监控摄像头，每个设备每10秒生成一个文件，规划的对象总量达到了360亿，业务系统在设计时采用公有云架构，仅支持单个存储桶，客户也希望所有数据采用单个存储桶进行统一管理，如统一配置生命周期规则进行数据清理等；

……

为了保证存储的性能、稳定性及可靠性，主流存储厂商通常会对单集群、单个桶等规格做出一定的约束限制，拥有海量数据的客户业务不得不拆分进行多个集群数据存储及访问管理，由此大大增加了开发、运维的复杂度。

XEOS 下一代对象存储V6版本，创新性地引入了全局统一的分布式元数据集群，使用一套对象系统真正意义上解决了存储规模的局限性。

XEOS V6 支持元数据和数据存储节点融合部署或分离部署独立规划：

• 采用可横向扩展的分布式元数据集群存储元数据，提供全局统一命名空间，有效解决海量小文件元数据瓶颈，直面未来；
  
• 允许接入多种异构存储平台存放数据，突破了厂商、存储规模以及地域限制。

分布式元数据服务

基于PAXOS共识算法实现分布式集群，提供海量对象元数据信息的存储。

• 单桶千亿规模，性能稳定，满足业务对存储的扁平化要求；

图例说明： 在对象数量从0到1000亿的增长过程中，请求OPS、带宽、延迟保持稳定

（性能监控曲线向下的毛刺是因为压测工具无法支撑千亿量级的数据压入，只能分批压入导致）

图例说明：对象数达到1000.75亿时，请求OPS、带宽、延迟保持稳定，与空桶无异

• 服务高可用，支持同城多活，异地主备；

• 主备部署模式，故障自动切换及恢复，降低运维复杂度及人工成本；

• 多个数据中心统一视图，强一致读写访问；

• 元数据访问性能大幅提升，频繁重度的List等元数据操作对底层分布式存储的冲击大大降低。

异构存储平台

在统一的元数据管理架构下，XEOS V6 接入多种异构存储平台，如对象存储、云存储、NAS、蓝光、磁带库等，更好的与企业已有存储系统共存，实现纳管，同时也避免了单存储平台线性增长的瓶颈。

• 通过存储模块化设计，解耦底层硬件能力，数据存储集群内实现了一池多芯，单个存储池跨CPU架构，快速适配整合异构硬件平台；

• 通过整池扩容机制，实现集群内业务无感知的数据扩容，避免数据重平衡和木桶效应对业务系统的影响；

• 单桶数据可以跨多个数据存储集群存放，打破单一存储集群规格上限约束；

  
  

• 支持多家厂商的存储平台，实现存储厂商解锁，帮助客户业务更平滑地过度到使用对象存储，同时解决纳管利旧的困境。

多站点容灾

• 支持站点级别的故障冗余，业务多活，数据允许在多个站点同时并发写入；

• 站点间同步策略支持配置数据集及同步方向，满足不同数据分发、汇聚需求。其中，数据集灵活定义，支持：整桶、前缀、元数据、标签、对象拥有者划分数据集，实现不同数据使用不同的站点间复制策略，例如：核心标签数据同步汇聚到中心站点进行备份；指定前缀的数据分发到多个站点就近访问；

• 根据业务数据一致性敏感程度，可以通过代理远程访问获取最新数据或者配置就近访问，直接读取本地数据，提高数据响应速率。

XEOS V6 通过全新的存储技术手段，构建了稳定可靠的海量对象数据存储服务，实现了跨地域按需访问，消除了命名空间、单一站点、单一存储池、单一集群、单一存储平台的限制，满足企业日益增长的数据存储需求，能够帮助企业更好地存储管理海量非结构化数据。

END