標籤：

什麼情況下，需要使用分散式資料庫？

01-03

目前，伺服器的磁碟和內存，cpu都相對較好，一台資料庫伺服器可以存儲好幾億條的數據，在一個什麼樣的情況下，應該考慮分散式資料庫的，百億？千億？

如果單機資料庫，直接通過分散式資料庫來訪問，分散式資料庫是否能夠提高資料庫的效率呢？

資料庫分庫後，一些複雜的sql場景，會比較難處理，而且分庫之後，sql除了查詢分庫的數據外，還要進行數據合併操作，那是否是說不分庫，比分庫更好一些呢？

分別回答下，題主的三個問題：


1. 目前，伺服器的磁碟和內存，cpu都相對較好，一台資料庫伺服器可以存儲好幾億條的數據，在一個什麼樣的情況下，應該考慮分散式資料庫的，百億？千億？

考慮用分散式資料庫，肯定是容量或者性能方面，現有的單機資料庫滿足不了業務的需求。當然，遇到了容量或者性能的問題，也不一定要用分散式資料庫，可以通過scale-up的方式，即升級資料庫伺服器的CPU、內存、磁碟，將SATA/SAS盤換SSD盤等方式解決。不過相對scale-up來說， 分散式資料庫這種scale-out的方式，擴展性會更強一些，一般來說也更具性價比。


普通的X86伺服器，一台資料庫伺服器存好幾億條數據，問題不大，但前提是需要分庫或分表，單表幾億條數據，普通伺服器基本支撐不了的，畢竟數據量一大，表對應的B樹層次就高，寫入時B樹節點的分裂和調整，開銷也大。同時，上億規模下，單台資料庫伺服器的恐怕不能支持密集的讀請求，性能可能會有問題。


2. 「如果單機資料庫，直接通過分散式資料庫來訪問，分散式資料庫是否能夠提高資料庫的效率呢？」

題主這裡所說的分散式資料庫， 應該是指資料庫中間件這樣的軟體吧。目前比較流行的一種做法，是DBA利用開源中間件，結合自己項目的mysql或pg資料庫，來搭建出一套分散式資料庫的解決方案。主要的方法有兩種：

一種是水平拆分。當數據量大到單機資料庫已存儲不下時， 可以對數據進行拆分，化整為零，將數據均勻分布到多個資料庫節點中。由於對數據進行了拆分，每個資料庫節點上的數據量小了，自然讀寫性能就提高了。

另一種是讀寫分離。這種方法，主要用在數據量並不大，單機資料庫能夠hold得住，但讀請求很高的情況下。此時，可以配置多個只讀資料庫節點，來分擔主節點的讀請求。通過數據複製機制，在主節點和只讀節點之間進行數據的實時同步，保證主從節點的數據一致性。


兩種方法很好地解決了資料庫的容量和性能問題。當然，使用了中間件，相當於在sql的執行路徑上，多了一個處理環節，因此單條sql的延時，相對於直連資料庫節點，在非滿負載的情況下，肯定是要高的。但在實際的業務訪問中，sql的性能瓶頸，一般都出在資料庫節點上，中間件只是做單純的sql解析和路由，性能開銷不會很大。因此，通過增加資料庫節點，提升sql處理的短板，是能夠提高系統效率的。


3.「資料庫分庫後，一些複雜的sql場景，會比較難處理，而且分庫之後，sql除了查詢分庫的數據外，還要進行數據合併操作，那是否是說不分庫，比分庫更好一些呢？」


基於中間件來進行分庫， 確實對 SQL 有閹割的情況，並不是所有sql都能夠支持。主要原因是數據被拆分了。而數據一旦被拆分到多個節點，則：

1.複雜的join查詢

2. 同時更新多個資料庫節點的sql語句

這兩類SQL的支持難度，就比較高。這也是目前市面上所有中間件都無法滿足的兩點。複雜的join查詢之所以難以支持，是因為要跨節點join；同時更新多個節點的sql難以支持，是因為很難解決多個節點的並發一致性問題。但是除了這兩點之外，其他的sql類型，一款中間件是能夠努力做到的。


從中間件實現的角度，我們來對sql做一個分析，以說明這一點。


1. 按操作範圍的維度，可以把所有的SQL，分為3類：

