大数据方案提供商，在帮助企业客户处理流向数据的过程不可避免的要面对如何处理大量的数据问题。虽然说数据处理一个老话题，但是时代在变化，技术在进化，解决的问题思路也需要与时俱进，在处理数据的过程中，技术人员也在不停的思考和实践，更好的发挥出技术优势来解决问题。

　　以下内容来自为医药产业开发互联网和大数据解决方案的未名企鹅供稿，作者为高级架构师Joseph，文章体现了他和团队在传统关系数据库升级到分析型数据库这个过程中的一些实践和思考。

　　传统关系数据库的瓶颈

　　数据是所有业务处理的基本对象，数据的处理能力会受多方面的限制。其中数据库就是数据处理能力的重要提供者。

　　传统关系型数据库指的是 MySQL、SQL Server、Oracle 等严格执行事务ACID原则的数据库。其关注点在于事务的处理、单机的存储性能。一般项目启动时会选择一款数据库，为数据的存储和事务处理提供支持。但传统关系型数据库的性能受限于主机的硬件性能和强事务保证的算法逻辑。

　　随着业务的拓展，数据量激增。使得我们不得不直面传统关系数据库的问题。

　　首先会遇到大表的检索问题。当一个表中的数据激增到大几百万或上千万时，会发现即使使用索引的查询也变的越来越慢了，甚至盲目增加索引会造成写入困难。这个时候可能会考虑按时间(或按其他条件)分表分库来解决问题。如需求稳定，这种分库分表的方式还算可以接受。然而这些给业务层带来额外的开发量，增加了处理的复杂度。

　　随着数据量的继续增长，数据的存储量增加。单节点的存储能力问题会逐渐显露。靠简单的扩容硬盘来提高存储能力会变得越来越困难，成本也会随之升高。更要命的是单节点的故障风险也会增加。数据丢失、 服务器宕机等任何一个问题的恢复时间会长到无法接受。此时有人会提出使用多个主机运行多个数据库实例，并结合分库分表的方案来解决问题。

　　进行多主机的方案实施后会发现， 采用多实例方案会引入大量的开发量。写入时数据的分配问题、聚合计算的问题、单节点很容易实现的功能会在多节点上实现变得异常困难。因此急需一个中间环节来对上层业务屏蔽这些复杂化的动作。

　　传统数据库的增强、中间件的应用及问题

　　在这样的背景下，数据库中间件应运而生。如MyCat这样出色的中间件，它对上层业务屏蔽了多实例操作的复杂问题，让业务使用起来如同单机一样。

　　业务在不断变化，需求复杂多样。好景不长，表结构的修改变的不可避免，之前稳定的分库分表策略开始被频繁被挑战。更改表结构漫长的等待时间逐渐让你失去耐心，意外的数据倾斜让你不知所措。

　　列式数据库的兴起

　　列式数据库 HBase 、Hive 的出现让人眼前一亮，新的设计理念，抛弃了对事务ACID的执着，专注于对大表(Big Table) 的处理。从大数据处理本身出发，没有了传统关系型数据库的包袱，轻装上阵，浴火重生。

　　如果说传统关系型数据库的存储时以记录为单位，那么一条记录为一行，因此可以称为行数据库。列数据库按记录里的字段进行分割存储，因此称为列数据库。

　　列式数据库独有的特性

　　* 存储容量无限扩容

　　* 按列聚集存储，高压缩比，高存储空间利用率

　　* 列即是索引

　　* 可预分区解决扩容极限问题

　　如此优秀的特性一度成为大数据处理的标配。如果说传统关系型数据库解决的问题的重点在于事务，那么列式数据库解决问题的重点在于大数据分析，因此将传统关系型数据库分类至OLTP联机事务处理(On-Line Transaction Processing)数据库，列式数据库分类至OLAP联机分析处理(On-Line Analytical Processing)数据库。至此数据库向两个方向齐头并进。

　　列式数据库的局限性

　　虽说列式数据库解决了大部分大数据分析的痛点，但在逐渐丰富的功能需求下，依然暴露出了短板。

　　* 实时响应要求高的系统无法接受秒级响应* 缺失事务管理能力，很难保证数据完整性，需要业务层介入* 运维成本高，依赖Hadoop生态众多项目，运维管理开发困难都较大

　　在实际使用当中，用于OLAP数据实际上是经过大量繁琐且昂贵的ETL操作才进入到数据库中的，数据在处理的过程中，为了保证高可用的状态，会保存多份，极大的增加对数据操作的成本，管理的复杂度，人力成本等等。同时如果实时响应的需求变得迫切。有些必要的事务动作不得不加入。在此背景下对部分数据的存储被迫使用其他数据库替代，如此操作又引入了数据的同步问题和存储空间的浪费。数据版本的管理不当容易引发灾难性后果。

　　新型数据库功能和性能的对立统一

　　从列式数据库的使用经验可以得知，真正的实际使用需求是既要能分析大数据，又要有事务控制能力。最好不要让业务管理多个版本的数据，否则既浪费存储资源，又增加开发成本。综上可以归纳为一条，拥有传统数据库的事务控制和实时响应能力，性能上又不受数据量影响。

　　对于以上存在的问题，我们更倾向于采用集成系统，能够同时支持OLTP和OLAP操作，中间不需要有大量的ETL操作。也就是具备HTAP混合事务和分析处理(Hybrid Transaction and Analytical Process)的能力。

　　已知列式数据是放弃了事务功能才获得大数据处理的优势，那么现在重新组合在一起，真的可行吗?

　　为此我们调研了现在能找到具备这种特性或潜力的数据库，TiDB就是其中一种，在分布式KV存储引擎上实现了事务控制、计算下推等能力。从而可以应对大量数据查询。从TiDB的架构设计上可以看出，其本质上依然是行式数据库，所以可以拥有很好的数据完整性控制能力，同时拥有分布式的存储扩容能力。但复杂查询的性能依然无法让人满意。好在后续推出了 TiSpark 弥补了这一缺陷，拥有了列数据库的能力，通过冗余的存储换取了复杂查询的性能。

　　同样功能的产品Aliyun的AnalyticDB采用行列混合存，最大程度满足了分析、和实时响应的需求，同时运维便捷。由于没有像TiSpark一样应对OLAP的接口，只能使用SQL操作，在应对复杂分析时略显语法表达能力的不足。

　　合适的才是最好的

　　可以预见HTAP将成为数据库发展的主流方向，甚至传统数据库如Mysql也默契的在新版本中加入OLAP特性来应对需求的升级。HTAP也并非完善无缺，在这个过程中需要有专业的团队去综合判断。

　　我们在追求极致的用户体验时从不迷信哪种技术可以解决一切问题，能在功能和成本上找到一个平衡点才是最佳的方案。

　　专业的事情交给专业的团队来做，未名企鹅在技术方向上投入了大量的人力和财力，专注于为客户提供开箱即用的数据处理平台，使客户无需再考虑复杂的技术实现问题，专注于自业务即可。

　　责任编辑:张华