257      阿裏雲  技術社區[雲棲]

MariaDB Spider：實現MySQL橫縱向擴展的小能手

什麼是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

最後更新：2017-05-17 12:02:19

  上一篇：  Oracle安全攻防，你可能不知道自己一直在裸奔

  下一篇：  從Oracle遷移到MySQL的各種坑及自救方案