用户案例 | 分布式数据库影像管理最佳实践

巨杉数据库 2020-06-12

1550

分布式架构+多模正在成为新一代数据库技术的主流技术架构，其中处理非结构化数据的能力成为新一代数据库的关键功能点。本文也将从一个实际企业案例出发，介绍分布式数据库在影像数据管理场景下的最佳实践。

内容数据管理需求

在银行业竞争越来越激烈的背景下，部分银行由于非结构数据部分或全部存在于各自系统中，或尚未形成完整统一的存储管理模式，信息共享不及时导致信息孤岛效应明显，影响银行在部分业务上的决策。并且现有的非结构化内容管理平台已经不能满足在产品创新、服务创新和流程创新上的新需求，并且部分银行已经提出流程银行的战略构想,将企业内容应用以及集中作业和碎片录入系统，作为全行流程银行的基础平台。

目前金融企业内容管理平台存在以下几个问题：

需要实现跨业务的企业内容管理系统整合和处理，由于部分业务系统企业内容数据独立，未形成企业级内容统一存储，造成在需要企业内容数据跨业务进行处理和展现时，不同业务系统对企业内容数据的调用处理复杂
数据量增长太快，传统企业内容管理系统依赖于关系型数据库，在记录数超过亿级别之后，检索内容记录的响应时间变慢，很难实时过滤企业内容数据特征比如基于内容标签的实时推荐，并且无法在全表多索引数据回溯
传统企业内容管理系统建设成本较高，水平扩展复杂。在银行海量数据存储需求的背景下，需要高性价比的数据存储持续在线，保留源结构的长期数据并且能做到秒级快速索引数据回溯，以满足复杂在线交易和历史数据查询需求，因此，未来企业内容管理系统需满足在线水平扩展

为了满足未来全行级流程银行建设的要求，需要建设能够服务于全行各种业务流程化处理的影像及相关系统处理平台，将其他分散的非结构化数据进行统一的管理。

技术要点

企业内容管理系统需求痛点：

用低成本的分布式存储管理海量数据

传统企业内容管理系统采用关系型数据库+文件系统的架构方式，硬件基于小型机+高端存储，运行Unix。这种架构和硬件成本较高，并且计算能力和容量不能横向扩展，按需扩容，大大增加了客户的使用成本，因此，需求采用分布式架构，使用内置 SAS 或 SATA 硬盘，并能横向扩展，按需扩容，管理 PB 级别的内容，同时做到在线扩容，滚动升级，不需中断业务，以节省客户的使用成本

非结构化数据和结构化数据的统一管理

对于企业内容管理系统，需要把企业内容本身，和企业内容相关的元数据，例如客户号、时间、交易类型、各相关字段同时存放在一条记录中，便于应用调用，同时省去了传统模式中要使用一个关系型数据库+一个 NAS 的复杂结构

高并发处理能力，随集群水平扩展性能线性提升

传统内容管理系统使用关系型数据库，在高并发场景下性能有所下降

同城灾备或异地灾备

随着银行业务的发展，企业内容数据存在银行的各个业务系统中，并在多个业务系统中传递，因此企业内容数据对银行来说越来越重要。为了提升业务系统的抵御灾难的能力，对这类系统银行会采用同城灾备或异地灾备的方式来保证数据的安全。传统的企业内容管理系统不具体同城灾备或异地灾备的功能，在新一代企业内容管理系统中这类需求显得尤为重要

多中心部署

部分银行存在分行到总行网络资源收到限制的问题，而企业内容数据在传输的过程中需要消耗较多的网络资源。为了不影响业务的正常进行，需要使用多中心部署的架构在业务较多时段分行本地存储企业内容数据，在业务较少（比如晚上）时段将企业内容数据同步到总行进行存储

整体架构及功能介绍

整体架构

利用SequoiaDB构建影像系统整体架构如3-1图所示：

图 3-1 影像平台整体架构

