新的問題：
若數據量即使使用 Partition，都不是單一臺主機有辦法處理；
存放要分散，但存取要集中。
這個時候，就可以考慮 Spider 存儲引擎。
事實上，對於數據驅動的功能，都可能面臨類似的問題，數據庫日益膨大，單表、單數據庫、單機器已經不能存儲和處理數據了。 所以會有上述說明的分片設計。
針對不同程度的數據，會選擇到不同的具體分片實現，這也是上述說明的各種單表的分區作業。
不過基於有些引擎的限制或者功能不夠強大，可能在數據庫分片上無法實現跨設備的作業。
但是 Spider 引擎可能提供了一個比較好的解決方案。
Spider 是什麼？
Spider 是 MariaDB 內置的一個可插拔用於 MariaDB/MySQL 數據庫分片的存儲引擎，充當應用服務器和遠程後端 DB 之間的代理（中間件），它可以輕鬆實現 MariaDB/MySQL 的橫向和縱向擴展，突破單臺 MariaDB/MySQL 的限制，支持範圍分區、列表分區、哈希分區，支持 XA 分佈式事務，支持跨庫 join。完成數據庫跨越多組實例(instances)。
使用 Spider 存儲引擎創建表後，該表將鏈接到遠程服務器上的表。遠程表可以是任何存儲引擎。通過建立從本地 MariaDB 服務器到遠程 MariaDB 服務器的連接，可以具體實現錶鏈接。該鏈接對於屬於同一事務的所有表共享。
簡單說起來：
Spider 首先提供的是從另一個 MariaDB 服務器訪問一個 MariaDB 服務器（也可以是其它類型數據庫服務器）上的表的方法。
保存實際表數據的 MariaDB 服務器上根本沒有任何特定的 Spider 代碼，它是一個普通的 MariaDB 服務器。MariaDB 服務器被配置爲訪問該數據，然後使用 Spider 存儲引擎使用通常的 MariaDB 協議訪問另一臺服務器上的數據。
圖源 mariadb 博客(https://mariadb.com/resources/blog/uses-for-mariadb-and-the-spider-storage-engine/)
可以看到，Spider 只在引用節點上處於活動狀態，目標節點不需要安裝 Spider。創建“spider 表”意味着我們定義一個表，該表包含目標表中相同列或列的子集，並引用目標服務器。
還要注意，“spider 節點”上沒有這些表的數據，也沒有重複的數據，所有數據都駐留在目標節點上。
Spider 存儲引起核心概念
這是幾乎每一篇介紹 Spider 的文章都會提到的東西。
典型的 Spider 部署有一個無共享的集羣架構(shared-nothing clustered architecture)。這個系統可以使用任何滿足對硬件或軟件有最低的特定要求的硬件。它由一組運行有一個或多個稱爲節點(node)的 MariaDB 進程的主機(computers)組成。
存儲數據的節點將被設計爲後端節點(Backend Nodes)，可以是使用後端中可用的任何存儲引擎的任何 MariaDB、MySQL、Oracle 服務器實例。
Spider 代理節點(Spider Proxy Nodes)是至少運行 MariaDB 10 版本上，用於向後端節點聲明每個表的附件(attachment)。此外，還可以設置 Spider 代理節點，以便將表拆分並鏡像到多個後端節點。
Spider 常見用例：
圖源官網(https://mariadb.com/kb/en/spider-storage-engine-core-concepts/)
此外 Spider 引擎的底層架構和優化設計還是比較複雜的，有興趣可以查看官網瞭解，或者從下圖中窺見一二：
圖源官網(https://mariadb.com/kb/en/spider-storage-engine-core-concepts/)