NoSQL集群流批PG集群内存缓存海量数据存储实践

NoSQL+集群流批+PG集群+内存缓存:

某单位海量数据存储实践

A公【导读】某机构原采用的Oracle的RAC作为数据存储，随着业务量加数

据量的增大，对于系统的稳定性和扩展性造成了极大的问题。现在采用

Postgres集群+Redis内存数据库+Druid实时分析数据库+Hbase列式数据库

+HDFS+Kafka消息队列；辅以Minio分布式文件存储实现的，目前使用效果良

好。本文介绍了整合建设的初期存在的技术痛点和建设实践经验，希望可以为

大家提供参考借鉴。

一、项目建设背景

随着大数据、云计算、移动互联迅速发展，快速交付与灵活扩展的强烈需求增

长，传统竖井式的IT基础架构设施面临着新的挑战。一方面快速增长的互联网

业务需要灵活的、可自由伸缩、不限于规格容量的存储的IT软硬件资源提斐坚

实基础保障，另一方面高效的业务响应同传统的IT基础设施发展矛盾也日益突

出。例不可预估的互联网业务客户量、持续增长的日交易量、重要时期的高峰

的运行压力、大量并发10读写，系统响应缓慢，关键指标时效性不足，而这些

性能痛点最先反映在数据存储10上。

因此如何全面规划和整合当前1T基础架构中的数据存储体系，构建灵活、高

效、先进的高可用存储架构，实现可满足生产系统的高并发、低延时的性能需

求，是金融机构IDCIT信息化建设的迫切要求。

二、高性能高并发的数据存储建设痛点

随着信息大数据时代的来临，对信息收集的需求越来越高，在原来客户交易信

息留存的基础上，增加了客户的行为及客户的属性等信息。对于一个大型的应

用系统，海量数据的存储和访问成为了系统设计的瓶颈问题。

我机构原先系统采用的是Oracle的RAC作为数据存储，随着业务量和数据量的

增大，对于系统的稳定性和扩展性造成了极大的问题。现在采用Postgres集群

+Redis内存数据库+Druid实时分析数据库+Hbase列式数据库+HDFS+Kafka消

息队列；辅以Minio分布式文件存储实现的，目前使用效果良好，但在整合建

设的初期，是存在许多技术痛点的。

1、是否坚持所有数据一致性原则

传统的项目，几乎清一色的使用传统的关系型数据库(RDBMS)。从早期的

MySQL、SQLServer到后期的Informix、Db2、Oracle再到OracleRAC。关系

型数据库是强事物一致性(ACID),使用比较早，技术相对成熟。

ACID它的核心是“约支”,而这个“约束”由数据库的使用者告诉数据库，使

用者要求数据一定是符合这样或者那样的约束条件。当数据发生修改时，数据

库会检查数据是否还符合约束条件，如果约束条件不再被满足，那么修改操作

不会发生。关系数据库最常见的两类约束是“唯一性约束”和“完整性约

束”，表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复，表

格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。

当数据库系统从批量处理进化到在线实时系统后，事务就可以并发地在数据库

上进行操作，在给使用者带来便利的同时也给数据库系统开发人员带来了诸多

困难。严肃的数据库系统都会有一套复杂的并发控制机制来保证事务并行执行

时数据的正确性。而事务隔离性最大的烦恼来自并发控制对性能的影响，最严

格的隔离性保证了所有的事务虽然是并发执行，但是最终执行的结果跟事务一

个个串行着做是一样的，可串行化保证了一定不会因为并发进行的事务导致数

据出错，但是这也会导致事务有更多等待或者失败。

在进入大数据时代后，超高的并发访问量以及海量的数据，注定使用ACID的原

则将使得系统需要一个性能极高的计算器进行运算。无疑这给系统带来了巨大

开销浪费。

原本单位使用的是Oracle的RAC,但是在越来越多的数据存储和更多的访问并

发，单点10吞吐量的制约效果，越来越明显。

当关系型数据库越来越成为瓶颈时，为解决单点瓶颈，适当采取牺牲CAP属性

中的C,也不失为一个可选的策略。

早期的系统调研中，有的场景对于实时性一致性要求高，但是每次操作的数据

量不大。而在其他的常见中，每次操作的数据量较大，但是对于数据的实时一

致性没有过高的要求。

基于此，对于数据存储的选型，要区别对待。对于前后数据需要一致性的，依

旧采用关系型数据库，用数据库事务来保证数据的ACID一致性要求。对于并发

访问量高，但是数据的时效性和对比关联性不是缎强的场景，我们采用分布式

数据存储来应对。

