什麼是spider？
當您的資料庫不斷增長時，您絕對需要考慮其它技術，如資料庫分片。spider是mariadb内置的一個可插拔用于mariadb/mysql資料庫分片的存儲引擎，充當應用伺服器和遠端後端db之間的代理（中間件），它可以輕松實作mysql的橫向和縱向擴充，突破單台mysql的限制，支援範圍分區、清單分區、哈希分區，支援xa分布式事務，支援跨庫join。通過spider，您可以跨多個資料庫後端有效通路資料，讓您的應用程式一行代碼不改，即可輕松實作分庫分表！
分庫分表架構：
應用程式連接配接spider，spider充當中間件代理，将用戶端查詢的請求，按照事先定義好的分片規則，分發給後端資料庫，之後傳回的資料彙總在spider記憶體裡做聚合，最終傳回用戶端請求，對于應用程式而言是透明的。
典型案例---騰訊遊戲
騰訊遊戲的生産環境資料量達到了100tb，用了396個spider節點做資料拆分，分片後的資料用了2800個mysql節點存儲。
使用場景介紹
下面介紹一下我負責的一個項目，已認證spider實作了曆史表的垂直拆分。
随着業務的增長，單台伺服器磁盤空間有限，有些業務上的曆史資料，dba用工具pt-archiver歸檔後，曆史表就沒有用了，通常我們會把它單獨遷移到備份機，主庫上就删除了。但有的時候，bi統計部門來了一個需求，需要臨時關聯查詢這些曆史表，那麼，dba就需要從備份機上myloader導入到從庫上去，為了降低導資料引起的從庫cpu升高、磁盤io的瞬間增大，可能造成主從複制的延遲。
為了減少這種重複性的體力工作，為了更快速地縮短可用時間，我們可以通過spider引擎解決，通過它你可以将遠端伺服器上的表做一個映射，做一個軟連接配接，相當于你操作本地的表一樣，簡單而便捷，省去了那麼多麻煩，臨時提供給業務方用，也不用考慮過多的性能問題。
架構圖如下：
實施這個方案，選擇spider引擎是有優勢的：
sql解析和查詢優化是個非常複雜且很難做好的工作，其它替代産品都是自己實作，由于複雜性，這些産品都帶來了一些限制，比如不支援存儲過程、函數、視圖等，給使用和實施帶來了困難。而作為一個存儲引擎，這些工作都由mariadb自身完成了，可以友善地将大表做分布式拆分，和fabric相比，它的好處是對業務方使用是透明的，sql文法沒有任何限制，在不改變現有db架構的方案中，侵入性最小。
内部原理架構圖如下：
我們在一台從庫上，安裝上spider引擎，隻需兩條指令做一個表的“超連結”，分分鐘就解決了問題。
注：前提是你的從庫使用的是mariadb10。
下面是官方的垂直拆分壓測報告：
而在我的壓測結果上，分庫分表的性能會降低70%，垂直拆分性能會降低40%，性能損耗的原因是在分布式場景下，要保證2pc的一緻性和可用性，讀寫的表現就差，另外就是跨多個網絡傳輸這兩方面引起的，目前為rc公測版本v3.2.37，固在主庫上實作該功能要慎重！
spider引擎安裝
# mysql -uroot -p
spider引擎使用
1、定義後端伺服器和資料庫名字
這裡後端伺服器的名字為backend1，資料庫名字為test，主機ip位址為192.168.143.205，使用者名為user_readonly，密碼為123456，端口為3306。
注：如配置錯誤，可直接drop serverbackend1; 重新建立即可。
2、建立表的“超連結”
這裡通過設定comment注釋來調用後端的表，然後你就可以檢視sbtest表了，是不是很簡單？
同上，但差別是分庫分表是采用了類似表分區的概念實作。
spider_conn_recycle_mode= 1
連接配接複用，類似連接配接池這種功能
optimizer_switch= 'engine_condition_pushdown=on'
引擎下推，查詢推送到後端資料庫，将查詢結果傳回給spider做聚合
由于spider自身不儲存資料，隻儲存路由資訊，是無狀态的，因而可以部署多個spider做負載均衡，架構圖如下：
後端mysql可以結合mha實作高可用故障切換。
注：在mariadb10.2版本裡，spider準備ga。
原文釋出時間為：2017-04-20
本文來自雲栖社群合作夥伴dbaplus