聊几句非技术的

昨天我发了一篇OB和TiDB架构对比的文章,谈了一些二者架构上的优缺点,没想到反馈和交流十分热烈,也有一些朋友对文章的观点谈了不同的看法。我十分欢迎这样的讨论,因为作为一个数据库的使用者,在某些观点上肯定存在不够到位,甚至完全错误的地方。只有和大家广泛交流才能够共同进步。回想起二十年前在ITPUB上的日子,某个关于Oracle的观点出来肯定会引发论战,甚至争吵和谩骂。正是因为这些讨论,让我们对Oracle的认知越来越清晰了,国内的Oracle数据库运维水平也快速提升。最近有几个朋友都和我聊过去东南亚做Oracle数据库服务的事情,我觉得这就是这些年我们进步的回报。
一个数据库在某个应用场景上的性能好坏,架构只是其中一部分,分布式事务管理器、SQL执行引擎、CBO优化器、RPC通讯机制等的代码质量对其影响也是巨大的。我们的数据库厂商也在不断的通过优化代码来提升其性能。我的一些观点,一些看法,都只是一家之言,大家可以充分讨论,方能共同进步。每个人都会对某种数据库产品有某种好感,同样也会对某个数据库产品有很强的恶感。实际上每个人对OB和TiDB这两种国产数据库产品的感受都会有些不同。昨天一个和我讨论的朋友说,他对二者最大的感受是TiDB就像开自动波的车,很多地方是自动的,你想玩运动模式,它不一定提供。而用OB向开手波的车,如果你开惯了自动波的车,刚开始会手忙脚乱。不过如果你擅长开手波的车,那么你可以利用很多可自己控制的方式去为自己的应用特点手动控制表的分布。
实际上我们的数据库厂商应该多听一听用户的声音,自动波的车也可以提供一些手波的特性,比如说提供一个陡坡、运动、雪上等专业模式,而手波的车也可以通过一些优化改进,通过电子辅助让离合和油门的配合更容易掌握。分布式数据库目前要解决的最大的问题是降低用户的使用门槛和使用成本,这方面做的好的产品,其受众群体就会越来越大。
目前我们的国产数据库厂商似乎都不太听得进负面或者反面的观点,网络上也是种花的多,栽刺的少,一片祥和的气氛。实际上在二十年前,正是ITPUB上大量的对Oracle的吐槽促进了Oracle在中国的普及。
几年前我写了一篇某国产数据库宕机故障分析的文章,实际上此类文章以前我写过的不少,不过都是写Oracle的。DBA们还是很欢迎此类文章的,因为这些经验对他们遇到类似问题很有帮助。
不过文章发出几个小时候,我接到了一个数据库厂商的朋友的电话,希望我能删掉那篇文章。当时我不太理解,这种国产数据库运维的文章不是越多越好吗?他说有些朋友看到了这篇文章,在渲染他们的数据库产品不稳定,容易宕机,影响不好。我后来还是把那篇文章删除了,可能问题也不是出在我的这位朋友身上,大家看不起国产数据库,一旦有些问题就无限放大,也让我们得国产数据库厂商变得脆弱起来了。
前几天我发了一篇关于OB4.0单机版使用体会的文章,其中举了一个PG中的一个场景的例子。因为openGauss最初也是基于PG 9.2.4开发的,所以我顺便也测试了一下openGauss,发现其执行计划与PG类似。文章发出后,中午我接到了华为openGauss的一位朋友的电话,和我探讨这个案例,他认为CBO的选择并无问题,我的测试场景数据量不同,所以得到的结论不同。确实是的,我是一边写文章一边做测试的,数据没有完全取齐。于是我建议他用10万条数据测试下openGauss的结果,因为我早上正好做过一个OB4.0的10万条记录的测试。晚上的时候,他给我在微信上留言,说十分感谢这个案例,优化器必须在这样的场景中多磨练,才能越来越好。并且问我在我们从Oracle迁移应用时还遇到过哪些SQL存在类似的问题,希望我帮他们多找一些。
今天早上写这篇文章,算是对这几天我发的几篇文章的读者的反馈的一个回答吧,我写一些国产数据库的文章,是希望和大家广泛的交流,大家觉得不对的观点,可以留言或者通过微信和我交流。只有通过不同观点的碰撞和交流,才能共同进步。不过我还是和二十年前在ITPUB上讨论Oracle一样,只讨论,不争论。年纪大了,血压有点高,需要保持心平气和了。

聊几句非技术的》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/153.html