1.1 kv類的sql： 這種sql操作很簡單，就是簡單的set/put某個表的一條記錄，大部分insert/delete/update語句，和指定primary key/key的select，都屬於這種類型。

1.2 範圍更新/查詢：這種sql不局限於操作一條記錄，但還是作用於一張表。比如update多行記錄，或者select某個時間範圍的記錄等。

1.3 多表join查詢：又包括兩種：

1.3.1 分庫分表鍵都是同一個的多表join：由於採用同一個劃分鍵，因此join操作其實是發生在單節點

1.3.2 分庫分表鍵不是同一個的多表join： 此時涉及到跨節點的join，實現複雜


2.按是否要在關係運算之後，還要對結果進行聚合，把select sql分為兩類：

2.1 不需要進行結果聚合，即select sql中沒有集函數、group by、order by、limit等需要在關係運算之後，再對結果進行處理和聚合；

2.2 包括上述結果聚合語法的select sql


3.從是否對分散式事務有要求的角度，可以把SQL分為兩類：

3.1 只讀寫一個節點的sql，無分散式事務要求

3.2 跨多個節點讀寫的sql，有分散式事務要求


根據之前所述， 目前的業內的中間件，都不能支持1.3.2 和3.2（mycat對分散式事務的支持，只支持最終一致性，還是一個偽支持；阿里DRDS號稱內測版本支持分散式事務，但一直未見公測），而除去這兩點，對於類型(1.1, 1.2, 1.3.1) × (2.1,2.2)得到的6種sql類型，理論上講，中間件都是可以做到支持的。

對於OLTP應用來講，這6種類型能夠覆蓋絕大部分的業務場景，這也是中間件技術這幾年這麼流行的原因。遺憾的是，目前業內的各大中間件， 對這6種類型的sql，支持程度往往都有一定的折扣。比如對於這樣一條操作單表的sql：


select distinct id, avg(price) from t1 where id&>=1 group by concat(id,name) order by avg(price) limit 10;

目前主流的幾款中間件，似乎就不能支持。

目前，UCloud 的 UDB 團隊，也在打造一款基於中間件和 UDB 的，分散式資料庫產品 UDDB，協議和SQL語法，全面兼容MYSQL。我們從零開始，但目標遠大。正如 UCloud 一直強調的，用戶的需求是我們下一款產品。我們的第一個目標，是做一款業內最好用的分散式資料庫，解決用戶在使用mysql中間件構建分散式解決方案時的痛點：學習成本高，配置複雜，運維麻煩，擴容不方便。

在系統管理上，UDDB將做到一步創建，開箱即用，無需額外的管理和配置操作，並提供全自動化，無需停服的水平擴展/縮容操作；SQL支持上，我們將對類型(1.1, 1.2, 1.3.1) × (2.1,2.2)這6種sql，進行全面的支持，讓用戶在遇到帶avg集函數、group by，order dy的select sql時， 無需擔憂系統是否支持，即可放心使用。

預計在今年9月底，UDDB將開放內測，敬請大家關注。

長期來看，打造這樣一款分散式資料庫服務，是我們和客戶交流，探索未來的一種方式。誠然，相對於 Google F1，Oceanbase 等全新設計的分散式資料庫產品， 基於中間件的分散式資料庫，在技術上並非最前沿，但是我們相信，這是廣大客戶目前正需要的。我們相信只有先服務好用戶，深入到用戶的需求當中，根據用戶需求不斷迭代，同時團隊自身不斷成長，才能真正理解公有雲環境下，用戶對分散式資料庫的需求，才能做出接地氣和廣受歡迎的產品。

可以試試我們的drds。

凡事都是能簡則簡，雖然分散式資料庫是資料庫發展的方向，但並不是說一定要用分散式。例如，很多NoSQL都是分散式的，但是很多中小型系統的都沒用用到分散式的特性。

但對於大型應用來說分散式資料庫就非常有優勢。現在比較流行的說法「金融級」的資料庫產品面向銀行等大型企業的大量高頻的數據處理，則都需要分散式資料庫，幾十個節點到1-2百的節點也非常多。

規模、性能、高並發、數據拆分、降低索引層次高度等都需要綜合考慮來決定是否使用分散式資料庫。分散式架構不是一個新鮮事務，因為現在網路帶寬（萬兆以上帶寬）、存儲、x86的低成本才給了分散式資料庫大力發展的條件。

