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

个人建议如下，能力经验有限，还请各位专家多多指正，在此谢过！

    1、由于银行影像内容管理平台的主要数据类型是 半结构化的影像数据 并且 随着银行互联网业务的迅猛发展需要影像平台的资源能够弹性地横向扩展及很高的图像读取性能。因此 传统的Oracle/DB2架构这种集中式一体化的架构及 有限的非关系数据结构的支持能力肯定是不适合作为 银行影像内容管理平台的！

    2、Hadoop 虽然是分布式架构，满足横向扩展能力，但是前期要针对Hadoop 特点进行影像平台开发，后期需要专门的技术人员进行运维，否则稳定性很难保障，人员投入成本会很高！

    3、分布式文档数据库，倒是一个非常不错的方案， 影像内容管理平台的开发成本相比  Hadoop 方案降低不少，而且在分布式文件存取性能，资源的弹性横向扩展，自动化运维方面都有着不错的表现！我们这边主要使用的  SequoiaDB  巨杉数据库，一款非常赞的国产的文档型分布式数据库！
    创始人 王涛，本 IBM DB2社区的远古大神wangzhounew，原 IBM 多伦实验室的专家！
    以下是他们影像平台的方案，您可以参考下：

金融影像平台应用

金融行业在业务运营中会产生大量纸质凭证，在信息化处理和监管要求下，这些纸质的凭证都需要扫描成影像文件并长期保存。随着互联网金融、流程银行、直销银行、移动作业以及集中作业中心等理念的深入推广，银行、保险等金融机构普遍需要建设统一的影像管理平台。

影像系统主要有以下的特点：

• 总体数量大：不同银行的规模，业务种类和上线的时间不同，业务系统中存放的文件数量往往达到千万级甚至数亿级。
• 存储成本高：影像系统占用的存储空间以TB为计，最高甚至达到PB级别，要同时为支持影像文件大量存取，以及要支持多业务系统，因此系统对于存储设备的I/O要求较高，造成影像平台系统存储成本居高不下，逐年递增。
• 生命周期管理不易：影像文件的存取通常发生在3个月内，一年后的查询调阅机率低，通常要定期卸载历史数据，使用冷介质进行离线管理，但数据可用性没保障。
• 备份时间长：数据需要备份保护，但海量小文件的备份效率很低，耗时较长，全量备份往往会超过备份窗口所能提供的时间。
• 历史影像文件查询难：因存储成本较高，对历史影像会进行离线归档，使得历史影像文件的查询调阅需要耗费大量的人力成本来完成，无法保证“快速响应”。
• 数据量逐年增加：随着业务品种的拓展、网点数目的增加、移动作业的新需求等，数据量随时间呈显著上升的趋势。这导致生产系统容量需求不断增加，需要不断扩容。
  
                                            基于SequoiaCM搭建的影像平台简要架构

针对这些挑战，基于SequoiaCM构建的金融行业新一代影像系统，全面解决了这些问题。包括柜面无纸化系统、会计影像系统等等。SequoiaCM搭建的影像平台能够提供给客户的价值包括：

• 影像数据弹性扩展：影像数据的存储和计算资源随业务需求动态调整，实现PB级别以上的存储，影像数据持续在线；
• 内容管理：丰富的内容管理功能，包括生命周期管理，内容数据存取，批次服务，版本控制以及检入检出服务等功能。
• 统一管理：影像文件数据和元数据统一存储，提升应用性能且简化运维；
• 自由检索：对于海量影像数据，做到多维度自由检索与实时查询，毫秒级别的查询效率；
• 数据安全：实现同城“双活”以及“异地容灾”需求，内容数据保证长效、安全、可用，数据安全保障大大增加，同时满足“两地三中心”等行业监管要求。
• 降低成本：采用低成本的通用硬件设备以及分布式架构，大幅度降低整体拥有成本（TCO）至原有ECM方案的1/3；

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

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

银行的影像平台数据就目前来看，一般会存放票据系统、信贷系统、核心系统、理财业务等相关的票据、单据以及高拍仪采集的一些影像数据。一方面它具备结构化信息，即票据、影像本身抽出的标识信息，另外一方面是完全的非结构化影像数据。目前有两方面读写要求，一个是高速传输、并发写以及定期归档的要求；另外一方面需要根据结构化信息迅速找到非结构化信息以供信贷审核、票据审核、集中授权以及其他类的一些业务所用。因此兼有结构化信息以及非结构化信息，单一的关系型数据库或者hadoop平台是不太容易解决的。

文档数据库兼具存JSON以及非结构化数据的功能，可以通过键值方式实现在同一套平台当中实现快速检索，可以通过分布式架构实现横向扩展增加并发吞吐量，从数据存储特点契合度和读写性能角度分析，应该讲都是比较合理的选择。

但是也需要影像平台的应用层针对文档数据库的调用接口进行相应的改造，最起码得把数据写入和读取接口改掉。而且需要很长时间的磨合优化，毕竟IBM Filenet虽然不受待见，也在银行的影像平台当中占有绝对市场地位很多年了，必然有可圈可点的地方，这些地方是需要我们在新的平台当中逐渐寻找和优化的。

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

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

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

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

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

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

这种半结构化数据，现在不建议采用oracle/DB2，一个是oracle、DB2这种商用数据库成本也比较昂贵，二是现在都提倡国产软件，自主可控，国家都提升到一定高度了，有合适的国产数据库软件，风险可控制的程度下，可以考虑选择国产数据库软件

银行影像平台这种半结构化数据，早期采用oracle/DB2多一点，但是随着互联网业务的增长，可能适应不了像这种半结构化数据的需求，而且oracle、DB2这种商用数据库成本也比较昂贵，但是比较成熟、稳定，如果采用合适的分布式数据库是最好的，但需要专业人士去维护，运维成本比较大！可以尝试hadoop或者mongdb这种数据库，加上合适的分布式存储！