海量数据的存储技术方案和应用实践.docx

海量数据的存储技术方案和应用实践
NoSQL+集群流批+PG集群+内存缓存
     
 
 
 
 
     
     
 
     
 
 
 
目 录
一、项目建设背景 3
二、高性单点瓶颈，适当采取牺牲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但是查询的速度较慢，适合于大批量场景的数据加工，存储的场景。
下面有个对比的表格：
支持情况
Redis
Durid
HBase
MongoDB
Hive
数据规模
小
中
大
中
大
批量查询性能
弱
中
中
强
强
批量写入性能
弱
中
强
中
强
支持表级关联
不支持
不支持
不支持
弱
强
聚合查询
不支持
强
不支持
中
中
亚秒级查询
强
强
中
强
弱
亚秒级写入
强
强
强
中
弱
3、数据灾备方式的选择
数据是科技公司最大的资产，每个公司都在数据灾备上面作为了大量的应用防止出现意外时候，数据丢失及访问异常。为最大程度的降低风险。早期考虑dump每天的数据快照，在异地数据库进行恢复，但是这样存在dump期间的数据丢失情况。一旦出现数据服务器down机的情况，备库是无法承接使用的。
现在Postgres集群本地采用一主两从的流复制方式，保证主从节点之间数据一致性。同时在一台从节点上使用级联复制为异步IDC提供数据同步服务。
HDFS采用跨IDC机架的方式，Redis、Durid、MongoDB采用集群模式、保证数据灾备时候，能够快速切换到备机使用，且数据不会丢失。
三、建设实践
1、关系型数据库应用
 关系型中数据库切分存储
由于去IOM的要求及未来国产化、开源化的大趋势。我们最终选择了Postgres作为关系型数据库的载体。
单库Postgres性能无法满足高并发访问的要求，采用了分库分表的数据逻辑切分。由于是强职能管理型的系统特性。客户关联的数据信息使用基于所在辖区水平分库切分，而管理公共信息、统计报表信息、数据概览信息、以垂直切分的方式切分。对于常用的表，在各个数据库中冗余存储。以此减少OLAP操作时网络传输的耗时，同时便于利用数据库本身的特性。
这样切分，虽然不同的数据库中数据相较于一致性hash分库原则会不一致，不同辖区对应的数据库中数据量可能不一样多，牺牲了一部分的存储。但是较系统的性能，还是值得的。
同时对于数据库当日产生的操作信息及交易流水，按照一致性Hbase的原理，将流水信息存储在以流水号切分的数据库节点中存储。
关系型中数据库HA
在众多的PostgreSQL HA方案中，流复制HA方案是性能，可靠性，部署成本等方面都比较好的，也是目前被普遍采用的方案。而用于管理流复制集群的工具中，Pacemaker+Corosync又是比较成熟可靠的。同时为了兼顾异地灾备，以一个从节点进行级联复制，将数据异地灾备到其他IDC机房节点。
系统