金融行业影像内容管理平台存储选型，XSKY、Ceph商业版、SmartX分布式存储软件，该如何选型？

投资成本维度（软件成本、硬件成本、运营成本、存储利用率等方面）。

Xsky & Ceph 基本上都是软件解决方案，硬件自己采购，SmartX多数是软硬一体解决方案，同配置，同节点，同周期，同维保可以出一个成本分析表进行比较。

平台可靠性维度（分布式算法安全性，扩容安全性，故障恢复机制等）。

Xsky是在原生算法之上进行了较大的优化，尤其是在性能方面；Ceph可以认为他就是原生的算法；SmartX基于分布式DB的算法进行改进，但是改的是偏应用的机制。

从原理上将，Xsky性能更优，从安全上Xsmart更优。

横向扩展能力维度（扩展规模、限制条件、复杂度）。

很想扩展能力，从官方材料公布的理论节点规模来看，Xsky会更高一些。smartX规模小一些。

与银行应用衔接复杂程度的维度（应用调用复杂度，应用需要修改的多少和难易）。

Xsky和smartX在上层衔接更好一些，提供接口转换层，比较容易对接各类应用需求。

运维复杂度维度（生态、运维工具等）。

Xsky & Ceph 底层都是分布式对象算法，smartX相对来讲是一个多元素融合体，复杂一些。

随着数字化的进程、法规的日趋规范和严谨，票据和影像整成爆炸式增长，给传统的影像内容管理平台，特别是以NAS为存储底座的系统，带来了众多挑战：

1. 树形目录结构的限制
2. 海量文件数量带来元数据挑战
3. 新应用场景适配度差
4. 原生WORM、数据保护的要求
5. 软硬件解耦的成本优化需求

以上这些点都是NAS较难解决的痛点，而对象存储正是面向这种场景而生，能很好的应对。因此金融行业的票据和影像业务正在加速从NAS向对象存储迁移，这将是对象存储和软件定义存储打入金融行业的重要据点。行业内众多创新性部门早已开始拥抱对象存储，市场上不乏将影像内容管理平台迁移到对象存储的案例。而根据了解，SmartX暂时还没有对象存储产品

1. 投资成本维度
   Ceph等软件定义存储的方案将传统存储厂商的硬件绑定和黑盒解开，可以大幅节省采购成本。XSKY的存储产品，还能提供高效、易用、智能的运维系统，来大幅降低运营和管理成本。这也是开源Ceph相对欠缺的地方。对于金融票据等海量小文件的场景，如何更好的权衡性能和成本之间的冲突，也是原生ceph所不具备的。XSKY可以智能的对小文件进行缓存和合并，既能得到SSD的性能，也能利用HDD的顺序写入和EC的低成本优势。XSKY还支持数据分级存储、数据流动策略，数据全生命周期管理，根据数据的冷热程度将数据在集群内部不同介质，甚至外部公有云、蓝光、磁带存储之间调度。
2. 平台可靠性维度
   Ceph提供的CRUSH算法在众多应用中表明它能很好的应对不同等级的硬件故障带来的数据丢失风险，在单集群的可靠性保障方面，XSKY还可以提供亚健康检测、扩容QoS控制等功能，同时支持双活、两地三中心、多站点等部署模式，进一步保障数据安全和业务的连续性。
3. 横向扩展能力维度
   Ceph从原理上看接近无限扩容，但在实际项目中随着集群规模的增大和对象数的增多，会带来性能和稳定性下降、重平衡范围过大等众多问题。这也是XSKY的存储产品重点优化的地方，不但单集群的扩容上限和可维护性大幅提升，还支持无需数据重平衡的整池扩容能力，桶中对象数据自动在多个数据池中分布，还能同时进行多集群、多站点的部署和管理。
4. 与银行应用衔接复杂程度的维度
   S3协议已经成为事实上的协议标准，围绕着S3出现了众多SDK、管理工具、终端应用，应用从传统架构迁移到对象的工作变得越来越简单。同时XSKY的存储产品还能提供商业化的NFS、HDFS互通等功能，可以进一步简化应用平滑演进、迁移的工作量。
5. 运维复杂度维度
   XSKY存储产品提供统一的可视化管理界面，可以直观地查看到集群的状态、硬盘的使用情况等。同时还提供丰富的管理API，可以无缝对接第三方管理平台。能够支持X86和其他架构平台在单一集群部署管理，包括鲲鹏、飞腾、海光、兆芯等，在操作系统上，支持CentOs Kylin、openEuler等，极大地降低了多厂商设备管理的困难度，为国内企业实现信息创新提供有力支撑。支持免人工干预的磁盘、主机自动故障检测和报警，支持硬盘点灯、硬盘重建、硬盘漫游等功能。
   在对象存储数据管理方面，s3cmd、awscli、S3 Browser等工具已经应用广泛，可以进行基础的对象存储数据管理。XSKY自研的S3 Console，提供了远优于S3 Browser商业版的用户体验，同时能进行对象存储的管理配置工作。XSKY还能提供数据处理框架，应用不但能存好数据，同时能用好数据。

首先，要明确该技术选型的侧重点，是仅仅作为影像内容管理平台的存储选型，还是所有非结构化资源存储池的选型，明确这个侧重点非常重要。下面我大概说下自己的想法：
如同你描述的几个考虑维度，当侧重点不同的时候，这几个维度的重要性也不同。根据你的描述，我假设你仅仅是为了替换点原有基于NAS存储的影像平台存储引擎，那么， 投资成本维度 、 平台可靠性维度 、 横向扩展能力维度 、 运维复杂度维度这几个维度，其考量的重要性是低于“与银行应用衔接复杂程度的维度”这个维度的。
如果是替换掉现有的影像平台存储引擎，那么平台与新存储引擎的对接、新老存储引擎之前数据迁移的难易程度，这些才是最头疼的问题。甚至你已经选型了一个性价比高、性能强的产品后，发现无法与老的影像系统对接，或者说，老的影像系统需要非常巨大的人工去改造，最后盘算一下，人力成本远高于新平台建设成本，这样就得不偿失了。
碰到上述的情况，更应该去考虑是否有成熟的迁移方案和仅有少量的工作量，比如据我所知，信雅达影像平台的存储引擎更换，就有部分成熟的平台和案例，这样你拿来就用会减少很多不必要的麻烦。

如果单纯的是为了采购非结构化的存储引擎，那么个人建议，除了自己做POC测试，最好能找使用相同产品的同业去询问使用情况，目前市面上的分布式存储引擎，都有部分金融案例，根据他们的金融案例去问问真实上线的情况，这样才是最好不过的，毕竟每个厂商来，都能举个自己公司TOP的排名，而且POC阶段很多坑是没办法发现的。就我接触的厂商，多数都是基于CEPH或者所谓自研单技术原理和架构和ceph差不多的，因此在性能、扩容性等方面，差距不会非常大，重点考虑运维、可视化、易用性的评测

个人理解，如有不对欢迎讨论，一起学习

有钱上红帽，没钱上smartx，就这么简单

个人想法，分布式对象存储提供NAS接口，是否可行 ？