MySQL数据切分及整合方案

MySQL数据切分及整合方案

关键字: 分库分表

From：http://bbs.jcwcn.com/thread-264962-1-1.html

 

《MySQL性能调优与架构设计》第14.5节“数据切分及整合方案”


14.5  数据切分及整合方案
通过前面的章节，已经清楚了通过数据库的数据切分可以极大地提高系统的扩展性。但是，数据库中的数据经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是如何让这些数据源得到较好的整合，可能这也是很多读者非常关心的一个问题。本节主要的内容就是分析各种可以帮助我们实现数据切分及数据整合的整体解决方案。

数据的整合很难依靠数据库本身来达到，虽然 MySQL 存在 Federated 存储引擎，可以解决部分类似的问题，但是在实际应用场景中却很难较好地运用。那该如何来整合这些分散在各个 MySQL 主机上的数据源呢？

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

（1）在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；

（2）通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明。

可能90%以上的人在面对这两种解决思路时都会倾向于选择第二种，尤其是系统不断庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内须要付出的成本可能会相对大一些，但对整个系统的扩展性来说，是非常有帮助的。

所以，对于第一种解决思路就不过多分析了，下面重点分析第二种思路中的一些解决方案。

1. 自行开发中间代理层

在决定选择通过数据库的中间代理层来解决数据源整合的架构方向之后，有不少公司（或者企业）自行开发了符合自身应用特定场景的代理层应用程序。

自行开发中间代理层可以最大程度地应对自身应用的特点，最大化定制个性化需求，在面对变化的时候也可以灵活应对。这应该是自行开发代理层最大的优势了。

当然，选择自行开发，享受个性化定制最大化乐趣的同时，自然也需要投入更多的成本来进行前期研发及后期的持续升级改进工作，而且本身的技术门槛可能也比简单的 Web 应用更高。所以，在决定选择自行开发之前，仍须要进行比较全面的评估。

由于自行开发更多时候考虑的是如何更好地适应自身应用系统，应对自身的业务场景，所以这里也不好分析太多。下面将主要分析当前比较流行的几种数据源整合解决方案。

2. 利用 MySQL Proxy 实现数据切分及整合

MySQL Proxy 是 MySQL 官方提供的一个数据库代理层产品，和 MySQL Server 一样，它也是一个基于 GPL 开源协议的开源产品。可用来监视、分析或传输它们之间的通讯信息。它的灵活性允许最大限度地使用它，目前具备的功能主要有连接路由、Query分析、Query过滤和修改、负载均衡，以及基本的 HA 机制等。

实际上，MySQL Proxy 本身并不具有上述所有的功能，而是提供了实现上述功能的基础。要实现这些功能，还须要我们自行编写 LUA 脚本。

MySQL Proxy 实际上是在客户端请求与 MySQL Server 之间建立了一个连接池。所有客户端请求都发向 MySQL Proxy，然后经由 MySQL Proxy进行相应的分析，判断出是读操作还是写操作，分发至对应的 MySQL Server 上。对于多节点 Slave 集群，也可以起到负载均衡的效果。如MySQL Proxy 基本架构图（图14-4）：

图14-4  MySQL Proxy 架构


通过上面的架构简图，可以清晰地看到 MySQL Proxy 在实际应用中所处的位置，以及能做的基本事情。MySQL Proxy 详细的实施细则在 MySQL 官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从 MySQL 官方网站免费下载或者在线阅读，这里就不赘述。

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

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

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

（1）数据切分后复杂数据源整合；

（2）提供数据切分规则并降低数据切分规则给数据库带来的影响；

（3）降低数据库与客户端的连接数；

（4）读写分离路由。


图14-5  Amoeba For MySQL架构

可以看出，Amoeba 所做的事情，正好就是通过数据切分来提升数据库的扩展性所需要的。

Amoeba 并不是一个代理层的 Proxy 程序，而是一个开发数据库代理层 Proxy 程序的框架，目前基于 Amoeba 所开发的 Proxy 程序有 Amoeba For MySQL 和 Amoeba For Aladin 两个。

