場景1:有兩個分佈在不通實例上的多張不通的表,想要經過某個字段關聯,作一個統計,或者想將分佈在不一樣實例的表,合併到一個實例中來作一些查詢。mysql
場景2:因爲數據庫容量的瓶頸或者是因爲數據庫訪問性能的瓶頸,將一某一個大庫、大表或者訪問量很是大的表進行拆分,而後分佈到不通的實例中。算法
簡單來講就是水平、垂直拆分的場景sql
Spider引擎是一個內置的支持數據分片特性的存儲引擎,支持分區和XA事務,該引擎能夠在服務器上創建和遠程數據庫表之間的連接,操做起來就像操做本地的表同樣。而且對後臺數據庫的引擎沒有任何限制。 目前spider引擎已經集成到了MariaDB中。
優點分析 1.對業務徹底透明,業務層不須要作任何的修改;對於分庫和分表的操做業務層不須要關係,只須要經過spider做爲代理入口,真實數據存儲在哪臺設備上,spider代理會自動進行路由。 2.方便橫向擴展,能解決單臺mysql的性能和存儲瓶頸3 3.對後端的數據庫引擎沒有限制 4.實現垂直拆分和水平拆分功能,針對分表支持此哈希,範圍,列表等算法 5.徹底兼容mysql協議 劣勢分析 1.Spider自己不支持緩存和全文搜索,只能在後端數據庫實現全文搜索 2.Spider沒法備份數據,只能對後端數據庫作物理備份 3.Spider自己是單點的,沒法作災備,只能經過VIP方式本身實現啊 4.因爲業務與數據庫之間多了一層spider,在性能上多少會有些損耗
從上圖能夠看出,spider後面接4臺DB server,能夠將不通功能的表分佈到後端不通的DB server中,好比user_info的表專門存放在HostA中,user_msg表存放在了HostB中,user_detail表存放在了HostC中,user_log表存放在了HostD中。在圖中的紅色部分,當咱們執行紅色部分的SQL的時候,spider會經過user_info表的映射關係以及HostA的IP映射關係,將查詢user_info表的請求都轉發到HostA上,HostA查詢完成後再將結果發給spider服務器,spider再轉發給客戶端
spider支持多種水平分表的模式,目前支持hash分表(hash)、範圍分表(range)、列表分表(list),我這裏用range來講明水平分表的工做原理。從上圖中能夠看出spider對user_info錶針對id進行了分區,將0~100000的記錄存儲在了HostA,100000~200000的記錄存儲在了HostB,200000~300000的記錄存儲在了HostC,300000~400000的記錄存儲在了HostD。當用戶訪問user_info的某條或者多條記錄的時候,spider會根據分區的狀況,對相關的記錄落在某臺或者多臺DB server上,再進行轉發。好比select * from user_info where id=1這個SQL,spider在收到這個請求後,會跟進分區狀況選擇對應的DB server進行轉發。這裏會將該請求轉發到HostA中。HostA處理完成後,再將結果返回給spider server,spider再將結果轉發給發起請求的客戶端。
從spider 10.0.0.4版本開始,spider引擎就集成到了MariaDB中,集成後安裝就很是的簡單,安裝步驟以下: 一、安裝mariaDB到spider server以及後端多臺DB server上; 安裝方法很是簡單,請參考:https://mariadb.com/kb/en/mariadb/getting-installing-and-upgrading-mariadb/ 二、安裝spider引擎到spider server上(後端的DB server不須要安裝spider引擎) mysql -uroot -p < install_spider.sql 或者登陸mysql後執行 source /path/install_spider.sql 備註:install_spider.sql在share目錄下面 這個命令所作的事情以下: 建立spider相關的系統表 spider_link_failed_log spider_link_mon_servers spider_tables spider_xa spider_xa_failed_log spider_xa_member 建立spider相關的表結構 加載spider引擎
未完待續~~~