Spider引擎(解决分库分表的尴尬)

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Spider引擎(解决分库分表的尴尬)》，聊聊MySQL、MariaDB，我们一起来看看吧！

场景假设

场景1：有两个分布在不通实例上的多张不通的表，想要通过某个字段关联，做一个统计，或者想将分布在不同实例的表，合并到一个实例中来做一些查询。

场景2：由于数据库容量的瓶颈或者是由于数据库访问性能的瓶颈，将一某一个大库、大表或者访问量非常大的表进行拆分，然后分布到不通的实例中。

简单来说就是水平、垂直拆分的场景

一、Spider引擎简介

1、什么是Spider引擎

Spider引擎是一个内置的支持数据分片特性的存储引擎，支持分区和XA事务，该引擎可以在服务器上建立和远程数据库表之间的链接，操作起来就像操作本地的表一样。并且对后台数据库的引擎没有任何限制。
目前spider引擎已经集成到了MariaDB中。

2、Spider架构图

3、Spider的优劣对比

优势分析
1.对业务完全透明，业务层不需要做任何的修改；对于分库和分表的操作业务层不需要关系，只需要通过spider作为代理入口，真实数据存储在哪台设备上，spider代理会自动进行路由。
2.方便横向扩展，能解决单台mysql的性能和存储瓶颈3
3.对后端的数据库引擎没有限制
4.实现垂直拆分和水平拆分功能，针对分表支持此哈希，范围，列表等算法
5.完全兼容mysql协议

劣势分析
1.Spider本身不支持缓存和全文搜索，只能在后端数据库实现全文搜索
2.Spider无法备份数据，只能对后端数据库做物理备份
3.Spider本身是单点的，无法做灾备，只能通过VIP方式自己实现啊
4.由于业务与数据库之间多了一层spider，在性能上多少会有些损耗

二、Spider的使用场景解析

1、垂直分表的场景和解析

从上图可以看出，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再转发给客户端

2、水平分表的场景和解析

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引擎实战

1、安装

从spider 10.0.0.4版本开始，spider引擎就集成到了MariaDB中，集成后安装就非常的简单，安装步骤如下：

1、安装mariaDB到spider server以及后端多台DB server上；

    安装方法非常简单，请参考：https://mariadb.com/kb/en/mariadb/getting-installing-and-upgrading-mariadb/

2、安装spider引擎到spider server上（后端的DB server不需要安装spider引擎）

    mysql -uroot -p 

2、使用

未完待续~~~

终于介绍完啦！小伙伴们，这篇关于《Spider引擎(解决分库分表的尴尬)》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！