AP的数据库性能到底重要吗?

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

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

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

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

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

这种情况常见于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,其价值是较低的,和稳定性也没那么高要求,性能是完全没要求了。只要能有结果就行。、
没结果呢?没有就没有吧。也没什么事。

  • 5
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值