因为这些是站在我们角度觉得的。

而实际上使用者#xff08;业务或者用户#xff09;#xff0c;真的不太在乎我们所在乎的。

因为这些是站在我们角度觉得的。

而实际上使用者业务或者用户真的不太在乎我们所在乎的。

这种情况常见于HTAP数据库与AP数据库的PK场景甚至是AP与AP数据库的PK。

我印象比较深刻的是OB在发布会上和CK的若干个场景进行跑分。

结果是在个别场景下OB优于CK个别场景下CK优于OB。

就是这种在伯仲之间的。

你说有差距吗有是一定有的。

但是决定性吗也不至于。

0.8秒觉得快但是1秒也没觉得慢。

不差那0.2秒。

这种场景通常见于全表扫描和索引实现。

我经历过的一个案例就是定时用ETL把OLTP的数据送到Hive这个操作等于是离线操作要4小时乃至12小时。

然后一顿操作猛如虎的数据加工。

这又导致几个小时过去了。

接着用户使用这些数据查询起来当然也是慢的。

可能需要30秒吧。

基于这种情况我采用的是CDC将数据送到一个集中的数据库。

这个库可以是Oracle也可以是其他数据库。

主要有索引就行。

我意思是MySQL和PostgreSQL都行。

这样的话这个操作等于是在线实时的数据捕获。

然后不需要数据清洗加工结合需求直接写针对底层表的SQL。

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数据来要插手介入的领域。

经济好的时候TPCDCAP经济不好的时候反正如果要保一个我就保TP。

总不能停止交易吧

那么就在TP上想办法怎么叠加AP。

但凡走离线的AP其价值是较低的和稳定性也没那么高要求性能是完全没要求了。

只要能有结果就行。

、