Spider是个数据库存储引擎，MariaDB从10.0.4开始支持Spider，在10.3.7版本宣布Spider已经Stable（即GA了）。目前腾讯在大规模使用（腾讯游戏、腾讯支付等）并提供云服务。简单说来，Spider有3个作用，一是作为分库分表的中间件，二是支持像访问本地数据表一样访问远端表（进行普通查询、跨表Join和DML等），三是业务和数据库间的代理（Proxy）。

本文先介绍Spider的安装方法，接着介绍其常用的部署方式，进而介绍Spider的功能特性，包括与性能优化相关的高级特性DirectSQL和所支持的多种下推操作。然后介绍Spider与VP配合使用的进阶模式。接着简单介绍Spider的性能。最后总结Spider优缺点和使用场景。

Spider简介

Spider是由日本的MySQL开发者Kentoku Shiba创建和开发的存储引擎，腾讯数据库团队贡献了非常多Patch。与InnoDB一样，Spider也是MySQL插件式存储引擎架构的一个具体实现，用户发起的SQL经过解析和优化后下发送给位于存储引擎层的Spider，Spider再根据后端数据表的存储方式做进一步的转发，最后收集后端数据库实例返回的结果集做合并或排序等操作后返回给客户端。所以，其实Spider发挥了类似代理的作用。

Spider主要用于进行数据库分片和将其他数据库实例的表映射到本地。Spider基于MySQL分区表（MySQL Partition Table）来进行数据分片，不同的是分区表中各个分区的数据仍在该MySQL实例上，而Spider是将这些分区/分片放到其他MySQL实例（也支持放到非MySQL实例）上。下图是个基于Spider的分片方案：

ip为192.168.0.201的节点部署Spider（Spider节点），192.168.0.202和192.168.0.203这2个节点作为Spider的后端节点（数据节点）。在Spider节点定义一个sbtest分区表，包括2个分区，PART1的数据位于192.168.0.202，PART2的数据位于192.168.0.203。客户端CLIENT的增删改查SQL发送给Spider节点SPIDER1，Spider解析SQL将请求转发给后端数据节点BACKEND1和/或BACKEND2。当SQL需要跨后端多个数据节点时，Spider通过2阶段提交（2 phase commit）来实现数据的ACID特性。

Spider的远程表连接功能类似于MySQL的FEDERATED存储引擎，不同的是Spider支持事务和XA，而FEDERATED都不支持，可能正因为这个原因MariaDB未像MySQL一样默认安装FEDERATED存储引擎。下图是一个最简单的Spider连接部署方式：

BACKEND1节点的数据库上已存在了SBTEST表，假设用户需要在SPIDER1节点上执行一个Join操作，涉及到BACKEND1，显然在传统的MySQL架构下无法实现跨实例的Join操作，有了Spider存储引擎后，可以在SPIDER1上创建一个SBTEST虚拟表（ENGINE=Spider），这样就可以将BACKEND1上的SBTEST映射到SPIDER1进行多表Join操作。

Spider安装方法

安装方法简单。在MariaDB中，Spider默认未安装，若要使用，仅需先执行二进制包share目录下的install_spider.sql。该sql脚本所做的事情包括创建Spider相关的系统表，并安装Spider引擎插件。

调用install_spider.sql完成Spider存储引擎初始化后，会在mysql系统库增加9张表。如下：

Spider系统表

spider_link_mon_servers保存用于监控Spider后端数据节点存活情况的Spider监控服务器信息；spider_link_failed_log用于记录Spider监控服务器探测到的Spider的后端数据节点连接失败的日志；

spider_tables保存了该Spider节点创建的所有Spider存储引擎表定义信息；spider_table_crd和spider_table_sts用于保存Spider存储引擎表的统计信息，crd表示cardinality，即索引的区分度，sts表示statistics，即Spider表的数据统计信息。

