免费做二建题的网站,手机可以做app的软件,wordpress主题分为多章节,天津西青区属于什么风险区先说结论#xff1a;没那么重要。甚至可能不重要。
我用我的经历和分析给大家说说。诸位看看如何。
不重要的观点是不是不能接受#xff1f;
因为这些是站在我们角度觉得的。而实际上使用者#xff08;业务或者用户#xff09;#xff0c;真的不太在乎我们所在乎的。
…先说结论没那么重要。甚至可能不重要。
我用我的经历和分析给大家说说。诸位看看如何。
不重要的观点是不是不能接受
因为这些是站在我们角度觉得的。而实际上使用者业务或者用户真的不太在乎我们所在乎的。
先说第一种情况伯仲之间的较量
这种情况常见于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都是鸡肋了
经济好的时候TPCDCAP经济不好的时候反正如果要保一个我就保TP。总不能停止交易吧 那么就在TP上想办法怎么叠加AP。但凡走离线的AP其价值是较低的和稳定性也没那么高要求性能是完全没要求了。只要能有结果就行。、 没结果呢没有就没有吧。也没什么事。
