四種分佈式數據庫場景選型、優缺點對比分析和將來展望 | 趨勢解讀

【摘要】隨着互聯網金融場景的不斷拓展，海量的數據訪問和處理形成傳統的集中式數據庫開始表現出性能瓶頸，分佈式數據庫的研究和場景使用應運而生，而數據的安全和合規也隨着企業對數據使用的要求愈來愈高更加劇視。所以在這種場景下，分佈式數據庫應具有高性能、可擴展、高可用和高容錯等特性，而傳統的集中式數據庫難以同時知足，本文重點介紹分佈式數據的特性及種類，根據相應的業務場景對分佈式數據庫選型進行分析，並對分佈式數據庫的細分領域的發展進行探討。
【做者】顧黃亮，十年技術老兵，歷經研發和運維，瞭解基礎架構、安全、中間件、數據庫，專一於智慧運維體系的打造。曾供職於航天晨光、上汽集團雲計算中心，現任蘇寧消費金融安全運維部總監。

1 引言

近年來，隨着國際信息安全形式的日益嚴峻，國家信息安全策略逐步深刻。所以，一行兩會連續針對金融業數據庫技術受制於人的嚴峻形勢出臺了相關政策，以知足構建安全可靠可控的信息技術體系的要求。

縱觀近年來普惠金融的發展，多用戶、低額的客單價帶來的主要挑戰是數據量、交易額的大幅提升，並伴隨着數十倍的交易高峯壓力以及交易複雜度的增長。而傳統數據庫在處理此類應用場景的時，在擴展性、性能、吞吐量和可靠性等方面遇到了明顯的瓶頸，只能經過業務拆分、升級硬件的方式來提高性能，形成設備投入和人員成本的不斷攀升。面對着互聯網金融業態不斷的發展，數據的交互和存儲也呈現指數級增加，這樣的方式也沒法保證業務連續性。在此形式下，在分佈式數據庫的選型上，根據不一樣的業務場景和關鍵系統中選擇不一樣的開源產品，經過對開源數據庫的深刻研究和應用，知足了互聯網金融業務場景的事務處理和數據處理的要求。

2 傳統數據庫的那些事

我的認爲，分佈式數據庫是起源於傳統的關係型數據庫，二者的設計場景不一樣，前者面對企業級應用，運行在獨立的服務器上，然後者的應用更多的是面對互聯網用戶。隨着用戶相應的數據量極具增長，傳統的關係型數據庫在可擴展性的弊端日益顯現，通常有下面幾個方面：

（1）單點處理的性能瓶頸，即單點的數據庫系統沒法處理大規模的併發請求和計算；

（2）單點運行風險高，容災容錯能力差；

（3）單點存儲能力有限，只能縱向擴展，不能橫向擴展；

（4）應用擴容升級難度大，設備投入高。

對於數據庫自己來講，傳統的分佈式數據庫都有各自的集羣解決方案，不過這不是真正意義上的分佈式，僅僅是爲了解決高可用場景下數據庫的負載均衡問題。這種特性是每一個數據庫都是冗餘的，所謂冗餘，那就是每一個數據庫的數據都是徹底同樣的，因此數據量上升到必定的程度，對集羣中的每一個數據庫都會形成很大的壓力。

然而，雲計算的出現引爆了這一切。當資源再也不是瓶頸的時候，分佈式數據庫的春天來了。

3 說說分佈式數據庫

分佈式數據庫的概念再也不闡述，大致描述就是數據庫技術和網絡技術的親生孩子。在此，咱們爲何選擇分佈式數據庫，理由有以下：

（1）具備靈活的體系結構；

（2）適應分佈式的管理和控制機構；

（3）經濟性能優越；

（4）系統的可靠性高、可用性好；

（5）局部的應用響應快；

（6）優越的可擴展性，易於集成現有的系統。

那分佈式數據庫應該怎麼用？基於分佈式數據庫的選型該怎麼作？

首先，基於特性，分佈式數據庫大體能夠分爲三類：

（1）支持持久化存儲的分佈式存儲系統，如MySQL，OceanBase；

（2）偏向於計算的分佈式計算框架，如Hadoop HDFS，Ceph，Swift，Blob，Cinder，Lustre；

（3）分佈式消息隊列，如Redis，RMQ，CMQ，Kafka。