spider_table_position_for_recovery用于保存Spider表对应的后端数据进行故障恢复时的状态信息，可以类比为一个MySQL复制状态信息，包括复制关系主从，需复制的schema和复制的位置信息。

spider_xa保存了节点当前的Spider表XA事务信息，spider_xa_member表示XA事务有哪些数据节点参与，spider_xa_failed_log记录了XA事务的错误日志。

information_schema系统库上也会增加一张Spider相关的表

SPIDER_ALLOC_MEM表示Spider存储引擎的内存使用情况，保存了Spider下的每个函数分配的内存总大小，当前分配的内存大小，分配和释放内存的次数，以及该函数所处的源码文件和偏移位置，例子如下图所示：

Spider部署模式

1、连接模式（垂直分表）

连接模式可以使用在多个不同的场景，包括将多个数据库实例的表映射到同个数据库实例上。这既可以实现跨表Join，又可以起到数据垂直拆分的效果。如下所示：

业务将用户的不同类型信息user_info、user_msg、user_detail和user_log分别保存到不同实例上实现垂直扩展，业务可以直接访问这些表进行DML操作，相互间没有干扰，这样可以解除单台服务器的存储和计算资源瓶颈。但毕竟它们都属于用户信息，有多表查询的需求，所以可以将这些表映射到独立的Spider实例上，业务通过Spider实例进行普通查询操作，包括跨表的各种Join，还可以在Spider实例上进行各种统计和分析操作。当然，业务也可以通过Spider实例统一对这些表进行DML操作，通过部署多个Spider实例实现访问的负载均衡。

验证用例

下面我们以user_info和user_msg为例来做下部署演示，使用mariadb 10.3.9作为Spider节点，使用InnoSQL 5.7.20-v3作为后端存储节点node1和node2：

先定义2个后端server：

查询mysql.servers表确认创建成功：

分别在后端节点创建user_info和user_msg，并插入2条数据

在Spider节点创建2个对应的表

查询mysql.spider_tables确认

通过Spider节点数据目录确认本地并没有相应的表数据，仅有表定义

在Spider节点进行2个表Join查询

可以看到，在Spider节点可以像对待本地表一样对其他数据库实例的表进行Join操作。

2、水平分表模式

这种模式应该是最常用的模式，类似于现有MySQL中间件的分库分表。可以将一张表拆分为多个分区，每个分区保存一部分数据。如下所示：

在MariaDB中，通过创建Spider存储引擎的分区表即可实现水平分表。下面我们演示创建一个基于range的分区表

验证用例

先在Spider节点创建分区表，将表划为2个分区。

分别在2个数据节点创建对应的表结构

在Spider节点插入6条数据

确认分布到不同的后端数据节点上

Spider支持MySQL/MariaDB所有类型的分区表，除了上面演示的基于Range分区外，Spider还支持Hash、List和KEy分区。

3、数据HA模式

Spider能够提供数据高可靠和高可用，即采用镜像部署模式，将一份数据写入多个后端数据节点。这样保证了一个后端节点故障不会导致数据丢失，而且Spider能够监控数据节点状态，从存活的数据节点查询用户所需的数据，演示如下。

验证用例

在Spider节点创建镜像模式的表定义，并插入一条数据

确认后端每个数据节点都有该数据

尝试kill掉node1节点，再执行查询，提示node1无法连接

这是因为我们还没有配置后端节点的监控服务器，创建监控服务器并重建Spider表

kill掉node1节点后，能够执行查询，但不能执行DML。类似于semi-sync或商用数据库方案的最大保护模式

4、分表&HA部署

Spider支持分区加HA的部署方式，实现数据水平扩展的同时实现数据高可靠和高可用。部署模式参考如下：

在上图中，部署3个Spider节点用于服务高可用和负载均衡，分布表TABLE1有3个分区，Spider下面有3个数据节点，每个数据节点保存2个分区的数据。每个分区的数据均放置在2个数据节点上。下面演示下部署方式。

验证用例

