什么是Spider？
当您的数据库不断增长时，您绝对需要考虑其他技术，如数据库分片。Spider 是 MariaDB 内置的一个可插拔用于 MariaDB/MySQL 数据库分片的存储引擎，充当应用服务器和远程后端 DB 之间的代理（中间件），它可以轻松实现 MySQL 的横向和纵向扩展，突破单台 MySQL 的限制，支持范围分区、列表分区、哈希分区，支持XA分布式事务，支持跨库join。
通过 Spider，您可以跨多个数据库后端有效访问数据，让您的应用程序一行代码不改，即可轻松实现分库分表！
分库分表架构图：
![wKiom1kBlnKCMwO9AAEwJiDNJYQ545.png]( "图片1.png")
应用程序连接Spider，Spider充当中间件代理，将客户端查询的请求，按照事先定义好的分片规则，分发给后端数据库，之后返回的数据汇总在Spider内存里做聚合，最终返回客户端请求，对于应用程序而言是透明的。
分片字段的选取：
一定要针对业务上查询最频繁的字段做片键，查询时会直接路由到后端 DB 上，否则会轮训遍历后端所有 DB，跨多个网络性能就会下降。
1、范围分片的优点是无限扩容，但缺点是冷热数据不均匀。
2、HASH分片解决了冷热数据不均匀的问题，但今后扩容比较麻烦，比如之前对表取模了128张，今后变更为256张，数据要重新导入。
典型案例---腾讯游戏
![wKioL1kBm1bjMm7bAAFO4lc9S1I379.png]( "QQ图片20170427151738.png")
![wKiom1kBmCiCU50xAAFWvnYrAxI300.png]( "QQ图片20170427150437.png")
腾讯游戏的生产环境数据量达到了100TB，用了396个Spider节点做数据拆分，分片后的数据用了2800个MySQL节点存储。
使用场景介绍
下面我介绍一下我负责的一个项目，通过 Spider 实现了历史表的垂直拆分的经验分享。随着业务的增长，单台服务器磁盘空间有限，有些业务上的历史数据，DBA 用工具 pt-archiver 归档后，历史表就没有用了，通常我们会把他单独迁移到备份机，主库上就删除了。
但有的时候，BI 统计部门来了一个需求，需要临时关联查询这些历史表，那么 DBA 需要从备份机上 myloader 导入到从库上去，为了降低导数据引起的从库 CPU 升高、磁盘 IO 的瞬间增大，可能造成主从复制的延迟，为了减少这种重复性的体力工作，为了更快速的缩短可用时间，我们可以通过Spider引擎解决，通过它你可以将远程服务器上的表做一个映射，做一个软连接，相当于你操作本地的表一样，简单而便捷，省去了那么多麻烦，临时提供给业务方用，你也不用考虑啥性能问题。
架构图如下：
![wKioL1kBltvQ0AqjAAAPTqOSJ3k216.png]( "图片3.png")
实施这个方案，选择Spider引擎是有优势的：SQL 解析和查询优化是个非常复杂而且很难做好的工作，其他替代产品都是自己实现，由于复杂性，这些产品都带来了一些限，比如不支持存储过程、函数、视图等，给使用和实施带来了困难。
而作为一个存储引擎，这些工作都由 MariaDB 自身完成了，可以方便的将大表做分布式拆分，和 Fabric 相比，它的好处是对业务方使用是透明的，SQL 语法没有任何限制，在不改变现有 DB 架构的方案中，侵入性最小。
内部原理架构图如下：
![wKiom1kBlvTiyz4vAAEdeXad47k830.png]( "图片4.png")
我们在一台从库上，安装上 Spider 引擎，只需两条命令做一个表的“超链接”，分分钟就解决了问题。
注：前提是你的从库使用的是 MariaDB 10
下面是官方的垂直拆分压测报告：
![wKioL1kBlw7y4pJDAADP7W5xEvI440.png]( "图片5.png")
而在我的压测结果上，分库分表的性能会降低70%，而垂直拆分性能会降低 40%，性能损耗的原因是在分布式场景下，要保证 2pc 的一致性和可用性，读写的表现就差，另外就是跨多个网络传输这两方面引起的。
目前为RC公测版本V3.2.37，固在主库上实现该功能要慎重！
Spider引擎安装
# mysql -uroot -p < /usr/local/mysql/share/install_spider.sql
| mysql > SELECT engine, support, transactions, xa FROM information_schema.engines; ![wKioL1kBlyiSBSZZAAAcg7pgokk477.png]( "图片6.png")
|
Spider引擎使用
垂直拆分
1、定义后端服务器和数据库名字
| CREATE SERVER backend1 FOREIGN DATA WRAPPER mysql OPTIONS( HOST '192.168.143.205', DATABASE 'test', USER 'user_readonly', PASSWORD '123456', PORT 3306 ); |
这里后端服务器的名字为backend1，数据库名字为test，主机IP地址为192.168.143.205，用户名为user_readonly，密码为123456，端口为3306
注：如配置错误，可直接DROP SERVER backend1; 重新创建即可。
2、创建表的“超链接”
| CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=SPIDER DEFAULT CHARSET=utf8 COMMENT='wrapper "mysql", table "sbtest",srv "backend1"'; |
这里通过设置COMMENT注释来调用后端的表，然后你就可以查看sbtest表了，是不是很简单？
分库分表
| CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=SPIDER DEFAULT CHARSET=utf8 COMMENT='wrapper "mysql", table "sbtest"' PARTITION BY LIST (mod(id,2)) (PARTITION p0 VALUES IN (0) COMMENT = 'srv "backend1"' ENGINE = SPIDER, PARTITION p1 VALUES IN (1) COMMENT = 'srv "backend2"' ENGINE = SPIDER); |
同上，但区别是分库分表是采用了类似表分区的概念实现。
可调优参数
spider_conn_recycle_mode = 1
连接复用，类似连接池这种功能
optimizer_switch = 'engine_condition_pushdown=on'
引擎下推，查询推送到后端数据库，将查询结果返回给Spider做聚合
负载均衡架构设计
由于Spider自身不保存数据，只保存路由信息，是无状态的，所以可以部署多个Spider做负载均衡，架构图如下：
![wKioL1kBl0ezGWHyAABzL32W0RE447.png]( "图片7.png")
后端 MySQL 可以结合 MHA 实现高可用故障切换。
注：在MariaDB 10.2版本里，Spider准备GA，并且合并了腾讯的补丁。
RC最新体验版下载地址：
http://spiderformysql.com/downloads/spider-3.3/mariadb-10.2.0-spider-3.3-vp-1.1-linux-x86_64-glibc25.tgz
参考文献：
https://m17.mariadb.com/session/deep-dive-supporting-distributed-data-spider
https://www.percona.com/live/17/sessions/using-spider-sharding-production
https://www.percona.com/blog/2017/04/12/percona-live-2017-many-technical-mariadb-server-sessions/
http://mp.weixin.qq.com/s/GuxGkQTptjFhqI3eI1CgJw
本文转自hcymysql51CTO博客，原文链接： http://blog.51cto.com/hcymysql/1920036，如需转载请自行联系原作者
