银行影像内容管理平台选型，是传统的Oracle/DB2架构，还是分布式文档数据库，还是基于Hadoop的大数据平台？

个人一些经验见解：
银行影像平台这种系统，一般在做新建或重构时，在应用层都会选择微服务分布式架构，自由研发团队强的可选择自研，自主可控能力强。影像件系统数据一般为温冷数据，大多采用分布式对象存储的方式进行海量数据的存储，上层应用通过S3的接口与分布式存储进行交互，分布式存储一般分为缓存池和数据池，对于海量数据场景的处理性能相对比较好。影像系统一般涉及到联机业务，必须满足双活或灾应用级灾备，对于数据存储双活建议使用同产品进行实现，异构的产品存在不可预估的风险。

oracle/DB2 这种结构主要是早期传统架构，成熟稳定，但是在现在去Oracle/db2这些国外商业产品的大背景下，选择使用国产的数据库加minIO这类解决方案可能更加合理。

我们使用的第一代影像平台，数据库用的是DB2。后来业务部门推广收单业务的时候，需要将大量商户的营业执照等证件信息存入，系统速度非常慢。几年前对第一代影像平台进行了改造，以Oracle来存放结构化的数据库，辅以对象存储来存放图片、影像等文件。对象存储适合存放数以亿计的图片、影像等小文件。优点是对象存储的成本低，容量大。缺点是，应用程序在处理的时候需要先访问Oracle数据库取得影像的法人行号、支行号、类别号和ID后，再去对象存储去拿到真正的影像。处理流程复杂了，在进行灾备建设的时候，只能在灾备中心在重新搭建一套对象存储，和生产中心每个一段时间进行同步一次。未来如果建设第三代影像平台的时候，期待利用分布式数据库来替代Oracle+对象存储的方式。

我个人认为 银行的影像内容管理平台，非结构化数据，不论从成本还是运维方面，更适合直接上第三方云厂商的金融PaaS云 进行托管，有三点看法：
1、技术上 建议采用Hadoop、mongoDB，不要用传统关系型数据库，成本高昂，运维复杂
2、合规上 使用金融Paas云已经能符合 银监会等保要求
3、高可用上 金融云 已做到多可用区的容灾，无需银行本身再投入成本建容灾。

对于规模和负载不是太大的话，可以采用集中式数据库Oracle/DB2/MySQL存储图像索引信息，采用开源分布式存储或者商用对象存储存储图像信息，这样实现成本较低。
对于规模和负载较大的话，可以尝试采用大数据平台对接图像平台。

影像平台的数据是非结构化数据肯定不再适合放在db2oracle这类关系型数据库中。即便以前曾有使用大对象存放的先例，但其实是不适合的。那么现在这类数据是选择放在文档数据库中，还是Hadoop上，或者是分布式对象存储里。我个人觉得从容量，性能，成本等各方面来看，分布式对象存储会更适合一些。

投资成本维度。
分布式对象存储采用低成本的服务器和存储搭建集群，软件甚至是开源的没有购买成本。
平台可靠性维度。
现在的对象存储还不够成熟稳定。不过分布式存储设计上就是为了高性能和高可靠性。
横向扩展能力维度。
横向扩展能力本来就是分布式对象存储的卖点。
与银行应用衔接复杂程度的维度。
通过与关系型数据库相结合，改造影像文件存取的衔接是比较简单的。
运维复杂度维度。
从运维角度来说，引进分布式对象存储增加了运维复杂性，但是这却是不得不开始的进程，因为对象存储就是为此而生的，未来数据的存储将会在场景化上越来越细分，技术产品也是相应如此。

1、索引数据建议用结构化数据库如DB2/Oracle。
2、非结构化数据如图片，建议用Hadoop大数据平台。

个人认为oracle/db2和分布式数据库在本项目中并非对立的，而是可以共存的。
分布式数据库专注于文档的存储，oracle/db2作为前置库，专注于提供目录、元数据、检索信息等，当确定需要提取文档时候再将请求转发到分布式数据库，提取到文档后直接发送到前端应用。
个人认为这样的话两种数据库的特点都能发挥出来。

两个观点：
1 从行业趋势看，传统行业去IOE进入深水区，技术创建不断，使用传统的Oracle、DB2一方面不能满足数据量指数级增长的要求，另一方面成本也是不可忽略的因素，性价比不高，且会带来扩展性难问题 ；

2  从技术角度看，影像属于非结构化数据，更适合使用NoSQL数据库，类似华为的GaussDB NoSQL、阿里的NoSQL类产品、巨杉的 SequoiaDB等都可以作为选型考量。

各个银行的体量不尽相同，架构也是各有差异，对于存储的数据选用NAS架构,对象存储，分布式存储还是如上的的5个维度，需要各自根据实际情况进行评估考量。目前接触到的银行还是以传统的Filenet&Oracle/DB2架构为主，少数看到技术底蕴丰厚的尝试采用新的架构，我更觉得适合自己架构的才是最好的。