技术咨询 | 数据库，你将何去何从？

自03年开始，google三驾马车纷至沓来，数据库开始掀起一股nosql的浪潮，虽然传统关系数据库依 旧屹立不倒，但我们的选择确实not only sql了：

●当数据量庞大到令DBA想删库跑路的时候，HBase会默默走到他旁边来一句”等我不行了，再跑 也不迟呀？”;

●当对数据有复杂的搜索需求的时候，我们情不自禁地会想起ES的倒排索引;

●当存取速度不尽如人意，如redis这样的基于内存的键值存储会立马飞入偶们的眼帘；

●当分析师对TB甚至PB数据提出近乎实时的报表需求的时候，我们只能祭出预计算的神器，于是 乎druid ，kylin就被推上了战场。

回过头来，我们发现虽然它们确实解决了问题，但也带来了新的复杂度：

业务同学说：“订单数据要 去Hbase查，日志数据从ES搜，报表从druid里搞, 晕了晕了，有sql接口的语法不一样，没有sql接口的更是五花八门，CRUD也不好做了吗？”；

平台的同学也不舒服:”一天到晚不是这个出问题了，就是那个出问题了，真当我是五花八门数据库运维吗？”。

大家心里不禁默默地想，还是回到那个只有关系数据库的时代好，就一个存储系统多好，简简单单，单纯的就和程序员一样。

然而在我看来，如果没有像NVM （非易失性内存） 这种革命性硬件的普及，或者内存便宜到就和磁 盘一样 （可参考内存数据库的发展） 。我们可能还是要面对混合存储这种现状，毕竟业务的问题总得解决，而从宏观上看数据结构就已经决定了增删查改的效率，尤其还基于当下如此庞大的数据的条件下。可是那怎么办呢？

近些年火起来的HTAP 就是业界给出的答案– 即一 个数据库，既支持对少量数据的短平快的事务操作，又支持大批量数据的复杂分析 。

HTAP：Hybrid Transactional/Analytical Processing

TIDB ，oceanBase就是其中代表。

拿TIDB来说，其实初期虽然号称能够TP，AP兼具。但底层的存储系统采用基于键值的RockDB，就算接上spark做查询引擎，在面对动不动就几TB数据进行聚合分组的查询，精确hash索引沦为摆设 （回表次数太多，不如全表扫描） ，查询效率可想而知，又怎能化腐朽为神奇呢？

而最近发布新版本中，终于抛弃了Tispark这个临时方案，开启TiFlash列存的新架构， 核心 就是：维护两套存储引擎，底层自动维护两套数据存储之间的数据同步；也就是说依旧是混合存储，只是对上层用户操作透明。

其实不仅是 存储 的 对外统一 ， 查询 也是如此 。Google在2018年发表F1 Query论文中讲到：google 内部已经在n年前实现了应对多种查询类型的F1 Query 的查询引擎 (可怕的公司，老是发一些旧系统 却引领着潮流) ，在基于存储计算分离的架构下， 统一 如下 三种类型的查询 ：

1. OLTP型的小规模数据查询;

2. 大批量数据的即席查询;

3. 超大规模数据的可靠的ETL的处理。

也就是说，用户透过F1 Client （如上图所示） ，向F1引擎发起各种类型的查询请 求，而F1则分别采用 三种执行模式 （Centralized Execution &Distributed Execution & Batch  Execution） 进行执行，实现了统一的查询入口功能。

当然做这件事的不止有google，Presto这个之 前只是支持即席查询的MPP的引擎，也是近些年引入了group execution的处理机制，实现对离线的 查询任务的支持；而kylin同样是不甘示弱，不再只能做n+1的报表，在最近发布的3.0版本中加入了 对实时数据的支持。

天下大势，合久必分，分久必合，数据库的世界是不是也是如此呢，让偶们默默吃瓜走着瞧吧。

投稿 | 数据中台

编辑 | sea

排版 | sea