利用SequoiaDB构建影像平台，整体架构主要分为存储层、服务层、管理功能层和接口应用层。其中存储层由SequoiaDB集群组成。服务层、管理功能层和接口应用层采用客户端和服务端架构模式，服务层、管理功能层主要为企业内容提供各种企业应用功能和管理功能，接口应用层为客户业务系统提供统一、标准的接入接口，方便开发、运维人员统一的应用和管理。

架构详解

本节主要从内容服务层、管理功能层和接口应用层进行描述，对于存储层可参考SequoiaDB相关技术描述。具体功能描述如下：

服务层

批次服务

批次查询：一个批次包含多个文档，根据批次号查询批次的属性信息，并且根据条件指定是否查询企业内容

批次写入：新增一个或多个企业内容数据并以批次的方式进行管理

批次更新：根据指定条件对批次的属性进行更新

批次删除：根据指定条件对批次的属性进行逻辑删除或物理删除

文档服务

文档存储：基于SequoiaDB LOB存储，数据三副本，可按业务系统物理隔离

文档查询：根据SequoiaDB LOB存储返回的唯一标识进行查询

文档更新：对文档的属性和文档的内容进行更新

文档删除：根据条件对文档的属性和文档的内容进行物理或者逻辑删除

检入检出

存在多用户操作同时更新同一批次影像文件，引入检出/检入机制，类似于写锁或者信号量，强制用户更新数据前进行检出操作，防止事务带来的锁等待问题

版本控制

便于提取企业内容的历史快照，追溯企业内容的变动历史

访问控制

根据设定的权限访问相关资源，接入相应的业务系统

数据归档

在多数据中心分布式架构部署方式下，将分中心的企业内容数据迁移到总中心，进行统一的存储管理并根据配置策略对分中心企业内容数据进行清理以节省分中心存储空间

管理功能层

管理功能层以图形界面的方式对相关功能进行展示和操作。

内容管理

内容查询：根据企业内容元数据信息、业务标识、版本控制信息等对内容进行查询

内容调阅：对企业内容的元数据信息、版本控制信息、检入检出信息以及内容具体数据进行展现

内容编辑：对企业内容的元数据信息、版本控制信息以及企业内容具体数据进行编辑

数据同步管理

在多数据中心分布式架构部署方式下，对分中心数据迁移到总中心以及分中心数据清理策略进行管理监控

配置管理

业务类型管理：业务系统所属的类型管理

索引属性管理：内容属性、用户自定义属性以及内容其他信息所要建立索引的配置信息

系统管理

角色管理：角色对应权限功能的设置和管理

用户管理：系统用户增、删、查、改功能管理

部门管理：对公司组织机构的管理，系统用户和业务系统所属部门与之关联

日志管理：平台操作日志管理，对非法操作进行记录，方便运维人员进行追溯查询

报表展现

提供对内容平台数据查询、报表功能

门户

构建公司统一的内容门户，实现统一的基于多维度的内容查询、内容展现功能

接口应用层

提供标准的系统接口服务，为与其它应用系统的对接提供服务和标准接口。各接口功能与服务层相关服务对应

技术难点

此处最佳实践主要以SequoiaDB存储规划如何实现为主，应用管理部分根据客户实际需求不同实现方式不同。以本地虚拟机部署为例，虚拟机配置信息如下：

虚拟机数量：3台
CPU	1CORE
内存	1GB
磁盘	20GB
操作系统	RedHat 7.4

技术关键点1：存储规划

根据上述业务系统的信息，可将这类系统划分为高并发海量存储业务场景。结合数据域划分方式以及未来扩容需求，该业务系统的结构化和非结构化数据存储在接入时数据域划分规则如下：

