先说结论：没那么重要。甚至可能不重要。

　　我用我的经历和分析给大家说说。诸位看看如何。

　　不重要的观点是不是不能接受？

　　因为这些是站在我们角度觉得的。而实际上使用者（业务或者用户），真的不太在乎我们所在乎的。

　　先说第一种情况伯仲之间的较量

　　这种情况常见于HTAP数据库与AP数据库的PK场景，甚至是AP与AP数据库的PK。我印象比较深刻的是OB在发布会上和CK的若干个场景进行跑分。结果是在个别场景下OB优于CK，个别场景下CK优于OB。 我今天不讨论谁优，我就说两者的优的具体表现。比如一个是0.8秒 ，另外一个是1.0秒或者 一个是1.2秒，另外一个是1.3秒。

　　就是这种在伯仲之间的。你说有差距吗？有是一定有的。但是决定性吗？也不至于。0.8秒觉得快，但是1秒也没觉得慢。不差那0.2秒。

　　再说第二种情况碾压式的较量

　　这种场景通常见于全表扫描和索引实现。我经历过的一个案例就是定时用ETL把OLTP的数据送到Hive，这个操作等于是离线操作，要4小时乃至12小时。然后一顿操作猛如虎的数据加工。这又导致几个小时过去了。接着用户使用这些数据查询起来当然也是慢的。可能需要30秒吧。

　　基于这种情况，我采用的是CDC将数据送到一个集中的数据库。这个库可以是Oracle也可以是其他数据库。主要有索引就行。我意思是MySQL和PostgreSQL都行。这样的话，这个操作等于是在线实时的数据捕获。然后不需要数据清洗加工，结合需求，直接写针对底层表的SQL。 那结果是20毫秒。

　　20毫秒的是一个虚拟机而30秒的是N台物理机。碾压1500倍。到这里看我文章的手中全体的读者估计会说，那就用这个20毫秒的呀。而实事是超出我们所想象的。领导觉得未必需要实时。有些觉得30秒也不是不能等。

　　所以基于这个来说，即使形成了1000多倍的优势，而这些优势用户都不在意。

　　打击过后的结论

　　没那么重要。甚至可能不重要。

　　数仓的场景

　　今天说这个是因为上个月NineData的一篇AP数据库性能的文章。（上个月实在没空写了）

　　佛爷当时说：TPC-H主要是报表分析场景，几乎都是全表扫描或者全索引扫描的JOIN，这个是新的数仓产品发力的战场。 这点上佛爷有发言权的。我觉得他说的对。

　　我对佛爷说，这个做的很好。但是我发现可能只有DBA看这个，用户不看这些。我并不是说这个没价值。如果是我，我也会去做这种工作。是给自己心里有个数。只是不懂数据库的人不在乎我们的结果。

　　摆在数仓前面的难题

　　比如某些AP数据现在这些产品还有个问题要解决，就是Join内存不足时，SQL会报错。Oracle在Hash Join方面内存控制比较优秀，内存不足会刷盘，SQL会慢一些，但是不会失败。这个难题，我觉得可能每家不一样，谁能解决谁有机会。

　　另外一个难题还是数据搬迁，我始终看不起ETL，我观点是CDC为王。有些产品的实时DML能力比较差，和关系型数据库有差距，数据加载基本都是批量导入文件的。这个难题是很多家都要面对的。数据怎么从TP可以优雅的到AP。当然这也是HTAP数据来要插手介入的领域。

　　极端情况下AP都是鸡肋了

　　经济好的时候TP+CDC+AP，经济不好的时候，反正如果要保一个，我就保TP。总不能停止交易吧？那么就在TP上想办法怎么叠加AP。但凡走离线的AP，其价值是较低的，和稳定性也没那么高要求，性能是完全没要求了。只要能有结果就行。没结果呢？没有就没有吧。也没什么事。