mysql如何实现数据切分(2)-木庄网络博客

当前第2页返回上一页

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

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

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

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

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

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

自行开发中间代理层

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

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

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

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

利用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基本架构图（图4）：

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

利用Amoeba实现数据切分

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

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

数据切分后复杂数据源整合；
提供数据切分规则并降低数据切分规则给数据库带来的影响；
降低数据库与客户端的连接数；
读写分离路由。

可以看出，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架构图（图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――配置路由规则中需要使用到的特定函数的实现类。

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

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

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

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

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

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

数据切分与整合中可能存在的问题

这里，大家应该对数据切分与整合的实施有一定的认识了，或许很多读者都已经根据各种解决方案的优劣基本选定了适合于自己应用场景的方案，后面的工作主要就是实施准备了。

在实施数据切分方案之前，仍要分析一些可能存在的问题。一般来说，可能遇到的问题主要有以下几点：

引入分布式事务的问题；
跨节点Join的问题；
跨节点合并排序分页问题。
引入分布式事务的问题

一旦数据进行切分被分别存放在多个MySQL Server中，不管切分规则设计得多么完美（实际上并不存在完美的切分规则），都可能造成之前某些事务所涉及的数据已经不在同一个MySQL Server中了。

在这样的场景下，如果应用程序仍然按照老的方案，那么势必须要引入分布式事务来解决。而在MySQL各个版本中，只有从MySQL 5.0开始以后的各个版本才对分布式事务提供支持，而且目前仅有Innodb提供分布式事务支持。不过，即使我们刚好使用了支持分布式事务的MySQL版本，同时也使用Innodb存储引擎，分布式事务本身对于系统资源的消耗就很大，性能也并不太高，引入分布式事务在异常处理方面会带来很多比较难控制的问题。

怎么办？其实可以通过一个变通的方法来解决这种问题，首先须要考虑的是：数据库是否是唯一一个能够解决事务的地方？其实并不是这样的，完全可以结合数据库及应用程序来共同解决。各个数据库解决自身的事务，然后通过应用程序来控制多个数据库上的事务。

也就是说，只要我们愿意，完全可以将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上的小事务，并通过应用程序来总控各个小事务。当然，这样做要求应用程序必须要有足够的健壮性，当然也会给应用程序带来一些技术难度。

跨节点Join的问题

上面介绍了可能引入分布式事务的问题，现在再看看需要跨节点Join的问题。数据切分之后，也许有些老的Join语句无法继续使用，因为Join使用的数据源可能被切分到多个MySQL Server中了。

怎么办？这个问题从MySQL数据库角度来看，如果非得在数据库端直接解决的话，恐怕只能通过MySQL一种特殊的存储引擎Federated处理了。Federated存储引擎是MySQL解决类似于Oracle的DB Link之类问题的方案。和Oracle DB Link的主要区别在于，Federated会保存一份远端表结构的定义信息在本地。乍一看，Federated确实是解决跨节点Join非常好的方案。但是我们还应该清楚一点，那就是如果远端的表结构发生了变更，本地的表定义信息是不会跟着发生变化的。如果在更新远端表结构的时候并没有更新本地的Federated表定义信息，Query运行很可能出错，无法得到正确的结果。

对待这类问题，还是推荐通过应用程序来处理，先在驱动表所在的MySQL Server中取出驱动结果集，然后根据驱动结果集再到被驱动表所在的MySQL Server中取出相应的数据。可能很多读者朋友会认为这样做将对性能产生一定的影响，是的，确实会有一定的负面影响，但除此之外，基本上没有太多其他更好的解决办法了。而且，由于数据库通过较好的扩展之后，每台MySQL Server的负载就可以得到较好的控制，单纯针对单条Query来说，其响应时间可能比不切分之前要提高一些，所以性能方面带来的负面影响也并不是太大。更何况，类似于这种跨节点Join的需求也并不是太多，相对于总体性能而言，可能也只是很小一部分而已。所以为了整体性能，偶尔牺牲一点点，其实是值得的，毕竟系统优化本身就是很多取舍和平衡的过程。

跨节点合并排序分页问题

一旦进行了数据的水平切分之后，可能就并不只有跨节点Join无法正常运行，有些排序分页的Query语句的数据源可能也会被切分到多个节点，其直接后果就是这些排序分页Query无法继续正常运行。其实这和跨节点Join是一个道理，数据源存在于多个节点上，要通过一个Query来解决，就是一个跨节点Join操作。同样Federated也可以部分解决，但存在的风险也一样。但是有一点不同：Join很多时候都有一个驱动与被驱动的关系，所以它涉及的多个表之间的数据读取一般会存在一个顺序关系。但是排序分页就不同了，排序分页的数据源基本上可以说是一个表（或者一个结果集），并不存在顺序关系，所以从多个数据源取数据的过程是完全可以并行的。这样，排序分页数据的取数效率可以比跨库Join更高，所以带来的性能损失相对要小，在有些情况下可能比在原来未进行数据切分的数据库中效率更高了。当然，不论是跨节点Join还是跨节点排序分页，都会使应用服务器消耗更多的资源，尤其是内存资源，因为在读取访问及合并结果集的这个过程须要比不处理合并处理更多的数据。

以上就是mysql如何实现数据切分的详细内容，更多文章请关注木庄网络博客！

返回前面的内容