怎样能更好地利用数据库处理医药企业流向

医药企业客户流向数据可谓是大海一般的广阔，如何将这海量数据处理好是一个老话题也可以说是一个新话题，做为医药产业互联网和大数据解决方案专家的未名企鹅，在处理数据的过程中，不断优化技术、与时俱进、通过不停的思考和实践，来更好的发挥出技术优势来解决问题。

我们先来看一下进行数据处理的传统型数据库是什么样子

传统关系数据库的瓶颈

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

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

随着数据量的继续增长，数据的存储量增加。单节点的存储能力问题会逐渐显露。靠简单的扩容硬盘来提高存储能力会变得越来越困难，成本也会随之升高。更要命的是单节点的故障风险也会增加。数据丢失、 服务器宕机等任何一个问题的恢复时间会长到无法接受。

那么如何解决上述问题呢？--这就要谈到下一个话题“列式数据库”

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

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

* 存储容量无限扩容

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

* 列即是索引

* 可预分区解决扩容极限问题是列式数据库独有的特性。

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

那么列式数据库是不是就完美了呢？

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

* 实时响应要求高的系统无法接受秒级响应

* 缺失事务管理能力，很难保证数据完整性，需要业务层介入

* 运维成本高，依赖Hadoop生态众多项目，运维管理开发困难都较大。

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

诚然，传统型数据库也好，列式数据库也好，只有适合客户的才是最好的。

专业的事情交给专业的团队来做，做为医药产业互联网和大数据解决方案专家的未名企鹅在技术方向不断进步、攻坚克难，在客户数据业务处理上使客户无需再考虑复杂的技术实现问题，专注于自业务即可。