?周五聊了下數據庫基準測試的一些事情，現在客戶選擇數據庫產品，唯一比較有權威的就是一些國測機構的測試結果。企業自行搞選型測試是十分困難的，一方面成本太高，一方面自己的能力不足，很容易被人忽悠瘸了。

周五的文章有搞數據庫的朋友留言，談了對測試的一些看法。比如代碼自主率測試，有朋友說可以要求數據庫廠商現場編譯，現場測試。我不知道有多少廠商可以很方便的把整個數據庫的編譯環境都部署到測試現場去，這對測試機構是個巨大的挑戰。哪怕真的可以這樣做，還是有些作弊手段可以使用的。我以前搞類似測試的時候，就有廠家把容易掃描出問題的代碼做成lib庫，或者甚至把這些obj打到linux系統的lib庫中，跟隨著編譯依賴庫一起通過YUM先安裝好，然后直接鏈接到應用系統里，這樣我們的掃描工具就掃描不出這些代碼的問題了。

實際上對于絕大多數用戶來說，關心的并不是數據庫代碼是否自主，而是數據庫本身的功能是否滿足自己的需求。對于一些國企央企或者國有控股企業來說，對于代碼自主率的焦慮主要是怕自己選擇的數據庫產品最后無法被國家認可為信創產品。信創數據庫的認定國產以前是采用清單的，不過這個清單覆蓋面太小，因此也被廣為詬病。

除此之外，實際上客戶最為關心的問題就是國產數據庫用起來是否便捷、數據庫可靠性如何，高可用切換是否簡單可靠、數據庫的性能如何、數據庫的運維難度如何、數據庫的周邊生態工具是否完備。

數據庫用起來是否便捷實際上是用戶在做數據庫選型的時候最為關注的問題這個是設計師并不是我們的數據庫廠商最為關注的問題，不過對于一些運維能力相對不足的中小型客戶來說，在數據庫選型的時候可能會把使用便捷性放在第一位。很巧的是，最近在和兩個金融用戶討論國產數據庫選型的時候，他們都在三四個數據庫中做選擇，經過測試試用后不約而同的選擇了TDSQL。當時我覺得有些意外，后來詢問原因后才明白了其中的奧妙。實際上TDSQL并不是一個數據庫，而是一個數據庫云平臺，其扁鵲平臺可以很方便的維護一個大型的數據庫云平臺，像普通的云平臺提供的RDS一樣快速交付各種數據庫。TDSQL不是一個數據庫，TDSQL平臺可以提供單機MYSQL實例、單機PG實例、分布式數據庫等。客戶選擇TDSQL的最終原因是他們的MYSQL單實例對他們遷移一些小系統來說完全夠用了，而扁鵲平臺的能力讓他們節約了大量的建設投入。在國產數據庫內卷如此激烈的時候，數據庫產品在核心能力上提升很難，但是提供一個類似“扁鵲”的平臺，我想并不困難。

數據庫一旦上線運行后，就難免會出現各種問題，導致實例宕機。用戶也認可單實例數據庫肯定是不能100%可靠的，但是如果數據庫實例宕機后能夠做自動遷移或者自動重啟，對于核心生產系統來說，可以秒鐘級主備自動切換，對于普通業務系統來說，可以分鐘級故障恢復，那么數據庫實例宕機并不會對核心業務產生重大影響，這些都是可以接受的。最主要的是數據庫廠商要能夠提供一個完整的解決方案，既可以方便的部署，也可以放心的使用。類似于Oracle GDS的能力，對于用戶的關鍵應用來說是十分必要的。

至于數據庫的性能，這是用戶在做數據庫選型時最為迷茫的，什么樣的性能才是企業所需要的。TPCC肯定不是用戶數據庫性能的關鍵點。很多應用系統從Oracle遷移到國產數據庫的時候，并不是因為國產數據庫并發處理能力不足而出現了性能問題，而是因為國產數據庫在表連接算法方面的的性能差異，執行計劃方面的差異導致了較大的性能差異。我遇到過一個客戶的數據庫從Oracle遷移到某國產數據庫后，核心業務模塊普遍性能下降了二三十倍。經過分析發現，最多的問題是因為索引設計導致的，原有的索引設計在Oracle上效率還不錯，但是到了國產數據庫上就不行了。還有一些是國產數據庫的表連接方面與Oracle存在技術差異，很多SQL在國產數據庫上無法使用Oracle上的執行計劃。遇到這種情況，我們就只能通過改寫SQL來解決問題了。目前的國產數據庫替代存在大量的存量替代問題，因此國產數據庫產品需要做好這方面的對比測試，如果數據庫產品確實無法采用較好的執行計劃來執行某些SQL，則應該發布優化建議，讓用戶能夠快速找到解決方案。

對于數據庫來說，除了數據庫核心的能力之外，生態工具的完備性也十分關鍵，比如數據庫異構復制工具、數據庫遷移工具、數據庫備份工具等。數據庫系統往往不是孤立的，異構數據庫之間需要進行雙向的數據復制，因此國產數據庫需要能夠和一些主流的國產數據庫、開源數據庫、大數據平臺之間進行雙向數據復制。甚至在目前階段，國產數據庫與Oracle之間的數據雙向復制工具還是必須存在一段時間的。數據庫遷移工具主要是支持將應用與數據從Oracle遷移到國產數據庫，不僅僅能夠遷移表結構，還要能夠支持大數據量的批處理遷移與增量復制。另外還需要能夠遷移Oracle 的PL/SQL存儲過程，讓整個數據庫應用能夠很便捷的遷移過來。備份是另外一個大問題，雖然所有的數據庫廠商都提供了備份工具，但是備份工具與主流的磁帶庫，備份管理工具，備份一體機，CDM等能否兼容也是十分關鍵的。這涉及到多廠商之間的生態協作，比起數據庫廠商自己就能干的事情來說更為復雜，難度也更高，特別是涉及一些國外數據庫備份工具的情況。

除此之外，數據庫的運維接口與運維工具也十分關鍵。目前大多數國產數據庫能夠提供的運維接口十分有限，數據庫廠商能夠提供給客戶的運維知識更是鳳毛麟角。國產數據庫對于用戶來說就是一個十分不穩定的黑匣子，說不準什么時候就出問題了。更有甚者，有些用戶現場的問題，我們的數據庫廠商都很難定位問題的原因，這樣的數據庫產品讓用戶用得提心吊膽的。

提升數據庫核心的能力，這需要很長的時間的積累，甚至無法完全依靠數據庫研發團隊的技術能力。很多數據庫性能的提升是在實際應用中遇到了問題，才去想辦法解決的。研發人員在設計數據庫產品的時候很難想得到這樣特殊的應用場景。因此這些核心能力的積累是需要時間的，很難一蹴而就。不過我今天提到的一些能力都是在數據庫核心能力之外的，只要我們的數據庫廠商想去完善，也是完全有能力做到的。?