每个业务系统使用独立的域进行存储（可以在同一个物理设备上，但是域要独立，数据域之间可以重叠数据组）
每个业务划分为结构化域和非结构化域
结构化域里面保存元数据信息，使用主子表按照时间切分，每个子表按照ID散列分布到域所对应的所有机器上
非结构化域里面保存对象数据，LOB不支持垂直分区，为了避免集群扩容对象数据重新均衡，在存储规划时可根据对象数据总的存储量及增长量采用按年或者按月的方式进行写入，LOB写入对应的集合空间和集合名称由接入平台维护
结构化域扩容可使用增加数据组再进行数据均衡切分到新扩容的机器上或者指定子表所属数据组在新扩容机器的数据组上
非结构化域扩容创建集合时所属数据组直接指定到新扩容机器的数据组上（这种方式适合前期规划时按月或年的方式，对应规划时存储在一个集合中的情形扩容后增加数据组需数据均衡）

针对数据域规划，此前我们也推出过相关的内容

可以链接前往阅读：数据域

技术关键点2：集合空间和集合设计

根据上述存储规则，该业务场景下的结构化数据和非结构化数据存储方式如下：

结构化数据以主子表的方式进行存储

结构化数据在创建主子表时，以上线时间为基准，上线时间以前的数据存放在历史数据表中，数据较少的业务系统以年为单位创建子表，子表时间跨度为规划存储年限，超过规划存储年限的数据存储到其他数据存储子表中；数据较多的业务系统以月或季度为单位创建子表，子表时间跨度为规划存储年限，超过规划存储年限的数据存储到其他数据存储子表中

非结构化数据以月为单位创建表进行存储

非结构化数据的存储，以上线时间为基准，上线时间以前的数据存放在历史数据表中，数据较少的业务系统以年为单位创建表，表时间跨度为规划存储年限，超过规划存储年限的数据存储到其他数据存储表中；数据较多的业务系统以月或季度为单位创建表，表时间跨度为规划存储年限，超过规划存储年限的数据存储到其他数据存储表中

（详情请见官网文档中心“系统架构-数据模型-集合”章节）

操作示例

结构化数据域和非结构化数据域创建脚本

db.createDomain('metaCSDomain',["group1","group2"],{AutoSplit:true});
db.createDomain('lobCSDomain',["group1","group2"],{AutoSplit:true});

结构化集合空间和非结构化结合空间创建脚本

db.createCS('metaCS', {"Domain":'metaCSDomain'});
db.createCS('lobCS', {"Domain":'lobCSDomain',"LobPageSize":logPageSize});

结构化数据集合创建脚本

db.metaCS.createCL('metaCL',{"ShardingKey":{"CREATETIME":1},"ShardingType":"range",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","IsMainCL":true});
db.metaCS.createCL('metaCLMin',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCL2017',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCL2018',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCLMax',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.getCL('metaCL').attachCL('metaCLMin',{"LowBound":{"CREATETIME":{$minKey:1}},"UpBound":{"CREATETIME":"20170101"}});
db.metaCS.getCL('metaCL').attachCL('metaCL2017',{"LowBound":{"CREATETIME":"20170101"},"UpBound":{"CREATETIME":"20180101"}});
db.metaCS.getCL('metaCL').attachCL('metaCL2018',{"LowBound":{"CREATETIME":"20180101"},"UpBound":{"CREATETIME":"20190101"}});
db.metaCS.getCL('metaCL').attachCL('metaCLMax',{"LowBound":{"CREATETIME":"20200101"},"UpBound":{"CREATETIME":{$maxKey:1}}});

非结构化数据集合创建脚本

db.lobCS.createCL('lobCL201701', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201702', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201703', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201704', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
...
db.lobCS.createCL('lobCL201912', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});

小结

数据域在逻辑上由一个或多个数据组组成，在物理上对应具体的数据节点，并且不同的域之间可以重叠数据组。因此，业务系统可以根据域包含数据组的灵活性将集群划分为不同的区域存储结构化数据和非结构化数据，充分利用集群的计算、存储资源。