轉自：興趣部落?buluo.qq.com

導讀： Spider是為MySQL/MariaDB開發的一個特殊引擎，具有內嵌分片功能。現在它已經被集成到MariaDB10.0及以上版本中，作為MariaDB的一個新的主要性。Spider的主要功能是將數據分散到多個后端節點，它的作用類似于一個代理。

1. 表鏈接

Spider的表鏈接的技術參考ISO/IEC 9075-9:2008 SQL/MED標準。利用spider的這個特性，你可以像操作本地MariaDB實例的表一樣來操作遠程MariaDB實例上的表，也可以像操作本地MariaDB實例的表一樣來操作分布在多個MariaDB實例上的表。當創建一個spider存儲引擎的表時，該表指向遠程服務器上對應的一張表或者多個實例上的表，就像UNIX/Linux中的軟鏈接一樣。遠程服務器上的表可以是任何存儲引擎的表。

在執行CREATE TABLE命令創建spider引擎的表時，需要添加COMMENT或CONNECTION語法來指定遠程服務器的地址等信息。例如，在遠程服務器(該服務器是數據節點，假設IP為192.168.0.1)上創建了如下一張表：

spider節點創建一張表指向該表：

spider節點，表字段定義可以忽略。Spider第一次訪問表的時候，如果發現沒有表字段定義，會從后端節點拉取相關元數據，然后緩存在本地。

Spider的系統表spider_tables記錄了各個數據分片的位置信息，類似于編程語言中指針作用。該系統表可以便利spider跨節點的join操作：訪問數據所在的機器，然后把數據拉取到本地進行join操作；如果進行join操作字段不是分片字段，那么需要廣播SQL語句將數據拉取到spider節點進行join操作。Spider_tables類似圖1所示。

圖1. Spider表鏈接

2.事務

Spider分別針對單機事務與XA事務實現了相應的操作事務的方法。圖2列出了部分實現的方法。

圖2. Spider部分實現的事務接口

Spider參照分布式事務DTP/XA模型實現了分布式XA事務(見圖3)。在這個模型中，存在RM(Resource Manager，資源管理器)、TM(Transaction Manager， 事務管理器)以及AP(Application， 應用程序)三種角色。AP通過RM API來操作和管理資源，通過TM接口開啟/終止/結束事務。RM與TM之間需要實現XA接口。XA接口定義了兩階段提交的必要步驟，以及RM與TM之間需要進行的交互。Spider扮演的是TM角色，而后端的數據節點扮演的是RM的角色。

圖3. 分布式DTP/XA模型

為了使用分布式XA事務，業界定義的XA命令如下：

Spider會在系統表spider_xa中記錄XA事務的狀態，同時在另外一張系統表 spider_xa_members 中記錄參與該XA事務的節點，以便進行操作。在spider中，XA事務分別有四種狀態，如圖4所示，對應于NOT YET, PREPAED, ROLLBACK 以及 COMMITTED。 Spider在開始PREPARE階段之際會在系統表 spider_xa中標記該XA事務的狀態為NOT YET。在所有數據節點都接收到PREPARE消息以后, 該 XA事務的狀態進入到PREPARED階段。假如在PREPARE階段，某一個數據節點發生故障，那么spider會回滾該事務。相應地，事務的狀態變成ROLLBACK。最后，如果所有參與事務的節點都返回PREPARE OK，該事務進入提交階段。圖5給出了對應上述命令的每一個步驟，spider向后端節點發送的消息。

圖4. Spider XA事務狀態轉換

圖5. 執行XA事務，Spider與后端節點的交互

從圖5可以看到spider向后端節點發送XA START命令的時候會設置會話級別的事務特性，同時將XA事務ID發送到后端節點。因為XA事務ID由三部分組成，spider會 將這三個部分的解析出來，然后拼接成對應的字符串發送到后端節點。為了節省網絡開銷，Spider將XA END與XA PREPARE命令合并起來一起發送。也就是在這個 階段初始，spider在系統表里面記錄事務的狀態。如果所有的RM都返回OK，那么spider進入PREPARED 狀態，準備提交事務。否則，事務進入到回滾狀態。

3.插撥式引擎

MySQL最強大的功能之一以及區別于其他關系型數據庫系統的一個主要的特色是不同的表能夠采用不同的存儲引擎。每一個存儲引擎都有其優缺點，用戶能夠根據自己的需要定制MySQL的存儲引擎。存儲引擎能夠控制在哪里以及如何存放、獲取數據。它代表了下面物理層提供的抽象邏輯接口，也是數據庫執行實際I/O操作的地方。這是一個組件體系結構。在這個結構中，handler類定義了存儲引擎提供的接口和功能。因為所有的存儲引擎從基類handler繼承而來，所以它們能夠提供相同的功能。總的來說，handler類和handlerton結構在整個體系結構中扮演了中間層的角色。你所編寫的存儲引擎只有滿足了handler的要求后，才能順利插入到運行的MySQL服務器中。所有的網絡連接、安全認證、解析和優化由MySQL服務器本身完成，與存儲引擎無關。

