分布式數(shù)據(jù)庫選型分析

分布式數(shù)據(jù)庫選型分析

數(shù)據(jù)庫向左，中間件向右公公【摘要】近些年來傳統(tǒng)集中式數(shù)據(jù)庫已不能滿足需要，分布式數(shù)據(jù)庫成為必然的選擇。金融行業(yè)作為數(shù)據(jù)應(yīng)用的高地，對(duì)數(shù)據(jù)庫的要求更高。然而面對(duì)紛繁復(fù)雜的數(shù)據(jù)庫種類，該如何選擇呢？本文嘗試從分布式數(shù)據(jù)庫的發(fā)展路線、技術(shù)分類、行業(yè)痛點(diǎn)等角度，談?wù)劮植际綌?shù)據(jù)庫的選型問題。L分布式數(shù)據(jù)庫演進(jìn)之路2010分布式數(shù)據(jù)庫發(fā)布?1970s>2006?2008?2010?2012?2014?2016?2018IBMDB2.MPP內(nèi)存數(shù)第庫ORACL-e?1970s>2006?2008?2010?2012?2014?2016?2018IBMDB2.MPP內(nèi)存數(shù)第庫ORACL-eORACLE發(fā)布8*MapReduce.Bk}TableHadoopCassandra,RedisiMongoDBOlARPG4amazon第一款開派數(shù)據(jù) Dynamo論文發(fā)布Google.levelDBSpanner.F1AWSAurorafacebook才2kRgOceanBaseA■訊DCDB阿夔PolafPB.HDFS.HiveHBse【難點(diǎn)】廠商綁定風(fēng)險(xiǎn)高選擇某廠商產(chǎn)品，也就意味著選擇某一技術(shù)路線，如果深度依賴廠商產(chǎn)品的特有能力，無疑存在綁定風(fēng)險(xiǎn)問題。這點(diǎn)對(duì)于分布式數(shù)據(jù)庫來說，表現(xiàn)尤甚。各廠商產(chǎn)品實(shí)現(xiàn)差異很大，沒有通用的使用標(biāo)準(zhǔn)。如何規(guī)避這一風(fēng)險(xiǎn)，帶來最大的自由度選擇？后文會(huì)展開說明。3.數(shù)據(jù)庫選型策略推薦針對(duì)上述諸多難點(diǎn)、痛點(diǎn)，作為金融行業(yè)如何選擇分布式數(shù)據(jù)庫呢？這談幾點(diǎn)個(gè)人的見解。尊重路線之爭(zhēng)，無關(guān)技術(shù)領(lǐng)先如前面所述，分布式數(shù)據(jù)庫的發(fā)展有著不同的技術(shù)路線。曾有種觀點(diǎn)認(rèn)為，“分布式數(shù)據(jù)庫的發(fā)展方向代表著未來，分布式中間件方向沒有前途”。針對(duì)這一問題，我的觀點(diǎn)是采用不同技術(shù)路線的產(chǎn)品有自己的適用場(chǎng)景，與技術(shù)領(lǐng)先性無關(guān)。某種技術(shù)通過提出理論、工程化實(shí)現(xiàn)、產(chǎn)品能力輸出，可解決某方面需求、甚至帶來巨大產(chǎn)品能力的提升；但希望以此通過大一統(tǒng)的產(chǎn)品解決所有問題是不現(xiàn)實(shí)的，未來仍然是多種技術(shù)路線并存的情況。成熟度有待完善，但時(shí)不我待提前規(guī)劃分布式數(shù)據(jù)庫作為一種新興技術(shù)產(chǎn)品，其成熟度尚需錘煉，但不能基于此就選擇觀望態(tài)度。產(chǎn)品成熟的提高，一方面來自廠商對(duì)產(chǎn)品的不斷迭代優(yōu)化；另一方面也來自使用者的不斷打磨。企業(yè)內(nèi)對(duì)數(shù)據(jù)庫的落地使用，也需要較為長期的過程。此外，外部驅(qū)動(dòng)也對(duì)這一選擇起到加速推動(dòng)作用。作為企業(yè)來講，根據(jù)自身情況可以選擇不同策略（引領(lǐng)、跟隨）；但無論那種都需要提前規(guī)劃，有明確方向和實(shí)施路徑。國產(chǎn)數(shù)據(jù)庫百花齊放，機(jī)會(huì)無限近些年來，國產(chǎn)數(shù)據(jù)庫發(fā)展迅猛，呈現(xiàn)百花齊放態(tài)勢(shì)。針對(duì)這一現(xiàn)狀，一方面要持續(xù)關(guān)注這些產(chǎn)品，給予這些產(chǎn)品充分施展機(jī)會(huì)；另一方面制定準(zhǔn)入標(biāo)準(zhǔn)嚴(yán)格把關(guān)，讓真正有實(shí)力的廠商能夠進(jìn)入，得到充分鍛煉、打磨的機(jī)會(huì)。慎重技術(shù)選型，不迷信宣傳技術(shù)選型是個(gè)很嚴(yán)謹(jǐn)?shù)倪^程，需要慎重對(duì)待。有很多第三方的評(píng)測(cè)和廠商宣傳結(jié)論，但這些只能做參考，決策層面的依據(jù)還是需依靠自己。一方面宣傳內(nèi)容一般都會(huì)所選擇有利于自己，這會(huì)帶來一定誤導(dǎo)性；另一方面對(duì)同一概念的理解是有偏差的，很難僅僅通過一段文字描述就能完全說清楚（例如，數(shù)據(jù)一致性，背后的解讀就有很多）。這些問題只有在真實(shí)環(huán)境，疊加上自身需求，測(cè)試出的結(jié)果才具說服力。結(jié)合場(chǎng)景需求，沒有最好只有最適合業(yè)務(wù)場(chǎng)景千差萬別，其對(duì)數(shù)據(jù)庫能力要求和側(cè)重點(diǎn)也有所不同。很難選擇一款通用型產(chǎn)品滿足全場(chǎng)景，那就需要根據(jù)實(shí)際情況做有針對(duì)性的選擇。此外，不同產(chǎn)品各有強(qiáng)點(diǎn)和局限之處，選擇最適合你的產(chǎn)品就好。例如上文談到的分布式中間件產(chǎn)品，在超大規(guī)模、自定義分片、超高性能、業(yè)務(wù)控制等方面往往更有優(yōu)勢(shì)；而分布式數(shù)據(jù)庫產(chǎn)品，則在分布式事務(wù)、數(shù)據(jù)強(qiáng)一致、混合負(fù)載等方面有所擅長。不選產(chǎn)品選兼容性，保持最大自由度當(dāng)前分布式數(shù)據(jù)庫，仍然處于快速發(fā)展期，很難確定未來的主流選擇。為了規(guī)避路線選擇、廠商綁定的風(fēng)險(xiǎn)，比較現(xiàn)實(shí)的方法是選擇一款兼容通用性協(xié)議的產(chǎn)品，并且在使用中僅使用標(biāo)準(zhǔn)數(shù)據(jù)庫的用法。舉個(gè)例子，選擇一款兼容MySQL的產(chǎn)品并且安裝標(biāo)準(zhǔn)MySQL的用法使用；當(dāng)出現(xiàn)風(fēng)險(xiǎn)時(shí)完全可選擇另外一款同樣兼容MySQL的產(chǎn)品來替代。目前MySQL生態(tài)在國內(nèi)最為成熟，很多廠商產(chǎn)品也選擇了兼容它，因此選擇兼容性產(chǎn)品在未來的自由度最大。保持技術(shù)敏感度，緊跟時(shí)代發(fā)展步伐面對(duì)技術(shù)發(fā)展多變、應(yīng)用特點(diǎn)多變、外部需求緊迫的現(xiàn)狀，時(shí)刻關(guān)注分布式數(shù)據(jù)庫發(fā)展，保持足夠的技術(shù)敏感度，緊跟技術(shù)發(fā)展趨勢(shì)。采取架構(gòu)前置、謹(jǐn)慎選型、局部試點(diǎn)、多線布局、掌握主動(dòng)、自建增強(qiáng)等策略，保持主動(dòng)。-全文完-單機(jī)型數(shù)據(jù)庫，最早源自上世紀(jì)70年代，從IBM著名的論文開始，后面誕生了Oracle,DB2為代表的優(yōu)秀商業(yè)產(chǎn)品以及PostgreSQL、MySQL為代表的開源產(chǎn)品。這些產(chǎn)品很好的滿足了對(duì)數(shù)據(jù)存儲(chǔ)和計(jì)算的需求。隨著21世紀(jì)初期，互聯(lián)網(wǎng)浪潮的來臨，數(shù)據(jù)規(guī)模呈爆炸式增長，單機(jī)數(shù)據(jù)庫越來越難以滿足用戶需求。這也催生了分布式數(shù)據(jù)庫的到來。到了2006年之后，出現(xiàn)以HBase/Cassadra/MongoDB為代表的NoSQL類產(chǎn)品。這些產(chǎn)品實(shí)現(xiàn)了分布式架構(gòu)，可以實(shí)現(xiàn)容量的水平擴(kuò)展，但也犧牲了諸如事務(wù)、SQL訪問接口等能力。存儲(chǔ)模型的簡(jiǎn)化為存儲(chǔ)系統(tǒng)的開發(fā)帶來了便利，但是降低了對(duì)業(yè)務(wù)的支撐。在這一階段，很多企業(yè)為了解決大規(guī)模數(shù)據(jù)存儲(chǔ)與訪問的問題，也研發(fā)了很多中間件產(chǎn)品。其原理是通過將數(shù)據(jù)分片存儲(chǔ)到單機(jī)庫，上層對(duì)SQL解析實(shí)現(xiàn)對(duì)語句的路由。這種方式有一定的難點(diǎn)，例如對(duì)分布式事務(wù)的處理及規(guī)模擴(kuò)大下的管理問題。到了2012年，Google的論文為關(guān)系模型的分布式架構(gòu)，提供了新型分布式數(shù)據(jù)庫理論基礎(chǔ)。在此之后，誕生了一系列新型分布式數(shù)據(jù)庫產(chǎn)品。其原理是通過分布式一致性算法協(xié)議完成底層數(shù)據(jù)多副本存儲(chǔ)，上層則實(shí)現(xiàn)了標(biāo)準(zhǔn)SQL支持能力。分布式數(shù)據(jù)庫之辯從上文可看到分布式數(shù)據(jù)庫的發(fā)展非常之快，目前仍處于高速發(fā)展期；而且并不是單一發(fā)展路徑，有很多技術(shù)路線同步發(fā)展。因而，大家口中的“分布式數(shù)據(jù)庫”可能代表的技術(shù)棧完全不同。下圖嘗試對(duì)常見的“分布式數(shù)據(jù)庫”產(chǎn)品按技術(shù)實(shí)現(xiàn)差異做個(gè)簡(jiǎn)單分類。下述分類僅代表個(gè)人觀點(diǎn)，部分產(chǎn)品因技術(shù)快速演進(jìn)可能有所變化。除了傳統(tǒng)數(shù)據(jù)庫外，這里將分布式數(shù)據(jù)庫分為三種情況：-分布式中間件這種架構(gòu)是從之前談到的中間件路線演進(jìn)而來。其采用存儲(chǔ)與計(jì)算分離架構(gòu)，底層采用標(biāo)準(zhǔn)單機(jī)數(shù)據(jù)庫，副本間基于數(shù)據(jù)庫主從復(fù)制機(jī)制。上層承擔(dān)計(jì)算，并可將部分計(jì)算下推到存儲(chǔ)節(jié)點(diǎn)執(zhí)行。這種架構(gòu)在分布式事務(wù)、全局MVCC等方面，往往存在一定難點(diǎn)，各廠商也有各自解決之道。一分布式事務(wù)這種架構(gòu)正是受到Google論文影響演進(jìn)而來。其采用存儲(chǔ)與計(jì)算分離架構(gòu)，底層采用單機(jī)庫（不一定是關(guān)系型），副本間采用分布式一致性協(xié)議完成復(fù)制，支持多數(shù)派提交。上層承擔(dān)計(jì)算，并可將部分計(jì)算下推到存儲(chǔ)節(jié)點(diǎn)執(zhí)行。-分布式存儲(chǔ)這種架構(gòu)另辟蹊徑，其上層是采用本地計(jì)算方式，下層采用分布式存儲(chǔ)，節(jié)點(diǎn)間共享數(shù)據(jù)。這種架構(gòu)需要嚴(yán)格依賴于底層存儲(chǔ)系統(tǒng)。-典型產(chǎn)品示例（分布式中間件）上圖一摘自GoldenDB數(shù)據(jù)庫，上圖二摘自TDSQL數(shù)據(jù)庫。從上面兩圖可見，此類數(shù)據(jù)庫架構(gòu)大致都分為幾個(gè)組件：O計(jì)算節(jié)點(diǎn)（或稱Proxy）集群，由一組無狀態(tài)節(jié)點(diǎn)組成，響應(yīng)用戶請(qǐng)求、解析SQL、完成邏輯優(yōu)化、物理優(yōu)化，生成分布式執(zhí)行計(jì)劃，下發(fā)到數(shù)據(jù)節(jié)點(diǎn)，完成用戶操作請(qǐng)求。o數(shù)據(jù)節(jié)點(diǎn)集群，真正完成數(shù)據(jù)存儲(chǔ)功能。集群由若干單元組成，數(shù)據(jù)按分片策略存儲(chǔ)在單元中。每個(gè)單元內(nèi)由一組獨(dú)立數(shù)據(jù)庫主從集群構(gòu)成，實(shí)現(xiàn)對(duì)數(shù)據(jù)的高可用保證。o管理節(jié)點(diǎn)（含配置中心），負(fù)責(zé)集群組件管理、元信息存儲(chǔ)等，不涉及業(yè)務(wù)訪問流程。O事務(wù)管理器（（G）TM）,負(fù)責(zé)事務(wù)管理，有中心化或非中心化不同實(shí)現(xiàn)策略。o管理控制臺(tái)，負(fù)責(zé)集群管理、維護(hù)職能。-典型產(chǎn)品示例（分布式事務(wù)）上圖一摘自PingCAP-TiDB數(shù)據(jù)庫，上圖二摘自O(shè)ceanbase數(shù)據(jù)庫。此類分布式數(shù)據(jù)庫的實(shí)現(xiàn)差異是較大的，不同廠商有各自的實(shí)現(xiàn)策略。前者傾向于中心化實(shí)現(xiàn)，后者傾向去中心化。但總體上，還是包含兩類組件，一是計(jì)算節(jié)點(diǎn)、二是存儲(chǔ)節(jié)點(diǎn)。前者實(shí)現(xiàn)了用戶訪問接入，后者通過分布式一致性算法，實(shí)現(xiàn)數(shù)據(jù)的多副本存儲(chǔ)。2.數(shù)據(jù)庫選型的痛點(diǎn)與難點(diǎn)如之前所說，金融行業(yè)正面對(duì)底層基礎(chǔ)設(shè)施的轉(zhuǎn)型問題，數(shù)據(jù)庫作為重要的底層技術(shù)棧同樣面臨一個(gè)選擇的問題。但在這一選擇過程中，往往存在較多的痛點(diǎn)和難點(diǎn)。這主要是因?yàn)榻鹑谛袠I(yè)的特殊性所造成的。"【痛點(diǎn)】基礎(chǔ)功能待完善對(duì)標(biāo)傳統(tǒng)集中式數(shù)據(jù)庫，現(xiàn)有的分布式數(shù)據(jù)庫在功能上仍然有待完善。這一方面是因?yàn)榉植际郊軜?gòu)所造成的功能tradeoff,另一方面是在產(chǎn)品化能力完整性上的欠缺。前者是我們?cè)谑褂梅植际綌?shù)據(jù)庫產(chǎn)品時(shí)，需要在架構(gòu)、設(shè)計(jì)層面需要在關(guān)注的，在項(xiàng)目初期都需要解決掉的。而后者廠商產(chǎn)品經(jīng)過多年發(fā)展在內(nèi)核能力上已趨于完善，但在周邊配套的管理、設(shè)計(jì)、優(yōu)化工具上，仍需進(jìn)一步完善。畢竟最終為用戶呈現(xiàn)的，是一套完整的數(shù)據(jù)庫解決方案。-【痛點(diǎn)】運(yùn)行穩(wěn)定待驗(yàn)證對(duì)于金融行業(yè)而言，穩(wěn)定性是第一位的。雖然分布式數(shù)據(jù)庫在設(shè)計(jì)之處，就將穩(wěn)定性設(shè)計(jì)放在優(yōu)先位置，其天然的分布式架構(gòu)也有利于提供更高的可用性保證。但一方面分布式架構(gòu)天然由多組件組成，其復(fù)雜程度較集中式更高；另一方面其對(duì)底層基礎(chǔ)環(huán)境的要求也更高。此外，產(chǎn)品的穩(wěn)定性是要在長期實(shí)踐中不斷打磨、持續(xù)改進(jìn)的。分布式數(shù)據(jù)庫作為后來者，也需要經(jīng)歷這一過程。【痛點(diǎn)】遷移改造任務(wù)重選擇使用分布式數(shù)據(jù)庫產(chǎn)品，對(duì)應(yīng)用側(cè)來說，需要有大量的應(yīng)用遷移工作。一方面是由于分布式數(shù)據(jù)庫較集中式數(shù)據(jù)庫功能上有所削弱，另一方面更換數(shù)據(jù)庫天然所需要的移植工作。雖然目前各分布式數(shù)據(jù)庫也推出XX兼容能力，但從實(shí)際效果來看僅能減少部分移植工作，整體遷移任務(wù)量仍然很高。且遷移采用所謂的兼容模式，也不利于后期平滑更換，這點(diǎn)后面會(huì)講到。"【痛點(diǎn)】風(fēng)險(xiǎn)巨大需并行對(duì)底層數(shù)據(jù)庫的更換，是存在較大技術(shù)風(fēng)險(xiǎn)的。一是由于新產(chǎn)品、新架構(gòu)所帶來的風(fēng)險(xiǎn)；二是應(yīng)用遷移改造帶來的不確定性；三是產(chǎn)品本身的穩(wěn)定性的潛在風(fēng)險(xiǎn)。為應(yīng)對(duì)這種情況，最為穩(wěn)妥的方式是采取應(yīng)用雙發(fā)并行的方式解決。這種方式可在最大程度上減少可能初期的風(fēng)險(xiǎn)，可做到數(shù)據(jù)冗余、無縫切換、靈活可控等，但其花費(fèi)的代價(jià)也是非常高的。需要從應(yīng)用端做大量雙發(fā)改造，如果更換系統(tǒng)很多，這方面代價(jià)是比較大的。■【難點(diǎn)】生杰環(huán)境需培育雖然發(fā)展多年，但國產(chǎn)分布式數(shù)據(jù)庫在整體市場(chǎng)上仍然屬于小眾選擇。之前國外廠商產(chǎn)品占據(jù)市場(chǎng)領(lǐng)導(dǎo)地位，經(jīng)過多年發(fā)展已形成了較為完善的生態(tài)。隨著近些年來，MySQL>PG開源數(shù)據(jù)庫在互聯(lián)網(wǎng)行業(yè)得到大量應(yīng)用，積累大量用戶，建立其不錯(cuò)的生態(tài)。很多國產(chǎn)分布式數(shù)據(jù)庫采用迂回策略，通過兼容上述數(shù)據(jù)庫標(biāo)準(zhǔn)，來享受開源生態(tài)紅利。此外，近期國產(chǎn)數(shù)據(jù)庫如TiDB、OB、PorlaDB>openGuass等，也紛紛開源建設(shè)自有生態(tài)?！倦y點(diǎn)】信創(chuàng)要求時(shí)間緊作為國家安全的重要舉措之一，安全可控成為基礎(chǔ)要求，信創(chuàng)因而誕生。為保證上述政策執(zhí)行到位，國家也設(shè)定實(shí)施計(jì)