在Spider创建新数据节点node3的server,在分别在每个数据节点新建另一个server，可以看到同个数据节点的不同server位于不同的数据库，比如node1属于wzh，node1_1属于wzh_1。

基于node1、node2、node3和node1_1、node2_1、node3_1进行range分表+HA部署

再插入3条记录位于不同分区的数据；

查看后端3个数据节点的数据

其他部署模式

上面列举了几种较常用的部署方式。通过介绍很容易发现，通过组合还可以部署其他多种多样的模式来满足不同的需求。体现较大的灵活性。而且，即使目前不支持的模式，也可以通过二次开发来提供支持。

Spider的功能特性

虚拟表

从上面的部署案例可以知道，Spider表本身不会存储数据，用户创建一个Spider表后，会在对应的实例数据目录的对应数据库下生成一个frm文件用于保存表定义，会将该表的更多信息持久化到mysql.spider系统表中，包括与数据节点实体表的连接信息，连接状态等，这样Spider表在实例重启后仍能够正常使用。Spider为每个后端数据表都维护了一个连接。

DML处理

在Spider表上进行的DML和查询操作均下发到后端数据节点。在HA部署模式下，Spider能够进行负责均衡，将查询请求分摊到不同的数据几点上。对于DML操作，不管是HA模式还是分表模式，Spider节点均对数据节点进行并发地数据增删改。涉及到多个数据节点的DML操作，Spider基于2阶段事务实现数据的一致性。

DDL处理

对于DDL操作情况有些不一样。对于Spider表进行drop table操作不会影响后端数据节点，也就是说数据节点对应的表不会被删除。类似地，对Spider节点进行alter table加索引或删索引等操作也不会影响后端数据。

但若执行truncate table，则后端数据节点的表也会被清空。如下所示

Spider节点执行truncate table user_info;

观察数据节点，发现对应的表也被清空

DirectSQL和Push Down

为了提高性能，还支持多种功能，包括使用DirectSQL直接操作后端数据节点，各种下推（push down）优化等。

DirectSQL

Spider提供了2个DirectSQL，分别是SPIDER_DIRECT_SQL和SPIDER_BG_DIRECT_SQL。其用法如下：

SPIDER_DIRECT_SQL('sql', 'tmp_table_list', 'parameters')

DirectSQL它会直接在parameters参数指定的远端节点执行sql参数指定的SQL，并将结果保存在tmp_table_list指定的临时表上，parameters一般指定为在mysql.servers中定义的一到多个后端数据节点server。类似于MapReduce机制，直接将SQL并行发送给指定的server（Map过程），将结果集返回给Spider节点，由其经过处理后返回给客户端（Reduce阶段）。操作如下所示

聚合下推

将min、max、avg、count和sum等常用的聚合操作直接下推到数据节点，再聚合数据节点返回的结果。

Update/Delete下推

如果是批量更新或删除，Spider将整个Update/Delete操作下推到数据节点，而不是在Spider节点解析Values后逐条下发到数据节点。

Join下推

与聚合操作、DML操作类似，Join操作也可以直接下推到数据节点，Spider仅做结果集处理。除此之外，Spider还支持引擎条件（Engine Condition）下推、索引hints下推等，这些下推操作即减少了Spider节点和数据节点重复的SQL解析优化，又减少了返回给Spider的结果集大小，可以节省系统的资源消耗，并提高实例的性能。

Vertical Partition (VP) 存储引擎

VP是Spider团队开发的另一个存储引擎，跟Spider相配合能够实现更加高级的功能。比如在HA模式下依托VP在不同的副本建立独有的索引，根据客户端SQL的特点，选择合适的副本下发请求。

上图为VP+Spider的组合部署模式，为table_a创建2个后端实体表table_a_ca和table_a_cb，2个表除了索引和分区键不同，其他均相同。