Amoeba For MySQL是专门针对 MySQL 数据库的解决方案，前端应用程序请求的协议及后端连接的数据源数据库都必须是 MySQL。对于客户端的任何应用程序来说，Amoeba For MySQL 和一个 MySQL 数据库没有什么区别，任何使用 MySQL 协议的客户端请求，都可以被 Amoeba For MySQL 解析并进行相应的处理。Amoeba For可以告诉我们 Amoeba For MySQL 的架构信息（出自 Amoeba 开发者博客）：

Amoeba For Aladin 则是一个适用更为广泛、功能更为强大的 Proxy 程序。它可以同时连接不同数据库的数据源为前端应用程序提供服务，但是仅仅接受符合 MySQL 协议的客户端应用程序请求。也就是说，只要前端应用程序通过 MySQL 协议连接上来，Amoeba For Aladin 会自动分析 Query 语句，根据 Query 语句中所请求的数据来自动识别出该 Query 的数据源是在什么类型数据库的哪一个物理主机上。Amoeba For Aladdin 架构图（图14-6）展示了 Amoeba For Aladin 的架构细节（出自 Amoeba 开发者博客）。

乍一看，两者好像完全一样嘛。细看才会发现两者主要的区别仅在于通过 MySQL Protocal Adapter处理之后，根据分析结果判断出数据源数据库，然后选择特定的 JDBC驱动和相应协议连接后端数据库。

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

但对于使用 MySQL 数据库来说，不论是 Amoeba For MySQL 还是 Amoeba For Aladin 都可以很好地使用。当然，考虑到任何一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会更高一些。所以，在仅仅须要使用 MySQL 数据库的时候，还是建议使用 Amoeba For MySQL。

Amoeba For MySQL 的使用非常简单，所有的配置文件都是标准的 XML 文件，总共有4个，分别如下：

·       amoeba.xml——主配置文件，配置所有数据源及Amoeba自身的参数；

·       rule.xml——配置所有 Query 路由规则的信息；

·       functionMap.xml——配置用于解析 Query 中的函数所对应的 Java 实现类；

·       rullFunctionMap.xml——配置路由规则中需要使用到的特定函数的实现类。


图14-6  Amoeba For Aladdin架构

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

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

关于Amoeba更为详细的使用方法读者可以通过Amoeba开发者博客（http://amoeba. sf.net）上面提供的使用手册获取，这里就不再细述了。

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

和前面的 MySQL Proxy 及 Amoeba 一样，HiveDB 同样是一个基于 Java 针对MySQL 数据库的提供数据切分及整合的开源框架，只是目前的 HiveDB 仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的 HA 机制。

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

在 HiveDB 中，通过用户自定义的各种 Partition keys（即制定数据切分规则），将数据分散到多个 MySQL Server 中。访问时运行 Query 请求，则会自动分析过滤条件，并行从多个 MySQL Server 中读取数据，并合并结果集返回给客户端应用程序。

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

HiveDB 官方网站上的 HiveDB 架构示意图（图14-7），描述了 HiveDB 如何来组织数据的基本信息，虽然不能详细地表现出架构方面的信息，但是也基本可以展示其在数据切分上独特的一面了。


图14-7  HiveDB 架构示意

5. 其他实现数据切分及整合的解决方案

除了上面介绍的几个数据切分及整合的整体解决方案之外，还存在很多其他的解决方案、如在MySQL Proxy 的基础上做进一步扩展的 HSCALE，通过 Rails 构建的 Spock Proxy，以及基于 Pathon 的 Pyshards，等等。

不管大家选择使用哪一种解决方案，总体设计思路基本上都不应该有任何变化，即通过数据的垂直和水平切分，增强数据库的整体服务能力，让应用系统的整体扩展能力尽量得到提升，扩展方式尽可能便捷。

只要通过中间层 Proxy 应用程序较好地解决了数据切分和数据源整合问题，那么数据库的线性扩展能力将像应用程序一样方便：只要通过添加廉价的 PC Server 服务器，即可线性增加数据库集群的整体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。