技術產品採用主要是性價比，在海量數據處理情況下，分散式資料庫的性價比特別明顯：

  1. 性能：能輕鬆面對海量數據和高並發的請求處理，好的分散式資料庫能做到90%以上的線性增長能力；
  2. 靈活性、彈性：現代的系統的業務和使用場景變化很快，用戶的增長也有很多不確定因素。彈性擴容就非常重要。分散式資料庫本身有Cloud-Ready的特性，能很容以通過添加設備擴容滿足需求，而不需要影響開發；
  3. 多中心、多活：這點在大型應用中很常見，分散式資料庫就更容易實現這個功能，當然這裡涉及到分散式資料庫的同步和一致性的能力，這也是判斷分散式資料庫好壞的一個重要指標。
  4. 讀寫分離：主從節點都能發揮作用；例如巨杉SequoiaDB資料庫，能在一組三副本的複製組上實現OLTP，NoSQL應用，OLAP多種應用場景同時使用。
  5. 低成本：x86伺服器，SATA存儲（部分可以用SSD），加上較好的網路帶寬就可以了。

更多的特性也不再一一描述了。分散式資料庫核心之一就是對數據的精細顆粒度管理，數據拆分後，命令下壓能否在精準定位到相應的數據節點來做計算。

數據拆分有三大類：

  1. 水平分區：基本對1個或多個鍵的水平哈希，增強數據的並行處理能力來提高性能；
  2. 垂直分區：和過去的Partition很像，對數據進行有含義的拆分；
  3. 混合分區：水平分區和垂直分區共同使用。

所以分散式資料庫非常需要架構師和工程師對業務理解能力和數據規劃能力。

和選擇產品有關的另一點就是產品化和成熟度，如果您是企業採購資料庫，這點就尤為重要。資料庫是否有「原廠」的技術服務能力也是大型企業選擇資料庫重點。

推薦看一下這個視頻：

【阿里雲大學課程】MySQL大牛丁奇：分散式資料庫技術與實現 - 知乎專欄

1. 什麼情況下使用分散式資料庫

這個取決於你的業務，如果單機資料庫已經能滿足你當前的業務需求並且也能滿足可預期的未來一段時間的業務需求，那就沒必要用分散式資料庫。具體的業務需求可以考慮容量、性能、一致性要求、可靠性和容災等。

2. 分散式資料庫是否能夠提高資料庫的效率

分散式資料庫不一定能提高效率，假設你的數據量不大，或者是每次查詢只涉及很少一塊數據，並且索引建的比較好，單機資料庫的速度有明顯的優勢。

3. 複雜的 SQL

如果用一些中間件方案，對跨庫事務、join等操作很難處理好。但是分散式資料庫!=中間件方案，中間件方案只是其中的一種。我們正在做的 TiDB，採用的和 Google F1/Spanner 相同的思路，不需要進行分庫分表，對複雜的 SQL 會採用分散式計算，提高性能。歡迎試用。

幾億條記錄只是存儲問題，對大部分需要分布的資料庫來說，首要解決的問題一般都不是存儲，而是請求數。

讀寫多的情況…也可能因為讀寫分離，用分散式資料庫…

數據量巨大的情況，你說了

分散式是為了解決單一存儲結構的一些寬表熱數據之類的問題，比如db鏈接資源這種，所以和存儲量沒多少關係。

簡單點說: 分散式資料庫首先提供多副本高可用，然後就是當單機處理數據的時間大於rpc時候，分散式資料庫多個數據分片並行算就會好點。

DATAHEKR 資料庫中間件，支持讀寫分離，性能優於MAXSCALE。

近期我們將發布自定義PLUGIN功能，可以定製你的專屬資料庫中間件。

各種資料庫都有集群方案，一做集群其實就是變成分散式了，市面上資料庫多種多樣，根據需求來選用吧，都是可以做成分散式的

推薦閱讀：

※產品運營，如何做出一份優秀數據報表？
※一台普通計算機能承擔伺服器嗎？
※如何評判基於中間件的分散式mysql與 雲資料庫？
※誰能用最簡單的語言或者例子說下 Mysql、SQLite、Mongo的區別呢？
※資料庫學習書籍推薦？

TAG:資料庫 | 分散式 |