某单位海量数据存储、应用实践.doc

? ? ? ? ? ? ? ? 某单位海量数据存储、应用实践 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 一、 项目建设背景 随着大数据、云计算、移动互联迅速发展，快速交付与灵活扩展的强烈需求增长，传统竖井式的 IT 基础架构设施面临着新的挑战。一方面快速增长的互联网业务需要灵活的、可自由伸缩、不限于规格容量的存储的 IT 软硬件资源提供坚实基础保障，另一方面高效的业务响应同传统的 IT 基础设施发展矛盾也日益突出。例不可预估的互联网业务客户量、持续增长的日交易量、重要时期的高峰的运行压力、大量并发 IO 读写，系统响应缓慢，关键指标时效性不足，而这些性能痛点最先反映在数据存储 IO 上。 因此如何全面规划和整合当前 IT 基础架构中的数据存储体系，构建灵活、高效、先进的高可用存储架构，实现可满足生产系统的高并发、低延时的性能需求，是金融机构 IDCIT 信息化建设的迫切要求。 二、 高性能高并发的数据存储建设痛点 随着信息大数据时代的来临，对信息收集的需求越来越高，在原来客户交易信息留存的基础上，增加了客户的行为及客户的属性等信息。 对于一个大型的应用系统，海量数据的存储和访问成为了系统设计的瓶颈问题。 我机构原先系统采用的是 oracle 的 RAC 作为数据存储，随着业务量和数据量的增大，对于系统的稳定性和扩展性造成了极大的问题。现在采用 postgres 集群 +redis 内存数据库 +Druid 实时分析数据库 +hbase 列式数据库 +hdfs+kafka 消息队列；辅以 Minio 分布式文件存储实现的，目前使用效果良好，但在整合建设的初期，是存在许多技术痛点的。 1、 是否坚持所有数据一致性原则 传统的项目，几乎清一色的使用传统的关系型数据库 (RDBMS) 。从早期的 mysql 、 sqlserver 到后期的 informix 、 db2 、 oracle 再到 oracle rac. 。关系型数据库是强事物一致性 (ACID) ，使用比较早，技术相对成熟。 ACID 它的核心是“约束”，而这个“约束”由数据库的使用者告诉数据库，使用者要求数据一定是符合这样或者那样的约束条件。当数据发生修改时，数据库会检查数据是否还符合约束条件，如果约束条件不再被满足，那么修改操作不会发生。关系数据库最常见的两类约束是“唯一性约束”和“完整性约束”，表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复，表格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。 当数据库系统从批量处理进化到在线实时系统后，事务就可以并发地在数据库上进行操作，在给使用者带来便利的同时也给数据库系统开发人员带来了诸多困难。严肃的数据库系统都会有一套复杂的并发控制机制来保证事务并行执行时数据的正确性。而事务隔离性最大的烦恼来自并发控制对性能的影响，最严格的隔离性保证了所有的事务虽然是并发执行，但是最终执行的结果跟事务一个个串行着做是一样的，可串行化保证了一定不会因为并发进行的事务导致数据出错，但是这也会导致事务有更多等待或者失败。 在进入大数据时代后，超高的并发访问量以及海量的数据，注定使用 ACID 的原则将使得系统需要一个性能极高的计算器进行运算。无疑这给系统带来了巨大开销浪费。 原本单位使用的是 ORACLE 的 RAC ，但是在越来越多的数据存储和更多的访问并发，单点 IO 吞吐量的制约效果，越来越明显。 当关系型数据库越来越成为瓶颈时，为解决单点瓶颈，适当采取牺牲 CAP 属性中的 C ，也不失为一个可选的策略。 早期的系统调研中，有的场景对于实时性一致性要求高，但是每次操作的数据量不大。而在其他的常见中，每次操作的数据量较大，但是对于数据的实时一致性没有过高的要求。 基于此，对于数据存储的选型，要区别对待。对于前后数据需要一致性的，依旧采用关系型数据库，用数据库事务来保证数据的 ACID 一致性要求。对于并发访问量高，但是数据的时效性和对比关联性不是很强的场景，我们采用分布式数据存储来应对。 经过多次选型调研，最终选择了 postgres 数据库作为关系型数据库的载体，用于 ACID 的场景。使用 NOSQL 的数据存储作为高并发访问的场景的数据存储。 2、 非关系型数据库选型 市面常见的 NOSQL 包括 redis,duri ， hbase,mongdb,hive 等。对于不同应用场景的选择是不同的。 MongoDB 表结构灵活可变，字段类型可以随时修改。记录以 Json 格式后存储，不需要定义表结构。但是多表查询、复杂事务等高级操作效率低下。所以其适合于写少读多的场景。 HBase 列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是由于查询都必须要依赖 r