在過去的兩三年里，國產數據庫成了熱點。各家廠商如雨后春筍一般破土而出，向陽而生。這種局面放在10年前是難以想象的。身邊也有朋友的公司開始引入各類國產數據庫。然而我們都很清楚，開發一個穩定成熟的數據庫，是一件門檻極高風險極大的工作。即便是有MySQL或者PG這種穩定的開源產品，在它們基礎上進行開發，仍然是一個以年為單位的事情。
這期間，也有一些做數據庫國產化的廠商和朋友問我，你覺得什么樣的數據庫是一個“好數據庫“。而每逢此時，我都會問他們，是讓我以一個專職DBA的視角回答，還是以一個旁觀者的視角回答。事實上，每個角色對于“好”的標準差異很大。最后得到的答案幾乎是一邊倒的DBA視角，最終也促使我去寫了整個系列的文章。鋪墊了前兩篇之后，終于該去回答一下我的答案了。
必備要素1：穩定性
既然是做數據庫，當然要在生產環境跑。而生產環境，對DBA來說，穩定性永遠是第一要務。性能再好功能再多，穩定性有問題，不但DBA不會喜歡，業務部門也不會去用。
這里說的穩定，既包含了服務狀態的穩定，又包含了性能穩定，同時還有一個隱性的指標，成本的穩定。前兩者我相信很多人都理解，成本的穩定指的是什么？
通常來說，一個企業，尤其是傳統企業，每年的IT預算不會出現太大幅度的增長，除非有特殊的原因，能夠說服相關負責人。如果數據庫軟件，隨著業務規模和數據量的增長，成本的增長是可以預期可控的，這才能在每年預算中游刃有余。但是如果我規模是10的時候成本是10，規模是20的時候，成本變成了30甚至50，這在成本的穩定性上就會出現大問題。這里面的成本既包含了軟硬件成本，又包含了人員成本。而比較糟糕的是，成本的穩定性往往都是在跑了一定時間之后才發現，這時候要么就接受更高的成本，要么就是選擇更換數據庫軟件，是一件很痛苦的事。
在這一點上，我覺得目前主流的商業數據庫都能做到成本的穩定性。而對于國產數據庫來說，需要通過時間來驗證。到了大規模使用，長時間使用之后，來檢驗這個事情。
必備要素2：易用性
一個數據庫如果從安裝配置到后期運維，全程都都很難用的話，注定不會成為一個好數據庫。
早期的Oracle安裝配置真的不友好，尤其是RAC的安裝，通常一個熟練的DBA照著文檔都得按天計算來折騰。盡管現在Oracle提供了RPM包安裝的方式，但是在安裝時也很難一帆風順。好在安裝完成之后，需要二次折騰的頻率就大幅下降了。加上現在Oracle自帶的OEM不斷完善，很多時候我干脆用圖形界面去完成很多日常工作，整個的效率提升了很多。而SQL Server的安裝和運維可能是我個人感覺易用性做的最好的，小到一次備份恢復，大到一次服務器遷移。
MySQL和PG安裝配置確實是簡單了很多，可是后期運維的時候，在功能和性能面前，都需要DBA和開發人員做各種取舍。在出了問題之后，各種診斷和排查工作，缺少足夠的信息支撐，很多的時候要靠猜和反復比對。這一點上，一些基于MySQL與PG開發的國產數據庫，也沒有做到實質性的改善。
倘若一個公司只用了一兩種數據庫，易用性不強的問題可以通過深入學習來慢慢抵消，可是很多的時候，一個DBA要運維五六種數據庫的時候，易用性的好壞可能直接影響了DBA的工作難度，而這種難度的提升，是否存在真正的意義，有時候是要打一個問號的。
必備要素3：輔助工具
一個好漢三個幫，數據庫想完成自己的工作，有時候也不是一個引擎就能搞定一切的，需要很多內置的外置的工具來共同完成。
商業數據庫往往選擇了把這些必備工具打包到自己的數據庫產品里，比如AWR、RMAN、ADG，都已經成為了Oracle數據庫的組件之一，伴隨著數據庫軟件的安裝一次搞定。而像OGG這類根據需要來選擇的則可以單獨配置安裝。SQL Server更是夸張到希望把所有輔助組件都集成到一個官方運維工具里。
主流的開源數據庫在這里則是選擇了另一個路徑，只提供了盡量少的輔助，而把更多必需的工具，交給開源社區來完成。好處是同一個需求可能找到很多不同的選擇，缺點是有的時候，想要精準找到匹配自己需求的工具或者插件，不僅僅需要時間，有時候也需要一些運氣。
如果未來有更多的新型數據庫出現，從DBA的角度，我理想中的狀態是兩者皆有，既能有足夠強大的官方工具提供支持，又能有比較豐富的開源社區工具提供補充。小孩子才做選擇，我有點貪心，什么都想要。
必備要素4：安全審計
在金融行業或者上市公司做DBA，日常永遠繞不開的就是安全和審計。即便不在上述這兩種企業，對于數據庫的安全，也是一個非常敏感的話題。現在數據庫行業，很多產品都標榜自己符合金融級別的安全。也側面說明了，數據庫安全是一個強需求。
如果一個數據庫軟件，做不到足夠的安全，是不會有企業客戶和DBA敢把它放到生產環境跑關鍵業務數據的。不安全的數據庫，無疑給自己挖了一個坑。權限和角色管理完備，安全機制足夠好，是DBA對一個數據庫最基礎的要求。甚至有的時候，一些資深的DBA希望把自己的權限都能盡量收縮，以便減少誤操作所帶來的的損失。
審計的意義在于，讓小到一條查詢，大到一次停庫，都能有跡可循。當然，實際生產環境，我們很少會讓每一次查詢都記錄在日志中，但是我不用不代表你可以沒有。真正到需要的時候不能提供，才是尷尬的時刻。
必備要素5：備份恢復與高可用
這里的備份恢復，既包含了冷備份與恢復也包含了熱備份與恢復，而且是可以異機恢復的。
可能有讀者看了這條會說，會有數據庫廠商或者團隊不提供這個嗎？你可別說，真的有。以前接觸過一個初創的數據庫團隊，我問他們，數據庫連熱備都不提供，你讓我每次備份數據都是停庫復制文件嗎？對方振振有詞地說，我們這是分布式多副本的架構，你有了這一套東西，就等于有了多個冗余。說出這話，讓我意識到，對方根本不了解一線數據庫運維的需求，都是在腦補。即便是分布式多副本，在一些行業中，仍然要求數據庫要有單獨的備份介質，可以單獨恢復數據，并且有硬性的保存的年限。即便行業和公司沒有要求，對于DBA來說，備份的數據都是自己最后一道防線。
而高可用也是同理，銀行業的兩地三中心是監管的強制要求。即便沒有強制要求的行業，高可用冗余所帶來的停機損失，也是遠遠小于從備份里恢復的。而且這個高可用的冗余，最好也是可以做switchover的。有時候我們看到某個系統因為故障導致長時間停機的時候，我總會下意識地去問，沒有冗余嗎？生產環境掛了，怎么不切換到備用環境？
極端情況，是一個合格的DBA永遠需要考慮的。
必備要素6：版本管理
一個數據庫軟件的生命周期可能長達10年，這期間無論是內部還是外部的變化，有時候都會比我們想象的還要大。這期間做版本升級或者打補丁，都是不可避免的。
好的數據庫，能夠做到補丁的升級，同時對業務數據不會有影響。倘若我打一個補丁，數據讀不出來或者不準確了，那就成了災難。同時還得有回退機制，不能我這一個補丁打上去，發現有問題還不能回退，只讓前進不讓后退。而到了大的版本升級的時候，升級的步驟和結果必須是確定的。1.0到1.1升級，要是不同機器的結果千差萬別，那干脆直接安裝一套新的好了。
這里面還有一個隱性的要素，相鄰版本之間的操作思路以及方式，不要有太大差異，給DBA一個過渡的時間。倘若升級了，哪哪都得重新學，這也是一個很要命的點。
寫完這6個，我還反復斟酌了幾個點，例如新特性是否及時、不同數據庫之間的數據導入導出是否方便，這些固然都是成為“好數據庫“的要素，但不能算必備要素。取一個“好數據庫“的最大公約數，大概就是這6點。
