轻松优化MySQL-之数据库切分2

数据切分及整合方案

我们已经非常清晰了通过数据库的数据切分能够极大的提高系统的扩展性，可是数据库中的数据在经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合。

数据的整合非常难依靠数据库本身来达到这个效果，尽管MySQL存在Federated存储引擎，能够解决部分相似的问题。可是在实际应用场景中却非常难较好的运用。那我们该怎样来整合这些分散在各个MySQL主机上面的数据源呢？

总的来说，存在两种解决思路：

1. 在每一个应用程序模块中配置管理自己须要的一个（或者多个）数据源。直接访问各个数据库，在模块内完毕数据的整合；
2. 通过中间代理层来统一管理全部的数据源。后端数据库集群对前端应用程序透明；

可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候，尽管短期内须要付出的成本可能会相对更大一些，可是对整个系统的扩展性来说，是非常有帮助的。所以，对于第一种解决思路我这里就不准备过多的分析，以下我重点分析一下在另外一种解决思路中的一些解决方式。

自行开发中间代理层

通过自行开发中间代理层能够最大程度的应对自身应用的特点，最大化的定制非常多个性化需求，在面对变化的时候也能够灵活的应对。当然，选择自行开发享受让个性化定制最大化的乐趣的同一时候，自然也须要投入很多其它的成本来进行前期研发以及后期的持续升级改进工作，并且本身的技术门槛可能也比简单的Web应用要更高一些。

利用MySQLProxy实现数据切分及整合

基于MySQLProxy自行编写LUA脚本实现数据切分相关代理功能。

利用Amoeba实现数据切分及整合

Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。眼下Amoeba已经具有Query路由、Query过滤、读写分离、负载均衡以及HA机制等相关内容。

Amoeba 主要解决的以下几个问题：

1. 数据切分后复杂数据源整合；
2. 提供数据切分规则并降低数据切分规则给数据库带来的影响。
3. 降低数据库与client的连接数。
4. 读写分离路由；

我们能够看出，Amoeba所做的事情，正好就是我们通过数据切分来提升数据库的扩展性所须要的。

Amoeba并非一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的开发框架，眼下基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。

AmoebaForMySQL主要是专门针对MySQL数据库的解决方式，前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于client的不论什么应用程序来说，AmoebaForMySQL和一个MySQL数据库没有什么差别。不论什么使用MySQL协议的client请求，都能够被AmoebaForMySQL解析并进行对应的处理。下如能够告诉我们AmoebaForMySQL的架构信息（出自Amoeba开发人员博客）：

image.png

AmoebaForAladin则是一个适用更为广泛，功能更为强大的Proxy程序。

他能够同一时候连接不同数据库的数据源为前端应用程序提供服务，可是仅仅接受符合MySQL协议的client应用程序请求。也就是说，仅仅要前端应用程序通过MySQL协议连接上来之后，AmoebaForAladin会自己主动分析Query语句，依据Query语句中所请求的数据来自己主动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节（出自Amoeba开发人员博客）：

image.png

咋一看，两者好像全然一样。细看之后才会发现两者主要的差别仅在于通过MySQLProtocalAdapter处理之后。依据分析结果推断出数据源数据库。然后选择特定的JDBC驱动和对应协议连接后端数据库。

事实上通过上面两个架构图大家可能也已经发现了Amoeba的特点了，他仅仅仅仅是一个开发框架。我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外。还能够基于自身的需求进行对应的二次开发。得到更适应我们自己应用特点的Proxy程序。

当对于使用MySQL数据库来说。不论是AmoebaForMySQL还是AmoebaForAladin都能够非常好的使用。当然，考虑到不论什么一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会相对更高一些。所以，对于仅仅须要使用MySQL数据库的时候，我还是建议使用AmoebaForMySQL。

AmoebaForMySQL的使用非常简单，全部的配置文件都是标准的XML文件，总共同拥有四个配置文件。分别为：

• amoeba.xml：主配置文件，配置全部数据源以及Amoeba自身的參数设置。
• rule.xml：配置全部Query路由规则的信息。
• functionMap.xml：配置用于解析Query中的函数所对应的Java实现类；
• rullFunctionMap.xml：配置路由规则中须要使用到的特定函数的实现类；

假设您的规则不是太复杂，基本上仅须要使用到上面四个配置文件里的前面两个就可完毕全部工作。Proxy程序经常使用的功能如读写分离。负载均衡等配置都在amoeba.xml中进行。此外。Amoeba已经支持了实现数据的垂直切分和水平切分的自己主动路由。路由规则能够在rule.xml进行设置。

眼下Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了，以前在与相关开发人员的沟通过程中提出过相关的建议，希望能够提供一个能够进行在线维护管理的命令行管理工具，方便在线维护使用，得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面临时还是Amoeba无法做到的，即使client应用在提交给Amoeba的请求是包括事务信息的，Amoeba也会忽略事务相关信息。当然，在经过不断完好之后，我相信事务支持肯定是Amoeba重点考虑添加的feature。

关于Amoeba更为具体的用法读者朋友能够通过Amoeba开发人员博客（http://amoeba.sf.net）上面提供的使用手冊获取，这里就不再细述了。

利用HiveDB实现数据切分及整合

和前面的MySQLProxy以及Amoeba一样，HiveDB相同是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，仅仅是眼下的HiveDB仅仅支持数据的水平切分。

主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同一时候支持数据的冗余及主要的HA机制。

HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异，他并非借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现的数据切分工作。

在HiveDB中，通过用户自己定义的各种Partitionkeys（事实上就是制定数据切分规则），将数据分散到多个MySQLServer中。在访问的时候。在执行Query请求的时候。会自己主动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给client应用程序。

单纯从功能方面来讲，HiveDB可能并不如MySQLProxy和Amoeba那样强大，可是其数据切分的思路与前面二者并无本质差异。此外，HiveDB并不仅仅仅仅是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。

以下是HiveDB官方站点上面一章图片，描写叙述了HiveDB怎样来组织数据的基本信息，尽管不能具体的表现出太多架构方面的信息，可是也基本能够展示出其在数据切分方面独特的一面了。

image.png

mycat数据整合

参见：http://www.songwie.com/articlelist/11

其它实现数据切分及整合的解决方式

除了上面介绍的几个数据切分及整合的总体解决方式之外，还存在非常多其它相同提供了数据切分与整合的解决方式。如基于MySQLProxy的基础上做了进一步扩展的HSCALE，通过Rails构建的SpockProxy。以及基于Pathon的Pyshards等等。

无论大家选择使用哪一种解决方式，总体设计思路基本上都不应该会有什么变化。那就是通过数据的垂直和水平切分，增强数据库的总体服务能力，让应用系统的总体扩展能力尽可能的提升，扩展方式尽可能的便捷。

仅仅要我们通过中间层Proxy应用程序较好的攻克了数据切分和数据源整合问题。那么数据库的线性扩展能力将非常容易做到像我们的应用程序一样方便。仅仅须要通过加入便宜的PCServerserver，就可以线性添加数据库集群的总体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。

上一篇	《性能优化系列文章目录》	下一篇