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

谈一些个人看法：
从业务角度来看，多个业务流程，多中类型交易都离不开影像平台，属于关键业务节点，可靠性可用性的优先级较高。
从架构方案角度来看，传统架构中的非结构化数据与其元数据是分开存储管理的，而后端如果采用NAS存储的方式，有一定的性能瓶颈，扩展能力较弱。但这种架构灵活性还是可以的，后端存储方案可以根据实际情况来优化，应用层的改造较少，采用对象存储来做扩展也是可以的，由于都是采用的很成熟的方案，平台整体的稳定性和可靠性都较好；而新的架构实现的是统一管理，毫无疑问需要重构应用的数据持久层逻辑，分布式的扩展能力较强，引入新架构及其内部复杂的组件会带来运维的复杂度。
从技术自主创新角度来看，采用新架构的可行性较高，也是很好的尝试，方案成本有优势，也利于技术队伍培养。

针对现在越来越依赖影像平台的金融机构来讲，传统的oracle，db2方式感觉已经不太合适。构建影像平台还是要考虑多副本方式存储，而hadoop架构组件过于复杂，后期维护难度较大，稳定性有待提高。目前金融机构用的比较好的是采用的巨衫数据库。个人建议！

Hadoop平台是一个很好的解决方案，但维护复杂度比较高，涉及组件多，对维护人员的技能水平要求较高，感觉不是很适用于规模相对较小的银行。

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

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

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

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