经过多次选型调研，最终选择了Postgres数据库作为关系型数据库的载体，用

于ACID的场景。使用NoSQL的数据存储作为高并发访问的场景的数据存储。

2、非关系型数据库选型

市面常见的NoSQL包括Redis、Durid、Hbase、MongoDB、Hive等。对于不同应

用场景的选择是不同的。

MongoDB表结构灵活可变，字段类型可以随时修改。记录以Json格式后存储，

不需要定义表结构。但是多表查询、复杂事务等高级操作效率低下。所以其适

合于写少读多的场景。

HBase列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是由于

查询都必须要依赖rowKey,这就使得很多复杂查询难以进行。例如，如果你的

查询条件涉及多个列项，或者你无法获取要查询数据的key,那么查询效率将

会非常低下。

Druid是基于MPP架构的OLAP,其预聚合算是Druid的一个非常大的亮点,

通过预聚合可以减少数据的存储以及避免查询时缎多不必要的计算。适用于大

量数据的下的实时聚合查询场景。

Redis牺牲了常规数据库中的数据表、复杂查询等功能，特别适合那些对读写

性能要求极高，查询条件也同样简单的应用场景。

HIVE数据仓库，基于HDFS的结构，支持主流的SQL但是查询的速度较慢，适

合于大批量场景的数据加工，存储的场景。

下面有个对比的表格：

支持情况RedisDuridHBaseMongoDBHive

数据规模小中大中大

批量查询弱中中强强

性能

批量写入弱中强中强

性能

支持表级不支持不支持不支持弱强

关联

聚合查询不支持强不支持中中

亚秒级查理强中强弱

询

亚秒级写强强强中弱

入

3、数据灾备方式的选择

数据是科技公司最大的资产，每个公司都在数据灾备上面作为了大量的应民防

止出现意外时候，数据丢失及访问异常。为最大程度的降低风险。早期考虑

dump每天的数据快照，在异地数据库进行恢复，但是这样存在dump期间的数

据丢失情况。一旦出现数据服务器down机的情况，备库是无法承接使用的。

现在Postgres集群本地采用一主两从的流复制方式，保证主从节点之间数据一

致性。同时在一台从卡点上使用级联复制为异步IDC提供数据同步服务。

HDFS采用跨IDC机架的方式，Rcdis、Durid、MongoDB采用集群模式、保证数

据灾备时候，能够快速切换到备机使用，且数据不会丢失。

三、建设实践

1、关系型数据库应用

关系型中数据库切分存储

由于去IOM的要求及未来国产化、开源化的大趋势。我们最终选择了Postgres

作为关系型数据库的载体。

单库Postgres性能无法满足高并发访问的要求，采用了分库分表的数据逻辑切

分。由于是强职能管理型的系统特性。客户关联的数据信息使用基于所在辖区

水平分库切分，而管理公共信息、统计报表信息、数据概览信息、以垂直切分

的方式切分。对于常庆的表，在各个数据库中冗余存储。以此减少OLAP操作时

网络传输的耗时，同时便于利用数据库本身的特性。

这样切分，虽然不同的数据库中数据相较于一致性hash分库原则会不一致，不

同辖区对应的数据库中数据量可能不一样多，牺牲了一部分的存储。但是较系

统的性能，还是值得的。

同时对于数据库当日产生的操作信息及交易流水，按照一致性Hbase的原理，

将流水信息存储在以流水号切分的数据库节点中存储。

・关系型中数据库HA

在众多的PostgreSQLHA方案中，流复制HA方案是性能，可靠性，部署成本等

方面都比较好的，也是目前被普遍采用的方案。而用于管理流复制集群的工具

中，Pacemaker+Corosync又是比较成熟可靠的。同时为了兼顾异地灾备，以一

个从节点进行级联复制，将数据异地灾备到其他IDC机房节点。

系统基于Pacemaker+Corosync实现PG集群的Master-Slave模式，如图所示：

读写分离、高可用

使用pacemaker实现集群资源的管理，业务层通过write-vip实现数据向

Master节点的写入，通过read-vip实现Slave节点数据的读取；主节点故障

时，vip会自动漂移，从节点升为主库，实现PG的高可用。

数据、状态同步

Master与Slave节点基于流复制(SteamingReplication)通过LX(ethl)

网段实现数据的同步；通过2.X(eth2)网段，corosync实现Master与Slave

节点状态同步。

主从切换策略

1.初始状态下，master数据库和write-vip在节点1上运行，slave数据库和

read-vip在节点2上运行。

2.当master数据库或master数据库所在节点宕机时，节点2上的slave数据

