前情提要《信通院HTAP数据库评测那些事——踩坑篇》。
聊完了具体的功能以及踩过的坑，第三篇我想以对评测内容以及评测这件事本身做一个吐槽，估计会是一篇得罪人的内容。
评测内容
信通院的评测内容，我个人感觉，整体上还是比较完善的，强调了数据库基础能力的重要性，又对诸多方面做了要求，除此之外对于运维、可靠性、高可用等方面也有要求。然而在踩坑的过程中，我仍然还是对个别内容有一些不一样的看法。
缺少关键内容。数据库作为一个基础软件，可靠性和稳定性要求是极高的，达到7x24不间断，也刚刚进入一个及格线，这一点和应用软件有着本质区别。但是就评测内容来说，显然缺少对可靠性和稳定性以及服务连续性的更高要求。在测试过程种，如果实例频繁重启，只要功能点过了是否合格？这个问题其实挺耐人寻味，最起码从一个DBA的角度，我认为这是不及格的。然而信通院评测种，并没有对这方面做出明确要求。
内容存在不合理。例如同时满足行列两种存储，这个必要性就没那么强。哪怕是Oracle，在exadata之外的场景下，也仅仅只支持一种。但是谁敢否定Oracle是一个HTAP数据库？扩缩容基本都是建立在分布式数据库的角度，对于集中式数据库的资源扩展没有提及。事实上不是分布式就一定比集中式强，也不是所有业务都必须用分布式。两种架构的数据库是一个长期共存的关系，不存在谁比谁一定高明。
内容要求不明确。比如分析函数，什么是分析函数，这个东西每个人理解都不同，聚合函数用来做数据分析，算不算分析函数？资源隔离这一项更是语焉不详，如果我用容器限制了每个节点资源，容器的服务又打包在数据库软件安装包里，那么这歌容器算不算是数据库软件自带的功能？sequence功能提供了明确的sql，alter sequence xxxx，那么我做一个自增单列表，只保留一行数据，这种操作算不算是个序列？
从内容本身来看，能感觉出来一些内容也许是某些厂商夹带的私货，影响了评测标准制定。同时也能感觉到个别标准也比较仓促，并没有做细致的审阅和评估。导致了在测试之前准备内容的时间里，存在着大量不确定的项目要去沟通，标准的不确定性，实际带来了很多开发商的麻烦。
评测这件事
回到评测本身，HTAP数据库评测的意义在哪里？这一点和考认证有点像。
如果某家厂商刚开始起步，那么HTAP评测是一个很好的指导材料，告诉你哪些功能有用。按照这份材料去做开发路线，按部就班地把开发工作做好，是一个不错的思路。如同我们去学一个新数据库，拿着认证材料去学习，也算是一个常见的思路和学习方式。包括我本人学习PG都是按照PGCA和PGCE的材料跟着姜殿斌老师在课程中一步一步掌握了基本知识点和一些实践。所以，刚起步或者产品还在成长期的HTAP数据库团队，是可以用这个评测来结合自己产品的开发。
如果是一个已经有一定年头的数据库产品，同样可以使用这份材料查漏补缺。人总是有信息茧房，有时候通过不同方式不同来源获取到的信息，也许或多或少地可以打破或者扩展自己的视野范围，我本人在参与这次评测之后，也发现自己对不少数据库功能的认知存在盲区。经历了一段时间的调研和学习之后，才把它们慢慢消化掉。不可固步自封，须知人外有人天外有天，总有一些点总有一些东西，是自己未曾深思的。
反过来说，通过了HTAP评测，也并不意味着产品成为了合格的HTAP数据库。对于可靠性、性能、易用性都仅仅是做到了最基本的要求，而数据库开发本身就是一个长期内容，短则五年，长则二三十年都不意外。如同一个有数据库认证的DBA，和真实水平之间存在差距一样，有各种认证的数据库，与在生产上合格相比，仍然还有或多或少的差距。真正上生产的时候，还是要靠硬实力说话，而不是有多少个认证，过了多少个评测。
早上在一个数据库群里，一位从事国产数据库的大咖群友说了三点内容，让我无比认同：
1、全能的通用型数据库：盲目求大求全，结果什么都没做好
2、胡乱鼓吹新名词：概念PPT满天飞，能力还没有发布就先售卖
3、做产品变成做项目：特性没有延续性，东一枪西一炮
不要总想着搞一堆名头，而忽略了数据库本身最重要的东西；不要总想兵马未动，造词先行，吹一万不如做一件；做一个产品如同一局狼人杀，不要只看到某一次发言，某一个轮次，而忽略了整局游戏。
求木之长者，必固其根本；欲流之远者，必浚其泉源。源不深而望流之远，根不固而求木之长，斯亦伐根以求木茂，塞源而欲流长也。
