即便是 MariaDB，也有一個想要處理大數(shù)據(jù)的心。雖然可能跟其它的例如 HBase、Hive 之類的比有些差異和不足，但并不影響壯志。

簡單列舉兩個要處理大量數(shù)據(jù)的例子：

• 1、IoT Sensor Networks
  • 存取特性: 很少大量寫入，但多大量讀取
  • 事務(wù)需求: 少
  • 資料量: 累積數(shù)量龐大
• 2、AI Machine Learning 領(lǐng)域
  • 搜集大量數(shù)據(jù)進行分析

使用 MariaDB 處理大量數(shù)據(jù)，先來了解一下這兩點。

DATA Sharding (數(shù)據(jù)分片)和 Data Partition(數(shù)據(jù)分區(qū))

數(shù)據(jù)分片簡述

• 單一數(shù)據(jù)庫系統(tǒng)已無法處理 Big Data 服務(wù)需求
• 大部分數(shù)據(jù)庫瓶頸皆處于 I/O 效能問題
• 提供數(shù)據(jù)分片技術(shù)將數(shù)據(jù)分散儲存于多個數(shù)據(jù)庫實例中
• 提供水平式,垂直檔案分布于不同的 I/O 系統(tǒng),加速數(shù)據(jù)存取
• 可橫跨多種不同功能數(shù)據(jù)庫系統(tǒng)
• 相關(guān)技術(shù)或引擎:FEDERATEDX , CONNECT , SPIDER , MAXSCALE

關(guān)于數(shù)據(jù)分片，這里有一篇 2019 年 2 月發(fā)布的文章，到今天(2020/06/18)一年多，有 169.9k 的瀏覽量，講解說明還不錯，推薦閱讀：

Understanding Database Sharding

個人理解來說：

分片（Sharding） 是一種與水平切分（horizontal partitioning）相關(guān)的數(shù)據(jù)庫架構(gòu)模式，用于在特定的 SQL 操作中減少數(shù)據(jù)讀寫的總量以縮減響應(yīng)時間?！鐚⒁粋€表里面的行（row），分成多個不同的表的。

分區(qū)(PARTITIONing) 是分片的具體做法實現(xiàn)，例如水平分區(qū)、垂直分區(qū)。

分片（Sharding）將一個數(shù)據(jù)分成兩個或多個較小的塊，稱為邏輯分片（logical shards）。然后，邏輯分片（logical shards）分布在單獨的數(shù)據(jù)庫節(jié)點上，稱為物理分片（physical shards）。物理分片（physical shards）可以容納多個邏輯分片（logical shards）。盡管如此，所有分片中保存的數(shù)據(jù)，共同代表整個邏輯數(shù)據(jù)集。

數(shù)據(jù)庫分片（Database shards）是無共享架構(gòu)（ shared-nothing architecture）的一個例子。這意味著分片是自治的：分片間不共享任何相同的數(shù)據(jù)或服務(wù)器資源。但是在某些情況下，將某些表復制到每個分片中作為參考表是有意義的。例如，假設(shè)某個應(yīng)用程序的數(shù)據(jù)庫依賴于重量測量的固定轉(zhuǎn)換率。通過將包含必要轉(zhuǎn)換率數(shù)據(jù)的表復制到每個分片中，有助于確保查詢所需的所有數(shù)據(jù)都保存在每個分片中。

通常，分片（Sharding）在應(yīng)用程序級別進行實現(xiàn)。這意味著應(yīng)用程序包含“要向哪個分片發(fā)送讀和寫”的代碼。但是，某些數(shù)據(jù)庫管理系統(tǒng)內(nèi)置了分片功能，允許您直接在數(shù)據(jù)庫級別實現(xiàn)分片。

分片的優(yōu)點：

高可用性(High Availability)：對于分片數(shù)據(jù)庫，如果一個數(shù)據(jù)庫分片出現(xiàn)故障，則僅會使部分用戶無法使用應(yīng)用程序或網(wǎng)站的一部分，而其它分片可以繼續(xù)運行而不會出現(xiàn)任何問題。如果數(shù)據(jù)庫未分片，則中斷可能會導致整個應(yīng)用程序不可用。

更快的查詢響應(yīng)（Faster queries response）：對尚未分片的數(shù)據(jù)庫提交查詢時，它可能必須搜索查詢表中的每一行，才能找到您要查找的結(jié)果集。對于具有大型整體數(shù)據(jù)庫的應(yīng)用程序，查詢會變得異常緩慢。但是，通過將一個表拆分為多個表，查詢必須遍歷更少的行，并且其結(jié)果集可以更快地返回。

更多的寫帶寬(More write bandwidth)：無需主數(shù)據(jù)庫序列化寫操作，就可以并行寫操作，從而提高了寫吞吐量。寫作是許多網(wǎng)站的主要瓶頸。

向外擴展(Scaling out)：對數(shù)據(jù)庫進行分片可以幫助促進水平擴展（稱為向外擴展）。

分片的缺點：

增加系統(tǒng)的復雜性(Adds complexity in the system)：恰當?shù)貙崿F(xiàn)分片數(shù)據(jù)庫體系結(jié)構(gòu)是一項復雜的任務(wù)。如果處理不正確，則存在很大的風險，即分片過程可能導致數(shù)據(jù)丟失或表損壞。分片對團隊的工作流程也有重大影響。用戶必須從多個入口位置管理數(shù)據(jù)，而不是從單個入口點管理和訪問數(shù)據(jù)，這可能對某些團隊具有潛在地破壞性。

重新平衡數(shù)據(jù)(Rebalancing data)：在分片數(shù)據(jù)庫體系結(jié)構(gòu)中，有時分片會超出其它分片而變得不平衡，這也稱為數(shù)據(jù)庫熱點(database hotspot)。在這種情況下，分片數(shù)據(jù)庫的任何好處都會被抵消。數(shù)據(jù)庫可能需要重新分片以允許更均勻的數(shù)據(jù)分發(fā)。必須從一開始就建立重新平衡，否則在重新分片時，將數(shù)據(jù)從一個分片移動到另一個分片需要大量的停機時間。

從多個分片連接數(shù)據(jù)(Joining data from multiple shards)：要實現(xiàn)一些復雜的功能，我們可能需要從分布在多個分片中的不同來源提取大量數(shù)據(jù)。我們無法發(fā)出查詢并從多個分片獲取數(shù)據(jù)。我們需要對不同的分片發(fā)出多個查詢，獲取所有響應(yīng)并將其合并。

沒有原生支持(No Native Support)：并非每個數(shù)據(jù)庫引擎都原生支持分片。因此，分片通常需要自己實現(xiàn)。這意味著通常很難找到有關(guān)分片的文檔或解決問題的技巧。

ref: https://medium.com/system-design-blog/database-sharding-69f3f4bd96db