库提升为master数据库，同时write-vip飘移到节点2上c

3.当slave数据库所在节点2宕机时，slave数据库停止运行，read-vip飘移

到nodelo

2、Redis内存数据库存放热点数据以及公共参数和映射参数

・Redis数据存储内容

由于客户信息进行了切分。为了快速的找到一个客户所在的信息。我们将客户

及客户所在数据库的映射关系、客户交易流水的hash键值的映射关系作为热点

数据存放于Redis中。

同时系统中需要承载的公共参数也放入了Redisto

同时将客户交易信息中，交易金额超过1万元的大额数据交易信息以及每天日

终提取出最近一季度活跃的客户信息，将这部分活跃的客户关键标志信息和大

额交易标志信息，也存放在Redis中，用于检索时候，直接在内存中进行检

索，而非直接访问数据库，当Redis中没有的时候再访问对应的数据库。

•Redis的HA

映射关系、公共参数采用集群模式部署HA。热点数据由于数据量较大，集群模

式写入慢，采用了哨兵的模式部署HA。

其中哨兵3台节点集群6台节点。

3、Durid检索聚合重点信息

有时候存在在全单位维度的数据OLAP的数据加工和抽样。如果在每个数据库中

抽样结果聚合后，在通过程序二次筛选，一方面架构复杂，另外一方面开发成

本较高。为此我们引入了Druid,在其中存储了全机构的所有客户和客户的重

点属性信息。

每次需要聚合查询的时候，从Druid中根据客户重点信息检索出目标集合。如

果目标集合的展示信息不够，在根据目标集合到对应的PG分库或者Hbase中查

询出应的数据信息。

4、HBase应用历史交易明细信息

明细信息存放于HBase中注意基于以下几个情况：

PG分库分表存放：

（1）数据量较大，PG数据库压力过大，数据库内存数据的频繁交换

（2）分库分表，数据库维护成本的增加，例如数据库表清理维护，数据同步策

略，路由策略。

采用Druid存储：

大量数据存入Druid,Druid集群压力大。

由于HBase适合于读少写多的情况，而历史明细一般查询较少。所以放入

HBase进行保存。

于是采用了将索引与数据存储隔离的原则，只把可能参与条件检索的字段索引

到Druid中，这样整个Druid集群压力减少到原来的1/N,全量的客户历史交

易明细根据检索出的主键，作为ROWKEY在HBase内查询。

实际应用中，用客户号+日期+交易流水号作为ROWKEY。当发生交易时候，首先

在交易数据库节点写入当天的流水信息.同时写入的操做通过Kafka消息队列

传到后线服务。后线服务实时写入HBase中存放历史交易明细的表中

5、MongoDB应用用户的属性行为偏好信息

因为系统的定位原因，系统主要用户客户信息的检索，并对客户进行产品推荐

以及其他金融服务。产以客户的属性信息是访问量最大的。但是其修改又很

少。这种正适合于MongoDB的应用场景。

每天晚上通过hive数据仓库，加工出客户的属性信息。将其导入MongoDB用于

白天的高并发访问的查询。

-数据存储和HA

MongoDB有三种集群部署模式，分别为主从复制(Master-Slaver)副本集

(ReplicaSet)和分片(Sharding)模式。

Master-Slaver因为不提供自动HA功能，所以建设中没有考虑使用。

ReplicaSet将数据复制多份保存，不同服务器架存同一份数据，在出现故障

时自动切换，实现故障转移。但遇到需要存储海量数据的情况时，副本集机制

就束手无策了c副本集中的一台机器可能不足以存储数据，或者说集群不兄以

提供可接受的读写吞吐量。

所以最终选择了Sharding模式，它将数据分开存储，不同服务器保存不同的

数据，所有服务器数据的总和即为整个数据集。

Mongodb(R)表示路由节点，点Mongodb(C)表示配置节点，Mongodb(M)表示主节

点、,Mongodb(S)表示备节点,Mongodb(A)表示仲裁节点。

Mongodb(M),Mongodb;S),Mongodb(A)组成一个分片服务器，整个的数据分布

存储在不同的分片服务器中。其中Mongodb(分,Mongodb(S)用于实际数据存

储。Mongodb(A)负责仲裁选主，不存储数据。

Mongodb(R)在集群中可作为路由使用，客户端由此接入，让整个集群看起来像

是一个单一的数据库，提供客户端应用程序和分片集群之间的接口。

Mongodb(C)是独立的一个Mongodb进程，保存集群和分片的元数据，在集群启

动最开始时建立，保存各个分片包含数据的信息。

6、HIVE数据仓库

在1IDFS构