其次，基於不一樣的應用場景，根據特性繼續細化，又能夠分爲如下：

（1）分佈式協同數據庫系統；

（2）分佈式任務；

（3）流式計算；

（4）分佈式文件系統；

（5）分佈式nosql存儲；

（6）分佈式關係數據庫；

（7）分佈式消息隊列。

回到最核心的問題，如何進行分佈式數據庫技術路線的選擇？

分佈式通常分爲三條技術路線：分佈式訪問客戶端、分佈式中間件模式、分佈式數據庫模式。其中分佈式訪問客戶端對應用侵入性大，改造難度很高；分佈式中間件則相似MyCAT等產品，在數據庫和應用間架一層Proxy，這種方案沒法支持分佈式事務、也沒法支持跨庫關聯，分佈式數據庫方案則將分庫分表等中間件實現的功能下推到數據庫層面來作，對應用透明，應用就像使用單機數據庫來使用分佈式數據庫，同時自然地支持分佈式事務。

4 經常使用的分佈式數據庫和場景選型

針對以上概述，列舉ElasticSearch、Redis、MySQL分佈式集羣、MongoDB四個分佈式數據庫進行舉例，分別從簡介、應用場景、優勢、缺點、備份/持久化進行對比和分析。其中MySQL分佈式集羣包括如下幾種集羣方式：Proxy，Cluster，Mha，Mgr，基於MySQL協議的NewSQL，如MyCAT，OceanBase不在此範圍以內。

（1）簡介

（2）應用場景

（3）優勢

（4）缺點

（5）備份/持久化方案

5 項目中的一些問題

在項目中，針對分佈式數據庫的設計，通常有幾個難點。

（1）分佈式事務的問題，在分佈式數據庫中，分佈式事務的實時一致性是很難保證的，而容錯性的設計必定要考慮全面，經過犧牲相應的可用性來保證一致性。

（2）性能方面，爲了保證事務的全局一致性，分佈式數據庫須要一個全局的事務管理器，用於分配全局事務的工做，不一樣的分佈式數據庫或許有不同的功能，若是數據量和請求達到一個量級的時候，事務管理器或許就成爲一個新的瓶頸。

（3）高可用的問題，當分佈式數據庫集羣中有節點宕機的時候，宕機數量和選舉工做會影響整個集羣提供服務的質量，這一點跟業務的容忍性密切相關。

在運維階段，針對分佈式數據庫是從認識、熟悉到通過的過程，一個新的產品或者功能的運維是離不開不少準備工做。所以，進入運維階段，通常要考慮下面幾步。

（1）準備好經常使用的運維腳本、應急手冊、運維手冊；

（2）作好分佈式數據庫的監控，尤爲是關鍵指標的監控；

（3）技術手冊的培訓，准入條件的限制；

（4）按期作好演練工做，及時發現問題。

6 分佈式數據庫發展的一些思考

在企業中，對於新技術新產品的選型不只僅爲了知足當前業務場景的需求，還要考慮到這個產品將來三到五年的發展道路和方向，以及是否可以不斷迭代以知足將來的需求。所以，用戶僅瞭解每一種技術的現狀是遠遠不夠的，只有當認識到一種技術的發展策略以及其架構的侷限性後，纔可以預見和洞察將來。架構侷限性並不等於功能的缺失。不少新型技術 在開始時都沒法提供像Oracle同樣完備的企業級功 能，但並不意味着用戶必需要等到所有功能完備後才 開始考慮學習和使用。用戶在評估一種新產品和技術時，產品的功能點須要知足幾個必備的基礎功能，而一些高級功能則不須要馬上具有。

對於分佈式數據庫來講，隨着業務場景和數據的使用處理方面的需求趨於成熟和明朗，分佈式數據庫的以場景和功能的區分更爲細化，主要發展發現基本能夠分爲分佈式聯機數據庫和分佈式計算數據庫兩種，而針對非結構化小文件需求也在考驗分佈式數據庫是否在這個領域可以打出一片天地，能夠展望，小型的分佈式的針對非結構化的文件存儲數據庫也可能後期的戰場之一。

---

原做者：顧黃亮
原文連接： 分佈式數據庫的場景選型及趨勢分析解讀 - 顧黃亮 - twt企業IT交流平臺
原出處：twt企業IT交流平臺