面對互聯(lián)網(wǎng)業(yè)務的不斷深化以及業(yè)務量的爆發(fā)式增長，傳統(tǒng)數(shù)據(jù)庫架構迎來了前所未有的挑戰(zhàn)和變革。在傳統(tǒng)數(shù)據(jù)庫領域，Oracle一直占據(jù)了很大的市場份額，很多企業(yè)的業(yè)務系統(tǒng)基于此實現(xiàn)OLTP交易場景。近年來，隨著分布式技術的發(fā)展，分布式數(shù)據(jù)庫逐漸占據(jù)了OLTP領域較大的市場，尤其在互聯(lián)網(wǎng)領域，MYSQL、PG等分布式數(shù)據(jù)庫的應用非常廣泛。在中國，軟件國產(chǎn)化、自主可控戰(zhàn)略的提出，“去Oracle”逐漸被提上日程，非互聯(lián)網(wǎng)企業(yè)也開始考慮數(shù)據(jù)庫轉型。其中，分布式數(shù)據(jù)庫即是一個重要轉型方向。然而，分布式數(shù)據(jù)庫應該如何在企業(yè)中正確地落地，一直是業(yè)界討論的焦點，首當其沖的問題就是：分布式數(shù)據(jù)庫是否能替換Oracle？在回答這個問題之前，先來看看分布式數(shù)據(jù)庫的發(fā)展歷程和特點。20世紀80年代，伴隨著關系數(shù)據(jù)庫理論的誕生，IBM和Oracle兩家公司開始提供商業(yè)化的數(shù)據(jù)庫產(chǎn)品，服務于各類大型企業(yè)。初期的數(shù)據(jù)庫都是單機軟件，跑在專有的硬件之上，比如IBM的大機、小型機，如果業(yè)務量或者數(shù)據(jù)量增加，只能進行垂直擴展，即采用增加CPU、存儲的方式。這套體系的優(yōu)點是非常穩(wěn)定，缺點是開放性不夠，與通用x86服務器體系之上的開發(fā)環(huán)境兼容性差，另外當業(yè)務量增長過快時，其擴展能力有限，而且這套系統(tǒng)的造價非常昂貴。2000年以后，隨著互聯(lián)網(wǎng)在線業(yè)務的發(fā)展，業(yè)務系統(tǒng)訪問的并發(fā)度呈指數(shù)級上升，海量數(shù)據(jù)計算和分析需求越來越普遍，傳統(tǒng)單機系統(tǒng)在業(yè)務支撐、成本、開放性等方面均面臨巨大挑戰(zhàn)，數(shù)據(jù)庫垂直擴展的模式也無法維系。以支付業(yè)務為例，隨著在線購物、在線繳費方式的普及，支付業(yè)務系統(tǒng)的并發(fā)量迅速增長，尤其是在“雙十一”“618”“春節(jié)搶紅包”等場景下，每秒有上百萬筆支付交易。互聯(lián)網(wǎng)企業(yè)開始探索新的水平擴展的方案，最常見的就是應用系統(tǒng)通過分庫分表進行解決。但是，這種解決方案的應用系統(tǒng)需要做大量改造，需要感知數(shù)據(jù)存儲位置，增加了運維的復雜性，并因此出現(xiàn)了中間件的方式，如Mycat等。這種方式雖實現(xiàn)了數(shù)據(jù)對應用的透明，但未解決數(shù)據(jù)庫運維的痛點。隨著大數(shù)據(jù)技術的發(fā)展，以Hadoop、Greenplum為代表的非結構化大規(guī)模數(shù)據(jù)處理技術崛起。這些技術主要采用Shared-nothing架構，在分析領域率先實現(xiàn)了分布式的擴展，分析的主要任務是數(shù)據(jù)的查詢，其應對的挑戰(zhàn)主要是海量數(shù)據(jù)的存儲、計算，對于事務的要求較低。2010年后，谷歌Spanner、Tidb采用Paxos或Raft等一致性協(xié)議來解決中間件方案的單點瓶頸問題，這為事務數(shù)據(jù)庫的分布式化提供了新的理論依據(jù)。之后，分布式數(shù)據(jù)庫發(fā)展迎來了熱潮，各類分布式數(shù)據(jù)庫百花齊放。相比于傳統(tǒng)的單機或主備模式的集中式數(shù)據(jù)庫，分布式數(shù)據(jù)庫是傳統(tǒng)數(shù)據(jù)庫技術與計算機網(wǎng)絡的有機結合，在平滑擴展、高性能、高可靠、高可用、低成本等方面具有優(yōu)勢，特別是當數(shù)據(jù)量上升到一定程度，在性能方面可突破集中式數(shù)據(jù)庫的瓶頸。回顧過去10年，分布式數(shù)據(jù)庫經(jīng)歷了從行業(yè)質(zhì)疑、小規(guī)模試水、到如今在金融、互聯(lián)網(wǎng)等行業(yè)的探索和應用，有一些甚至在生產(chǎn)系統(tǒng)中得到大量應用，可以說分布式數(shù)據(jù)庫的春天已經(jīng)到來。那么，分布式數(shù)據(jù)庫足以替代Oracle這樣的傳統(tǒng)數(shù)據(jù)庫了嗎？傳統(tǒng)關系型數(shù)據(jù)庫在核心交易等領域深耕了40多年，到目前為止，大部分純交易場景不論從數(shù)據(jù)量還是商業(yè)模式都沒有本質(zhì)的變化，其業(yè)務的擴展空間的確十分有限。在企業(yè)數(shù)字化轉型的過程中，數(shù)據(jù)量隨著業(yè)務發(fā)展快速膨脹，為數(shù)據(jù)庫帶來全新的市場機遇。而分布式數(shù)據(jù)庫的設計初衷，正是為了解決全新的數(shù)字化業(yè)務問題。在Oracle所無法滿足的場景中，分布式數(shù)據(jù)庫成為了理想的落地方案。但值得注意的是，在替代Oracle的問題上，并沒有一刀切的答案。分布式數(shù)據(jù)庫的誕生，首先是為了解決傳統(tǒng)數(shù)據(jù)庫不擅長的場景，在關系型數(shù)據(jù)庫做到極致的領域同樣需要很長的時間才能完善，并不是為了單純替換某個原有系統(tǒng)。如果只是為了使用及推廣新技術，而進行固有架構的替換，將會面臨極大的技術風險與挑戰(zhàn)。可以看到，目前國內(nèi)絕大部分的分布式數(shù)據(jù)庫的產(chǎn)品試用，都是在一些非核心系統(tǒng)的應用。例如：在金融機構，分布式數(shù)據(jù)庫常用于渠道類業(yè)務如：網(wǎng)聯(lián)、第三方支付對接等，在生產(chǎn)環(huán)境中驗證產(chǎn)品功能和穩(wěn)定性，并沒有實現(xiàn)真正的替代。同時，分布式數(shù)據(jù)庫的產(chǎn)品成熟度也有待提升。相比較于DB2、Oracle等商業(yè)數(shù)據(jù)庫和MySQL 等開源數(shù)據(jù)庫，分布式數(shù)據(jù)庫產(chǎn)品在生態(tài)圈、技術手冊、技術支持等多個方面，還是稍遜一等，仍然有大量可提升的空間。由于尚無統(tǒng)一的業(yè)界標準，也沒有哪一款分布式數(shù)據(jù)庫產(chǎn)品，是這個領域不可爭議的第一名，就如同Oracle一樣。對于分布式數(shù)據(jù)庫而言，想要替代Oracle，更大難點在于如何從Oracle遷移出來。很多企業(yè)原本都是傳統(tǒng)數(shù)據(jù)庫一體化解決方案，其設計與運維經(jīng)驗不一定完全適合分布式數(shù)據(jù)庫。從Oracle遷移至分布式數(shù)據(jù)庫就會遇到各種障礙，例如：不同數(shù)據(jù)庫之間的異構數(shù)據(jù)如何做到無損遷移？ 遷移過程中如何保障系統(tǒng)穩(wěn)定性？ 如何設置異構數(shù)據(jù)庫并行過渡期？ Oracle數(shù)據(jù)庫往往和應用耦合度較高，遷移過程還會涉及到應用遷移和改造，如何評估改造量和改造難度？兼容性如何保障？ 數(shù)據(jù)庫遷移完成后如何成功建轉運？ 傳統(tǒng)運維方案中的網(wǎng)絡、存儲、監(jiān)控告警、備份恢復等等應該如何規(guī)劃？
除此之外，盡管分布式數(shù)據(jù)庫比原來各業(yè)務系統(tǒng)獨立使用數(shù)據(jù)庫更加易于運維，但是剛引入分布式數(shù)據(jù)庫，難免碰到運維技術和人力跟不上的階段。這些都是分布式數(shù)據(jù)庫需要解決的現(xiàn)實問題。從全球數(shù)據(jù)量發(fā)展的方向來看，其爆發(fā)性增長，主要集中在基于數(shù)字化創(chuàng)新的多樣化業(yè)務場景。因此，單純替代傳統(tǒng)Oracle占據(jù)核心優(yōu)勢的固有領域，并非是分布式數(shù)據(jù)庫未來的增長方向。分布式數(shù)據(jù)庫的最佳落地與使用方式，是從海量數(shù)據(jù)業(yè)務到核心的逐步迭代過程。先從存在海量數(shù)據(jù)彈性擴展的新興業(yè)務需求入手，隨著業(yè)務革新不斷的深入，逐漸滲透進傳統(tǒng)業(yè)務及應用中。企業(yè)在選擇分布式數(shù)據(jù)庫落地場景時，也應該選擇適當?shù)膽脠鼍埃哉嬲l(fā)揮其優(yōu)勢能力，并持續(xù)打磨技術團隊的運維能力，并逐步推向核心。
|
