集中式資料庫與分散式資料庫的戰場與戰爭
可能有朋友會覺得今天我的這個標題有點累贅,直接說二者之間的戰爭不就行了,為什麼還用戰場與戰爭這麼繞口的標題呢?實際上戰場與戰爭是兩個不同的東西,戰場是戰爭的場地,而不是戰爭本身。分散式資料資料庫與集中式資料庫在剛開始的時候是為了解決不同的應用場景而分別設計的資料庫系統,最早的分散式資料庫與集中式資料庫相比也不是全功能的,而是為了解決某些集中式資料庫不太好支撐的應用場景而定製化開發的,經過多年的發展,分散式資料庫也逐漸成熟起來,開始向集中式資料庫的傳統領地發起了衝擊,這才有了現在如火如荼的集中式資料庫與分散式資料庫的戰爭。
為了更好的分析這場戰爭,首先我們來分析一下目前二者佔據的地形,以及發生戰爭的戰場的情況。前幾天和一個資料庫行業的朋友聊了幾句,談到有國外的機構預測集中式資料庫與分散式資料庫在市場上的可能的佔有比例是9:1,因為缺乏實際的資料因此我不太確定目前這兩種架構的資料庫產品的市場佔有率情況,不過大差不差吧,哪怕有朋友覺得這個比例有點極端了,那麼8:2肯定是沒有太大的問題的。不管是9:1還是8:2,集中式資料庫在未來市場上會佔比較多的份額,是能獲得共識的。可能有朋友看到這個數字會覺得分散式資料庫就沒活路了,這的如此嗎?
實際上這場戰爭絕對沒有這麼簡單,因為戰爭發生之前,戰場已經選定了,而且兩家都佔據了自己傳統的優勢領地。今天我們以國產商用資料庫為例來分析一下這場戰爭。
在戰場上不只是存在商用集中式和商用分散式這兩個冤家,他們各自還有同盟軍,那就是開源集中式與開源分散式資料庫。在抵禦對方滲透進入自己的傳統領地的時候,開源與商用產品是盟友,而在領地內部,二者也是爭鬥得十分激烈的。
分散式資料庫最初是為一些特殊的場景設計的,因此它們最初是從小眾需求出發研發的產品,受眾群體肯定沒有集中式資料庫大,不過這些小眾場景正好是比較有錢或者比較願意花較多錢的場景領域。一方以市場更為廣闊,不過客單價相對較低的使用者為基礎使用者群體,一方以市場相對較小,不過客單價相對較高的使用者為基礎使用者群體。這場戰爭的起點相對來說還是比較公平的。從使用者群體的數量上看,似乎集中式資料庫還佔一定的優勢。
不過如果仔細分析一下,你會發現集中式資料庫陣營裡還是比較複雜的,國產集中式資料庫廠商的日子過得似乎沒有基本面上看到的那麼好。這是為什麼呢?除了大量的國產集中式資料庫廠商之間的內卷之外,開源集中式資料庫也對商用產品產生了較大的衝擊。如果商用產品做得沒有比開源產品更加優秀,那麼憑什麼使用者要為資料庫產品埋單呢?除此之外,雲原生資料庫也在大量的侵蝕國產集中式資料庫的領地。雲的發展還處於加速期,企業上雲的加速度依然存在,因此來自雲原生、RDS的競爭壓力還在加劇。在這種形勢下,國產集中式資料庫守住原有陣線是不夠的,必須向分散式資料庫的領地發起攻擊,從而獲得較高客單價的高價值使用者,才能確保在這場戰爭中活下來。
分散式資料庫也有自己的問題,雖然目前獲得了一下價值較高的使用者,但是使用者的數量不足依然是個硬傷。資料庫產品必須經過大量使用者場景的磨合才能成熟,少量精品客戶只能把自己的產品做成專案,無法讓自己的產品快速成熟起來,因此他們也需要向集中式資料庫的傳統領域衝擊。在自己陣線內部,開源與商用分散式資料庫依然存在合作與競爭並存的問題,在攻擊集中式資料庫的陣地的時候,還要守住自己的基本盤,不要讓開源的盟友斷了自己的後路,依然是商用分散式資料庫廠商要關注的。只不過,在客單價比較高的客戶群體中,使用者更加看重服務,因此開源產品對商用分散式資料庫衝擊沒有開源集中式資料庫對商用集中式資料庫那麼大。
既然二者都想突破對方的領地,那麼就必須有能打的戰士。集中式資料庫需要在叢集計算能力、高可用、可擴充套件性等方面有所提高才能彌補自身不足,因此在融合資料庫、高併發處理、共享儲存多讀多寫(或者共享儲存讀寫分離)、快速應用切換等領域加強功能。這也是為什麼這兩年突然冒出來一大堆國產資料庫廠商都宣佈推出類似Oracle RAC功能的主要原因。因為缺乏這個功能,在高階金融使用者的爭奪戰中,集中式資料庫已經明顯落了下風。
分散式資料庫佔領目前集中式資料庫的領地,也不是那麼簡單的事情。資料庫小型化、強大的多租戶能力、更強的自治能力、更好的可觀測性以及易用性都是分散式資料庫想要在集中式資料庫的優勢領域參與競爭所必須做好的事情。
前幾天和一個國產集中式資料庫的朋友聊到這個問題的時候,他也認為目前集中式資料庫做得還不夠好,需要在產品上下大工夫,才能在這場競爭中勝出。不過好在他們前面有一個領路人-Oracle給他們帶路,不太會走偏。目前國產集中式資料庫存在的問題,還是能解決的,需要的是時間與大量的資金投入。而分散式資料庫存在的主要問題是複雜性,當分散式資料庫產品無法解決其複雜性帶來的問題的時候,就會限制其使用體驗,反而會在最終的競爭中落敗。決定這場戰爭勝敗的關鍵是誰先解決自身的問題,誰能把自身的問題解決得更好了。他認為最終能夠成功的資料庫產品一定是功能滿足使用者需求、使用起來比較簡單、總體使用成本最低的產品,就像馬斯克的特斯拉和SPAC-X。
我還是比較認同他的觀點的,解決好各自存在的問題,讓使用者用更低的使用成本,更便捷的使用的產品,必然是這場戰爭決定勝敗的因素。在資料庫領域,關係型營銷只能一時幫助企業獲得訂單,但是不能幫助企業從這種競爭中最終勝出。真正有能力把產品打造得更好用,更易用,更便宜,並且具有秉持長期主義的實力的企業才可能是最終的勝者。
來自 “ 白鱔的洞穴 ”, 原文作者:白鱔;原文連結:https://mp.weixin.qq.com/s/yCr6GHiWZAvlbjSeOF5RcQ,如有侵權,請聯絡管理員刪除。
相關文章
- 分散式資料庫的需求與場景分散式資料庫
- HarmonyOS Next方舟資料管理與分散式資料庫實戰:構建高效同步架構分散式資料庫架構
- 真正硬核分散式資料庫:開發分散式SQL資料庫的6種技術挑戰 - YugaByte分散式資料庫SQL
- 原生分散式資料庫與子資料庫子表中介軟體的區別分散式資料庫
- 區塊鏈與分散式資料庫的比較區塊鏈分散式資料庫
- 分散式資料庫分散式資料庫
- 關聯式資料庫與文件資料庫對比資料庫
- 分析型資料庫:分散式分析型資料庫資料庫分散式
- 從 Oracle 轉型 MySQL 分散式事務資料庫的實戰旅途OracleMySql分散式資料庫
- 分散式時序資料庫QTSDB的設計與實現分散式資料庫QT
- 強!分庫分表與分散式資料庫技術選項分析分散式資料庫
- 分散式 SQL 資料庫與表格最佳化技術分散式SQL資料庫
- openGauss 分散式資料庫能力分散式資料庫
- 螞蟻金服資深總監韓鴻源:像使用集中式資料庫一樣使用OceanBase分散式資料庫資料庫分散式
- 分散式資料庫火了 開源填補資料庫空白分散式資料庫
- 【許曉笛】EOS 資料庫與持久化 API —— 實戰資料庫持久化API
- 開源分散式資料庫RadonDB的核心技術與實現分散式資料庫
- 分散式資料庫事務故障恢復的原理與實踐分散式資料庫
- 乾貨好文:分散式資料庫DDL的編譯與執行分散式資料庫編譯
- 分散式快取--快取與資料庫強一致場景下的方案分散式快取資料庫
- 分散式資料庫 ZNBase 的分散式計劃生成分散式資料庫
- 資料庫與資料庫管理系統概述資料庫
- 實時資料庫與時序資料庫資料庫
- NoSQL資料庫概念與NoSQL資料庫家族SQL資料庫
- 國產分散式資料庫發展趨勢與難點分散式資料庫
- 38_資料庫實戰資料庫
- “熱搜”中的分散式資料庫分散式資料庫
- 分散式資料庫的健康評估分散式資料庫
- 資料庫國產化實戰之達夢資料庫資料庫
- 資料庫高可用面臨的挑戰與解決之道|OceanBaseDev資料庫dev
- 分散式資料庫拆表拆庫的常用策略分散式資料庫
- 《分散式資料庫HBase案例教程》分散式資料庫
- CNCC技術論壇|分散式資料庫HTAP的探索與實踐分散式資料庫
- 阿里雲資料庫的新戰役阿里資料庫
- 分散式資料(4)分散式與版本化分散式
- SQL Server實戰四:查詢資料庫的資料SQLServer資料庫
- 分散式文件儲存資料庫之MongoDB備份與恢復分散式資料庫MongoDB
- 資料庫新兵:分散式實時分析記憶體資料庫eSight資料庫分散式記憶體