【数据库实现感悟】算子实现的第一天就应该考虑可观测性

很多算子有外部观测的需求，例如 sort 消耗了多少内存，落盘了多少数据、transmit 算子传输了多少网络数据，耗费了多少时间做等待，等等。

Oracle 做得特别好：下图中，红框里的内容都是 Oracle 为算子的可测性做的工作。

如果设计的第一天就把可测性放在心中，整个数据库组件的架构设计会有更好的抽象。例如：

• Sort 组件：对于 MERGE GROUP BY, MERGE SORT, SORT 三种算子，他们都会共享一个 Sort 组件，Sort 组件内部负责做具体排序工作。那么这三种算子如果想统计 Sort 的细节数据，他们就要定义好和 Sort 组件的交互方式。再比如
• Store 组件：SORT、HASH JOIN、WIN FUNCTION 等都有内存不足时写数据到临时文件的需求，他们会共享一个 Store 组件，Store 组件内部负责组织管理临时文件和数据缓冲区。如何让 Store 的内部数据透出给组件使用者？这也需要设计一定的接口。
• Transfer 组件：EXCHANGE IN、EXCHANGE OUT 算子都需要做网络交互，依赖于 Transfer 组件（OceanBase 里称为DTL）。如何让 Transfer 组件的内部统计数据透露给 EXCHANGE 算子，需要做设计。
• 锁：无处不在的锁，如何跟踪他们的消耗？如何让这些消耗可观测？
• Operator Specific Requirements：特定算子的个性化信息如何有效被观测？比如 HASH JOIN 里 HASH 冲突的次数。

如果我们多考虑一些类似的需求，能指导我们抽象出一套通用的接口，让实现系统可观测性成为非常简单的一件事。框架写得好，无论新人还是老鸟，新增功能时可以非常低成本地提供可观测性支持。

这个事情需要早做，早做成本低，晚做成本高，甚至做都做不了。做不了是怎么讲呢？

想想吧，一个 Store 组件，可能嵌套在一个叫 MyPerfectAutoStore 组件下 10 层深的地方，如何把它的指标取出来呢？后期做的话，不知道要费多少事，hack 多少代码，把好好的东西改成一坨屎。谁都不爱吃屎。