Spider作為MySQL的一個可插拔引擎，實現了handler類定義的相應的存取方法。Spider本身并不存放數據，而是類似一個代理的功能將訪問請求路由到后端的數據節點。Spider提供了兩種途徑訪問后端節點存儲的數據。如圖6所示，spider可以遵循MySQL傳統的查詢處理流程來訪問數據，也開發了自有的一套來加速數據訪問。在傳統的查詢處理方式下，SQL查詢請求經過查詢解析、查詢重寫、查詢優化等步驟。按照生成的查詢執行計劃，spider從后端節點拉取數據，交給MySQL服務器處理。Spider在這種查詢處理框架之下的一個缺點是不能很好地利用后端節點可并行化特性，同時需要對SQL查詢進行兩次解析，帶來的性能損耗問題比較嚴重。在我們的測試中，性能損耗約50%左右。基于這個原因，為了加速聚集、統計等查詢，spider開發團隊提供了DirectSQL方式執行查詢。DirectSQL的原理類似于Map Reduce方案，將查詢直接下發到后端節點，無需在MySQL服務器層進行解析(Map階段)；后端節點將結果返回給spider，由spider合并結果集。(Reduce階段)。這個方式很好地利用后端節點可并行處理查詢的特點，消除重復解析SQL語句的行為。

圖6. MySQL體系下的spider

上面已經談到，spider本身并不存儲數據，因此需要將數據訪問請求轉換成其它方式，例如Handler、Handler Socket以及SQL方式。前面兩種訪問方式更像是一種NoSQL的數據訪問方式，允許查詢繞過SQL layer層。Spider允許后端的數據節點可以是不同的數據庫系統，通過2PC保證事務提交的原子性。

4.讀寫流程

為了更清楚地了解spider的讀寫流程，我們有必要研究一下數據庫系統的查詢執行模型以及MySQL的插拔式引擎如何跟這個模型對接的。數據庫系統基本都采用迭代器模型處理查詢，也叫volcano查詢執行引擎(發明這個詞的學者大概是因為查詢執行計劃樹看起來像一座火山，如圖7)。執行計劃樹的上層節點通過get_next方法驅動子節點獲取一條元組，子節點遞歸調用。在葉子節點也就是基本表將數據返回。這個模型的一個好處就是實現起來很優雅，同時數據流與控制流結合在一起方便程序的調試。這個模型的缺點是函數的大量調用使得進程/線程上下文切換頻繁，程序的局部性受到損害。因此，后來針對OLAP場景，采用了向量查詢執行模型來減少進程上下文的切換以及保證保證高速緩存的命中率。再次以圖7為例子，圖中的SQL語句的功能是查詢一個部門的平均薪資。假如在職工表EMP的員工ID字段Dno上存在索引，MySQL在Server層針對該查詢語句生成的查詢計劃如下:順序掃描部門表，通過索引訪問職工表，然后在兩表join操作之后進行投影操作。下一個階段為分組排序操作。上層的操作算子(例如join)，驅動子節點調用get_next方法(表掃描方法)獲取一條元組。底層操作算子(表訪問方法，handler接口定義)將數據返回。至此，我們可以總結一下MySQL體系的工作原理：查詢執行計劃由MySQL server層生成，存儲引擎受執行計劃驅動而訪問表。MySQL的handler已經定義好表的訪問方法，實現了這些訪問方法的存儲引擎就可以作為MySQL的插件式引擎而存在。

下面我們對spider的讀寫流程結合server層代碼進行分析。

圖7. 查詢計劃樹示例

4.1 SELECT操作

上面提到spider的作用類似一個proxy，本身并不存儲數據。因此spider處理SELECT語句(UPDATE與DELETE類似)首先需要根據查詢解析的信息生成一個SELECT語句，發送到查詢涉及的后端節點，將數據從遠端拉到本地，然后進行處理。函數spider_db_append_select_columns根據查詢涉及的讀集以及寫集獲取相應的字段，構造一個SQL語句從后端節點拉取數據到本地。如果涉及多個分片, spider將從不同實例獲取過來的結果集存放在不同的結果集spider_db_result中。類spider_db_fetch 提供了fetch_next, current_row等方法供上層方法調用。Server層調用get_next方法驅動引擎層獲取下一條數據。對于表訪問方法，MySQL 實現了索引掃描(ha_index_read)與隨機訪問(ha_rnd_next)的方法。對于切分為多個分片的DB，索引掃描需要借助優先隊列。索引掃描需要區分是否是第一次調用該方法。如果是第一次調用該方法，需要遍歷所有的分片讀取一條記錄，然后插入到優先隊列。對應到spider，如果第一次調用訪問遠端實例表的方法，需要生成SELECT語句，將遠端實例的數據拉到本地存放。在使用索引掃描的情況，MySQL 為每個分片保留一個key buffer以及record buffer。server利用隊列頭部的m_top_entry 獲得訪問的分片ID。接著，調用get_next方法獲取相應的元組，將返回的數據存放在record buffer，并插入到優先隊列。函數最后將元組從優先隊列返回。為緩解內存等資源的壓力，spider實現全表掃描的方法是逐個分片串行掃描(為了加速，spider也提供了并行掃描數據節點的選項)。圖8給出了spider對于上述兩種表訪問方法的實現機制。

