保持兼容性應該是商用數據庫應遵循的原則

　　前些天一個D-SMART的用戶說在用PG 14的等待事件分析工具分析系統的等待事件的時候，發現工具能夠采集到相關的等待事件，但是無法對某些等待事件進行推理，導致部分等待事件背后隱藏的問題無法被發現。比如CommitTs等待事件應該代表了當時事務負載很高，而且當時服務器的IO性能不佳，但是工具并沒有展現出這方面的推理結果。 在我的印象里，PG的運維知識圖譜中是包含了這些等待事件的知識描述的，于是我打開系統檢查了一下。下一秒鐘，我驚訝地發現，在我們的知識圖譜里并沒有CommitTs這個等待事件，而是commit_timestamp。難道是PG 14的等待事件發生了變化？于是我查找了一下這方面的資料，發現從PG 13開始，PG的研發人員認為以前版本PG的等待事件名稱有些隨意，出于嚴謹的科學態度，從PG 13起作了較大的優化。在D-SMART中PG等待事件的知識圖譜是以PG 10為藍圖構建的，并且在11、12版本出現后都做了升級。但是PG 13后等待事件的知識圖譜就沒有做過升級了，雖然后面陸續增加了人大金倉、GAUSSDB等的等待事件，但是并沒有針對PG 13做升級。因此目前D-SMART的等待事件分析推理工具對PG 13或者以后的PG數據庫版本的支持是存在問題的。 數據庫的一些監控接口發生較大的變化是數據庫生態工具廠商最頭疼的事情，因為這些工具廠商必須投入巨大的成本才能不斷地進行版本適配。以前工具僅僅支持Oracle數據庫的時候，是沒有這個問題的，因為針對Oracle數據庫，我們只需要不斷的加入新版本的功能就可以了，不需要針對以前已經完成的功能不斷的進行版本迭代。Oracle的等待事件也是如此，新版本只會增加新的等待事件，不會修改已經存在的等待事件。最為典型的例子就是db file sequential read和db file scatterd read，這原本是Oracle內核研發中發生的一個烏龍事件，當時把離散讀和順序讀的等待事件弄反了，但是后來Oracle很“科學”的解釋了這個錯誤，但是出于知識延續性的問題，并沒有對此進行糾正。久而久之這兩個等待事件也成為了數據庫IO等待事件關于離散讀和順序讀的標準。在OWI方面也是如此，雖然目前v$session已經包含了完整的會話等待事件的信息，但是v$session_wait視圖依然保留著。我有時候還會偶爾錯用，用v$session_wait來分析等待事件。而新一代的DB可能都不一定知道這個接口到底是干啥用的。在OWI剛剛出來的Oracle 7.3.4里，這個接口就存在了，我們只能用v$session 來分析會話的其他信息，不能分析等待事件，因為等待事件只能從另外一個接口—v$session_wait中獲得。

　　保持數據庫接口的向下兼容性是對產品和客戶負責的表現，雖然PG 13后的等待事件命名更科學一些，但是我不大認可這種做法。因為這會打破知識的傳承，讓使用者的學習成本增加。在接口上也是如此，變來變去的接口讓數據庫核心開發人員覺得更爽了，因為確實改變后更合理了，但是對于使用者來說，其學習成本就大幅度增加了。去年年底Oceanbase 4.0發布的時候，我就和螞蟻的朋友吐槽，好不容易把OB 3.0復雜的監控視圖搞明白了，OB 4.0來了個大顛覆，我又得從頭學起了。OB的研發人員很驚訝的說：“你難道沒覺得現在的監控視圖用起來更舒服了嗎？4.0的視圖更加科學了！”。確實4.0的視圖更科學了，但是我并不喜歡，因為我還要從頭學習，以前的很多關于OB 的工具、和腳本也都要重新適配，這樣的更科學的接口，實際上是不夠科學的。更好的做法是保留這些接口，再新增一組“更科學”的接口。

　　商用數據庫不是開發者的玩具，而是要被用戶長期使用的，不斷升級的技術不應該讓使用者的知識不斷的過期，保持知識與接口的兼容性方面，我們的國產數據庫還是有很多地方要多學學Oracle。