现在只要是个数据库都号称自己是HTAP数据库。实际上HTAP原本并非数据库的特性，而是一种兼具OLTP和OLAP特性的应用特性。很多应用兼具这两种场景，也希望数据库产品能够对这样的场景做出良好的支撑。

虽然现在是个数据库就号称HTAP数据库，但是实际上仔细分析分析，靠谱的还真不多。Oracle Exadata是我目前所见最好的HTAP数据库，对于几百TB级别的数据，在OLTP和OLAP场景上都有着良好的性能，而且混合负载下并无衰竭。甚至对于老大难的即席查询场景的支撑也是游刃有余。Exadata凭借的是强大的硬件，以及强大的集成能力，几十甚至上百TB的并发扫描工作的同时，小事务写入依然十分平稳。再辅以TRUE CACHE、In Memory DB等技术，Exadata真的是一个能够完美支撑各种HTAP场景的数据库。哪怕离开了Exadata硬件的支持，如果辅助以高性能的全闪存储，虽然没有对HTAP场景强力支持的混合列压缩和SMART SCAN，仅仅凭借其强大的SQL引擎的能力，普通的Oracle数据库，在几十TB-100TB数据量的HTAP应用的支撑依然是十分稳定与靠谱的。

除了Oracle之外，亚马逊Aurora、Oracle MySQL Heatwave和谷歌AlloyDB也针对HTAP场景做了一定的支撑。这些产品的HTAP能力来自于云底座的强大硬件支撑。MySQL Heatware是暴力计算的典范，利用近实时的分布式内存列存集群，依靠算力来解决OLAP场景的需求。实际上TP和AP是在两个完全不同的数据库中完成的。Aurora和AlloyDB则是依靠对存储层的改造，利用云存储来确保高负载下的低延时，从而为OLAP提供有力对的支撑，其代价也是不小的。PolarDB PG则是这两种数据库的国产版本。

以前有一种观点是分布式数据库式天然的HTAP数据库，这一点我一直式存疑的。在我的个人观点里，HTAP数据库首先必须是一种通用数据库，判别一个数据库是否真正对HTAP场景有良好的支持的一个重要的因素是对十分宽泛与随意的即席查询的支持。早期的分布数据库大多数并非通用数据库，而是针对高并发的在线交易系统设计的。对于复杂查询与OLAP场景的支持并不好。想要利用分布数据库多节点的特性来平衡OLTP/OLAP两种场景，实现起来是比较困难的。早期的MPP数据库都是OLAP场景的，用列存、列索引、列压缩等方式可以很好地支撑在线分析应用，但是一旦多了一些在线事务，性能就很不稳定了。在我所见到的MPP数据库增加OLTP能力的项目，最后几乎都以失败告终。

同样的在OLTP数据库上增加OLAP能力的工作目前所见到的成果也并不理想。HTAP是需要代价的。TiDB是比较早明白这个道理的，如果没有TiFlash副本，仅仅依靠对TiKV的暴力计算，效果并不能让用户满意。将TiKV转换为列存的TiFlash，用来支撑OLTP系统中的AP需求，其实与AlloyDB或者HeatWave的思路是相同的。OceanBase则利用弱读来实现OLTP与OLAP资源的分离，实际上设计这些特性的最主要目的是隔离TP和AP这两种场景，不让AP影响TP的稳定性。但是无论TiDB还是OceanBase只是解决了一部分HTAP的问题。TiDB的架构决定了对于延时要求极低的场景的支持能力不足，从而在一些场景中无法发挥出其HTAP的能力。而OceanBase则最即席查询这种无法事先对数据分布做优化的场景的支持能力也是偏弱,并发几个大查询就很可能把网络拥塞了。上面的两种国产分布式数据库，都具备初步的HTAP能力，但是对场景的支持并不丰富。其他数据库我就不谈了，支持列存只是支持HTAP场景的必要条件，不是充分条件。

HTAP数据库首先必须有一个强大的心脏，能够对各种复杂查询都游刃有余，能够在优秀的资源管理器的控制之下，充分榨干现代硬件的能力，从而让用户的每一分投资都得到体现。HTAP数据库，先把这颗心脏锻炼出来，才是根本。