圖8-1.索引掃描實現

圖8-2. 全表掃描

4.2 INSERT操作

MySQL的handler類對于INSERT操作提供的接口函數的名字是write_row。存儲引擎想要支持INSERT操作就必須實現write_row方法。Spider對于write_row方法的實現是簡單地根據查詢解析的信息拼接一條INSERT語句，發往后端節點處理。如果是批量插入操作則需要與MySQL Server層配合，將INSERT語句批量發到后端節點。圖9結合一條批量插入的INSERT語句給出MySQL中INSERT操作的具體實現。mysql_insert調用write_row執行具體的插入操作(第8行)。這是存儲引擎必須實現的方法。對應于spider，spider根據查詢涉及到的列(field)拼成一條INSERT語句(如果是分片數據庫，VALUSE中的列必須包含分區鍵，分區鍵是自增列的情況除外)。圖8中的QUERY將用戶ID(ID)和用戶名(Name)插入到user表，其中ID是分區鍵。mysql_insert根據VALUES包含的元組數目，判斷是否需要進行批量插入操作。該例子的QUERY的VALUES包含4條元組，所有需要進行批量插入操作。MySQL循環調用write_row方法觸發spider生成INSERT語句。Spider的write_row方法實現中會根據分區鍵將INSERT語句進行分組(第5行~第9行)。圖8給出的實例只有兩個數據分片，所以SQL語句被分成兩組。處理完VALUES以后，spider的INSERT語句也拼接完成。ha_end_bulk_insert方法通知spider完成VALUES處理。此時，spider將INSERT發送到后端節點進行處理(第11行)。

圖9. spider中INSERT操作的實現

4.3 DELETE實現

Spider想要支持DELETE操作必須實現MySQL handler類提供的ha_delete_row方法。與INSERT操作不同，DELETE操作需要生成一條SELECT語句將查詢涉及的分區鍵拉到spider節點。這是因為MySQL Server層的“once-a-tuple”的查詢執行模型(實際上基本所有的關系數據庫系統都采用該模型)會驅動spider逐個拼接DELETE語句，然后發往后端節點。這時候，spider需要知道對應的DELETE語句該往哪個后端節點發送。為了減少網絡開銷，spider提供了批量發送DELETE語句的功能。

圖10給出了spider中delete的實現。MySQL server層首先確定表的訪問方法：采用索引掃描或者全部掃描(第5行)。DELETE方法需要執行一次查找操作，調用get_next方法(info.read_record)獲取一條元組(第10行)。Spider需要判斷是否第一次調用get_next方法。如果是的話，則需要生成SELECT語句，將數據節點的數據拉到本地。否則，spider直接從本地返回數據給上層調用者。接下來，server層調用ha_delete_row方法將數據刪除。這是存儲引擎需要具體實現的方法。由于Spider本身并不存儲數據的緣故，其實現delete操作的主要思想是利用從后端節點拉取過來的數據(分區鍵，過濾條件等)，拼接成一條DELETE語句。然后，發送該請求到數據節點。Spider為了優化網絡開銷，提供了批量發送DELETE語句的選項。

UPDATE操作的實現類似DELETE，都需要spider生成SELECT語句從后端節點拉取數據。只不過，UPDATE在更新區分鍵的時候，可能需要多一次DELETE操作(刪除原來分區的數據，將新的數據插入到不同的分區)。

圖10. DELETE實現

5.總結

Spider的最大亮點是為MySQL的使用者提供分庫分表的中間件解決方案，同時在SQL語法上兼容MySQL。這得益于spider作為MySQL的插拔式引擎而存在。 Spider 是一個proxy，其本身并沒有存儲數據，因此上層的讀寫表請求需要轉換成SQL語句，重新路由到后端的數據節點。相比其它的中間件解決方案，spider的查詢解析次數都是兩次，并沒有過多開銷。此外，spider還針對聚集、排序等操作提供了MAP REDUCE的解決方案。總而言之，從兼容性、性能上衡量，spider是MySQL分庫分表的一個不錯的選項。