資料庫產品用什麼抓住使用者

碼農談IT發表於2023-01-12

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

週五的文章有搞資料庫的朋友留言,談了對測試的一些看法。比如程式碼自主率測試,有朋友說可以要求資料庫廠商現場編譯,現場測試。我不知道有多少廠商可以很方便的把整個資料庫的編譯環境都部署到測試現場去,這對測試機構是個巨大的挑戰。哪怕真的可以這樣做,還是有些作弊手段可以使用的。我以前搞類似測試的時候,就有廠家把容易掃描出問題的程式碼做成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等能否相容也是十分關鍵的。這涉及到多廠商之間的生態協作,比起資料庫廠商自己就能幹的事情來說更為複雜,難度也更高,特別是涉及一些國外資料庫備份工具的情況。

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

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

來自 “ 白鱔的洞穴 ”, 原文作者:白鱔;原文連結:https://mp.weixin.qq.com/s/k_gA_P5PgRmBgGyfGhyPZw,如有侵權,請聯絡管理員刪除。

相關文章