争议 | Oracle/DB2 还适合现在的银行影像内容管理平台吗？

争议 | Oracle/DB2 还适合现在的银行影像内容管理平台吗？

来自twt社区同行交流，欢迎更多同行参与交流

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

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

银行IT从业人员都非常熟悉影像平台这个系统，它是为开户、理财、票据、信贷等业务系统提供非结构化&半结构化影像数据存取的平台，传统都以IBM的Filenet&关系型数据库为基本架构，

但是随着影像数据的快速膨胀，这些数据再次读取的效率明显下降，主要原因在于文件树的存储架构和数据量级的不匹配，另外结构化信息和非结构化信息分离的架构也导致了数据安全性及存取复杂度的提高。

另外企业也为此需要付出更多的NAS存储空间成本。因此大家开始探寻一条新的路子，大家开始关注文档数据库，比如以MongoDB为基础的各类产品；也有人开始关注大数据平台，例如以hadoop为基础的各类产品。部分企业早已开始了尝试。那么，从以下几个维度来看，这几种架构哪一个更适合金融企业呢？

1.投资成本维度。

2.平台可靠性维度。

3.横向扩展能力维度。

4.与银行应用衔接复杂程度的维度。

5.运维复杂度维度。

问题来自社区会员@赵海 技术经理，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。

* “争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点

@孔再华 中国民生银行 数据库运维工程师：

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

投资成本维度：

分布式对象存储采用低成本的服务器和存储搭建集群，软件甚至是开源的没有购买成本。

平台可靠性维度：

现在的对象存储还不够成熟稳定。不过分布式存储设计上就是为了高性能和高可靠性。

横向扩展能力维度：

横向扩展能力本来就是分布式对象存储的卖点。

与银行应用衔接复杂程度的维度：

通过与关系型数据库相结合，改造影像文件存取的衔接是比较简单的。

运维复杂度维度：

从运维角度来说，引进分布式对象存储增加了运维复杂性，但是这却是不得不开始的进程，因为对象存储就是为此而生的，未来数据的存储将会在场景化上越来越细分，技术产品也是相应如此。

@冯岩 银行 数据库管理员：

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

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

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

3、分布式文档数据库，倒是一个非常不错的方案， 影像内容管理平台的开发成本相比  Hadoop 方案降低不少，而且在分布式文件存取性能，资源的弹性横向扩展，自动化运维方面都有着不错的表现！

@freebile 金融行业 数据库运维工程师：

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

@张文正 dcits 系统工程师：

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

@cpc1989 某保险公司 存储工程师：

谈一些个人看法：

从业务角度来看，多个业务流程、多种类型交易都离不开影像平台，属于关键业务节点，可靠性可用性的优先级较高。

从架构方案角度来看，传统架构中的非结构化数据与其元数据是分开存储管理的，而后端如果采用NAS存储的方式，有一定的性能瓶颈，扩展能力较弱。但这种架构灵活性还是可以的，后端存储方案可以根据实际情况来优化，应用层的改造较少，采用对象存储来做扩展也是可以的，由于都是采用的很成熟的方案，平台整体的稳定性和可靠性都较好；而新的架构实现的是统一管理，毫无疑问需要重构应用的数据持久层逻辑，分布式的扩展能力较强，引入新架构及其内部复杂的组件会带来运维的复杂度。

从技术自主创新角度来看，采用新架构的可行性较高，也是很好的尝试，方案成本有优势，也利于技术队伍培养。

@wangzk0206 scrcu 数据库管理员：

针对现在越来越依赖影像平台的金融机构来讲，传统的Oracle/DB2方式感觉已经不太合适。构建影像平台还是要考虑多副本方式存储，而Hadoop架构组件过于复杂，后期维护难度较大，稳定性有待提高。

@lcc 城市商业银行：

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

> @赵海：>> 影像平台里面的数据不仅仅是非结构化数据，还有一部分是用来标识和诠释非结构化数据的结构化信息，这些信息之前都是以二维关系表的形式表示的，Hadoop似乎不太好解决结构化信息的存放和检索吧？列式DB似乎不太适合这类信息的存储和检索吧？>> @lcc：>> 行业需求可能比较类似，但具体方案还是要结合规模及人员it能力等因素进行决策。

@lulihuan1987 张家港行 数据库管理员：

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

对于规模和负载较大的话，可以尝试采用大数据平台对接图像平台。

> @saric：>> Oracle/DB2 组件复杂太多过重，在当下IT飞速发展的时代下已经逐渐不适合非结构化数据存储。

@jason2006xu 昆仑银行 技术经理：

1、索引数据建议用结构化数据库如DB2/Oracle。

2、非结构化数据如图片，建议用Hadoop大数据平台。

> @赵海：>> 影像平台是需要把这两部分东西集中在一个平台的，而且传统的架构就是基于db2/oracle + Filenet + nas 实现的，现在这两部分分开，那应用取一次数据岂不是需要访问两种不同类型的平台，取两次索引？hadoop大数据平台的地址信息和关系数据库里面的二维表数据关联是不是也是一个难题呢？

@huijx 某银行 系统架构师：

个人认为Oracle/DB2和分布式数据库在本项目中并非对立的，而是可以共存的。

分分布式数据库专注于文档的存储，oracle/db2作为前置库，专注于提供目录、元数据、检索信息等，当确定需要提取文档时候再将请求转发到分布式数据库，提取到文档后直接发送到前端应用。

个人认为这样的话两种数据库的特点都能发挥出来。

@冯万里 Huawei 数据库架构师：

两个观点：

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

2、 从技术角度看，影像属于非结构化数据，更适合使用NoSQL数据库。

@赵海  技术经理：

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

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

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

@孙伟光 中国金融电子化公司 IT顾问：

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

@huawei851120  江苏省农村信用社联合社 系统工程师：

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

@saric FNT 系统架构师：

我个人认为，银行的影像内容管理平台，非结构化数据，不论从成本还是运维方面，更适合直接上第三方云厂商的金融PaaS云 进行托管，有三点看法：

1、技术上：建议采用Hadoop、mongoDB，不要用传统关系型数据库，成本高昂，运维复杂。

2、合规上：使用金融Paas云已经能符合，银监会等保要求。

3、高可用上：金融云已做到多可用区的容灾，无需银行本身再投入成本建容灾。