客户端不同where条件的查询会路由到不同的数据节点上，比如where条件为col_a的路由到以col_a为分区键的后端，而where条件为col_b的则路由到table_a_cb。VP存储引擎目前还未MariaDB尚未支持，还在开发过程中。

Spider性能简介

我们没有对Spider性能进行验证测试，在此仅贴下MariaDB官方文档中提供的性能指标。

上图为sysbench只读场景下，MariaDB（InnoDB）、Spider和其他Proxy套件的性能对比，可以发现在低并发场景下Spider处于弱势，但并发数达到128以上，除了Spider和HaProxy，MariaDB和MySQL-Proxy性能均有急剧下降。

上图为读写操作在不同Spider表数据冗余下的性能对比，可以发现副本多了对读帮助较大，对写影响较小。

Spider的优缺点总结

Spider最大的优势是在数据库进程内部实现了分库分表和跨节点的表复杂查询，这样容易做到跟MySQL协议的100%兼容。依托于成熟而灵活的MySQL插件式存储引擎框架，可以进一步堆叠/扩展更多高级功能，比如后端节点的探活和自动切换，多个Spider节点的负载均衡等。可以说，基于引擎插件层进行MySQL功能特性扩展是个非常不错的方向。

Spider的缺点在于用户数还是太少，功能集未经过大规模验证，成熟度不高。此外文档偏少，功能也还不够丰富。

下面进一步列举说明Spider的各种优缺点：

Spider的优势

a、对业务透明，业务程序可以不用修改或做非常少的修改。业务连接到Spider节点，具体访问哪个数据节点由Spider处理，无需放在业务逻辑中；

b、方便水平扩展，能解决单个服务器的计算和存储资源瓶颈问题。扩展能力可以是无穷的；

c、支持多种后端数据节点类型，比如后端节点可以是MariaDB，也可以是MySQL，甚至是Oracle（MariaDB目前暂不支持）；

d、拆分方式灵活。可以根据需求实现垂直拆分和水平拆分功能，水平拆分支持基于分区表，可支持哈希、范围、列表等算法；

e、完全兼容MySQL协议，由于Spider位于存储引擎层，基于分区表实现数据拆分，所以MySQL的所有SQL在Spider均可以进行适配。这是Spider相比传统的分库分表中间件非常大的优势；

f、可透明使用后端数据节点的多种功能特性。比如全文索引，地理位置索引等。

Spider 的劣势

a、Spider的表不支持查询缓存；

b、Spider实例一致性物理备份困难。需要到每个数据节点单独进行物理备份，整个实例的一致性物理备份不好做；

c、Spider本身是单点。可通过MySQL复制来实现高可用，但需为业务提供VIP实现Spider节点切换后的服务可用性；

d、性能不如单MariaDB/MySQL实例。这是由于用户请求多跨一层网络，性能上会有一些损耗。尤其是在跨分区、跨表查询时。

e、线上使用案例较少，功能稳定性还未得到全面验证。比如笔者在某些部署模式下使用XA事务会报错，在执行DirectSQL时会导致mysqld crash。

总结

Spider部署非常简单，使用方便。可以使用在三类业务场景：一是业务存在多个数据库实例，某些实例有访问其他实例上数据的需求（比如做Join）；二是分库分表场景，比如业务存在超大表，或者业务的数据量一直在增加导致单数据库实例无法容纳，或者业务的并发请求非常多，单实例无法处理；三是作为Proxy，这个场景非常多，比如使用Spider实例作为堡垒机，外部业务均访问Spider节点，不直接访问后端数据库服务，提高网络安全性。

参考文献：

1、https://mariadb.com/kb/en/library/spider/

2、Spider引擎分布式数据库解决方案（最全的spider教程）

3、MariaDB Spider：实现MySQL横纵向扩展的小能手

4、https://www.slideshare.net/MariaDB/m18-how-mariadb-server-scales-with-spider

5、http://wiki.ivoa.net/internal/IVOA/InterOpMay2014NewTechnologies/Spider-MariaDB.pdf