文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

数据库国产化替代之后,补坑之路从未止步……

2024-12-01 02:49

关注

还有些企业怕遇到坑,因此还在不断地研究、认证、测试、分析中。事实上,在做出决策之前多一分小心还是十分必要的。10年前电信提出用开源数据库替代Oracle的时候,针对MYSQL和PG做了一番分析,我也参与了其中的一些工作,通过对当时的MYSQL和PG进行对比,我们最终的分析结果是:如果要迁移计费、账务系统,MYSQL优于PG。当然这个分析并不是说MYSQL就全面碾压PG,而只是针对计费、账务这样的系统场景,PG的膨胀与VACUUM会对系统稳定运行造成较大的影响,相对而言风险更大。

其实我们也没办法看得太远,哪怕是选择好的数据库,在迁移过程中,甚至迁移完成后的长期运行过程中,还是会遇到很多坑。有些问题可能是数据库基础架构从娘胎里带来的,无法马上解决的问题。如果你的应用对这样的问题十分敏感,不解决会引发大问题,那样就十分悲惨了。

昨天刚刚上班就有一个客户遇到国产数据库的问题,他们有一条SQL执行十分频繁,总体开销很大,希望通过index only scan来降低开销,不过创建了索引之后,执行计划依然不走index only scan,还是要走需要回表的执行计划。我以前也没有遇到过这类的问题,正好这个国产数据库是基于opengauss 2.0的,我们的测试环境中有opengauss 2.0和3.0的环境。于是我就先在opengauss 2.0的环境中做了一个测试。实际上openGauss是不支持Covering index的,在openGauss 2.0上,我们创建Covering index的时候会报错:

openGauss2.0是不支持这个语法的,openGauss3.0也类似,只不过错误信息有所变化:

在openGauss 3.0上,我并没有看到预期的Index Only Scan的执行计划。于是我在网上和一个朋友交流了这个问题,他正好对此有过研究,立即就指出了这是一个visibility map的问题,PG 8.4为了支持MVCC,引入了visibility map。不过VM文件并不是实时更新的,因此如果PAGE在VM中是不可见状态时,就必须做回表操作,因为索引中并不存在数据行可见性的标识数据,因此不能使用Index Only Scan。为了进一步确认这个问题,我在一个社区版的PG 11上做了一个测试。

drop table test_covering ;

create table test_covering (id serial,name text,val int);

create index idx_test_covering on test_covering(id) include(val);

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

analyze test_covering;

update test_covering set val=val+1;

select relallvisible from pg_class where relname='test_covering';

select relallvisible from pg_class where relname='test_covering';

explain (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

vacuum test_covering;

select relallvisible from pg_class where relname='test_covering';

explain (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

我们在PG 11上看到了预期的执行计划,因为PG的数据行的可视性信息仅仅存储于表数据中,而索引中没有这个信息,因此在做Index Only Scan的时候,如果VM没有及时更新,就必须回表才能获得准确的信息了。在VACUUM前执行的查询中,HEAP FETCHES是180,说明虽然执行计划是Index Only Scan,不过有180条数据是回表操作了。

当VM里已经更新了PAGE的信息,那么这些PAGE上的记录就不需要“回表操作”了,因此VACUUM后VM得到了更新,此时HEAP FETCHES变成0了,说明没有任何回表操作。因为VM文件的大小远远小于数据表的文件,因此不回表会降低执行成本。从上面的例子我们也可以看出,不回表执行0.037毫秒,回表执行0.203毫秒,差异还是挺大的。

在PG 11上只要做了表分析,那么起码执行计划是Index Only Scan的,为什么openGauss上执行计划也不选择Index Only Scan呢?刚才我们测试openGauss的时候因为不支持Covering Index的问题,对SQL做了改写。改写后的SQL在PG 11上是什么样的呢?


我们发现,如果索引变成了普通的索引之后,在PG上的执行计划也和openGauss一样了。

不过如果我们做一个vacuum,执行计划就变得正确了,而且也不存在“回表”的问题了。从这个测试我们再联想一下openGauss,openGauss数据库的CBO优化器是不是认为因为VM比较旧,这个查询需要回表,所以不选择Index Only Scan的执行计划呢?

于是我们也在openGauss上做了VACUUM,不过VACUUM完成后,可视的PAGE数量还是0,执行计划也还是没有发生改变。过了一段时间后,发现可见页的数量不为零了,于是再次分析执行计划,发现执行计划已经变成了Index Only Scan。

openGauss的文档上对于VM文件更新的问题并未做出说明,因为我们也只能猜测openGauss的vacuum命令并不更新VM文件,VM文件的更新可能是由其他机制来完成的。因为这个问题的存在,因此openGauss在ASTORE上不支持Covering Index,以防止创建了这样的索引,大部分情况下,Index Only Scan的执行计划也不可用。不过我们在openGauss的相关文档上并未找到这方面的说明。

我们利用openGauss 3.0的USTORE功能,做了最后一个实验,因为刚才我们看到openGauss在USTORE上是支持covering index的,是不是用Ustore可以解决这个问题呢?

drop table test_covering ;

create table test_covering (id serial,name text,val int) with (STORAGE_TYPE=USTORE) ;

create index idx_test_covering on test_covering using ubtree(id) include(val) ;

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

explain (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

analyze test_covering;

update test_covering set val=val+1;

explain (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

和我们预想的一样,在USTORE上不需要VM的情况下,优化器正确地选择了Index Only Scan。似乎在opengauss上使用USTORE可以完美解决这个问题。不过目前USTORE还不够成熟。在USTORE上也存在不少坑,比如说官方文档中没有提及的USTORE表不支持回收站的问题,以及USTORE上以前我们遇到的一些性能问题。从openGauss仅在USTORE上支持covering index上,我们也可以看出华为openGauss在VM方面可能存在一些问题。就像我们测试中发现,哪怕做vacuum,也不能马上更新VM数据。不能及时更新VM,会导致SQL语句的回表操作增加,导致covering index的初衷无法实现。

数据库使用过程中难免会遇到坑,在使用“完美的数据库”-Oracle的时候我们不也经常遇到BUG吗。遇到坑并不怕,怕的是遇到坑之后我们无法找到解决方案,也不知道这个坑到底是怎么回事。国产数据库并不只是在功能与性能上存在差距的问题,更大的问题可能是在今后的长期维护上,运维知识、运维专家、运维工具的缺失可能会更大地影响国产数据库的发展。

不过不管如何,走出第一步就没有后退的道理了,遇到坑就退回去也是不大可能的。企业在走出第一步之前,就应该未雨绸缪,安排好填坑的队伍,这样才能有备无患。

来源:白鳝的洞穴内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