国产数据库的文档真令人恼火

最近这段时间大多数时间都在研究国产数据库，为国产数据库编制知识图谱。同时发现一些新功能的时候简单的测试一下。去年的一个国产数据库相关的研讨会上我曾经说过，国产数据库的文档很差，可能会成为国产数据库发展中的一个比较严重的问题。这段时间对这个问题的认识就更加深刻了。

国产数据库的文档里，华为openGauss算是做得好一些的，好歹有十来个文档。

其中的开发者指南的内容最为丰富，有2000多页。似乎看上去做得还算可以了。不过如果你需要参阅这些文档的时候，你就会发现其中的问题。不知道是厂家不太重视文档还是产品经理的水平存在问题，这些文档从结构上，内容上都无法令使用者满意。作为一个运维人员，遇到运维方面的问题我肯定首先会选择管理员指南，数据库管理员不就是DBA吗，那么管理员指南就应该是DBA首选的文档。不过从这份文档只有600多K来看，似乎也不会有太丰富的内容提供给DBA。

果不其然，这份短短的只有90页的文档，除掉一些附录和目录结构，真正有用的部分不到80页，目录也只有一页零两行，只是介绍了DBA工作中的一些简单的操作，而且有一半的篇幅是在教人如何进行备份恢复和闪回。 似乎 openGauss的DBA除了备份恢复，启动 关闭之外，没有什么正经工作可干。

实际上，openGauss的文档里有价值的内容都在那份被称为《开发者指南》的手册中，而这份手册虽然有2000多页，不过不太像是一本给开发者看的参考手册，更像是一本数据库产品的reference。那些DBA才需要去使用的视图、存储过程的详细说明可能会把开发人员都给搞晕了。这份虽然厚度满满的手册，除了罗列reference外，真正能够指导开发者的内容也显得十分单薄。

昨天十分恼火的事情起源于在下班前我突然想试试openGauss去年十分高光宣布的USTORE，USTORE是华为对PG数据库的一个十分大的内核修改，在内核中支持了一个不同于PG的APPEND STORE(ASTORE）的USTORE，USTORE是一种堆表存储结构，数据的修改不会新增一条记录，而是在原来的记录上修改。

USTORE绝对是一个革命性的PG内核修改，实际上PG社区也有不少人进行过一些尝试，目前为止，还没有很好的内核代码能够合并进PG的主版本。openGauss已经在代码中正式包含了USTORE存储引擎，只是目前默认建表还使用ASTORE，可以通过enable_default_ustore_table参数可以控制默认建表的存储引擎模式，否则可以在建表脚本上选择使用USTORE引擎。

我想建表操作起码应该能在2000多页的开发人员指南中找到了吧，于是满心希望的打开手册，如愿以偿的找到了建表语句的章节。

你不是逗我的吧，短短的几行建表语句说明，哪怕你去抄一下PG的文档，也至少有十页八页吧。我不死心地在文档中查找USTORE相关的信息。

一杆子给我支到14章性能优化上去了。在查找文档无果的情况下我只能借助于度娘，好歹找到了几篇介绍了USTORE的文章，大多数是华为的宣传USTORE如何强大的文章，只有一篇文章里有人测试了在USTORE上建表。

我懒得修改benchmark工具里的脚本，选择直接修改参数来进行测试。没想到从其数据库后开始runDatabaseBuild过程中突然报错了，到数据库服务器上一看，高斯DB的服务进程没了，一查日志发现数据库已经宕了。于是重启数据库再来测试。数据库启动后，benchmark工具连不上数据库，于是只能再次关闭数据库，来回折腾了好几圈，数据库终于起来了。不过Build warehouse的过程中，数据库再次宕了。

这回我仔细阅读了一下数据库的日志，发现原来是nofiles超了。这个benchmark Props文件我使用了很长时间了，以前使用ASTORE的时候也做过多次压测，都是没问题的。

难道使用了USTORE之后，数据库打开的文件数量增加了很多。超出了以前我设置的1024？不过对于多线程结构的openGauss来说，nofiles设置为1024确实小了些，于是我把nofiles 增加到26万，再次压测，数据库不再宕了，压测顺利完成，不过从压测结果来看，比以前使用ASTORE还略微有所下降，并没有质的提升。可能是我在某些参数配置方面还存在问题，没有发挥出USTORE的性能吧，不过到底问题出在哪里了，我也真的不知道到哪里去找这方面的文档资料。

唯一能给我一些帮助的是D-SMART的等待事件分析工具，以后有时间，先按这方面去做些优化看看吧。