数据切分及整合方案

14.5数据切分及整合方案通过前面的章节，已经清楚了通过数据库的数据切分可以极大地提高系统的扩展性。但是，数据库中的数据经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是如何让这些数据源得到较好的整合，可能这也是很多读者非常关心的一个问题。本节主要的内容就是分析各种可以帮助我们实现数据切分及数据整合的整体解决方案。数据的整合很难依靠数据库本身来达到，虽然MySQL存在Federated存储引擎，可以解决部分类似的问题，但是在实际应用场景中却很难较好地运用。那该如何来整合这些分散在各个MySQL主机上的数据源呢？总的来说，存在两种解决思路：（1）在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；（2）通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明。可能90%以上的人在面对这两种解决思路时都会倾向于选择第二种，尤其是系统不断庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内须要付出的成本可能会相对大一些，但对整个系统的扩展性来说，是非常有帮助的。所以，对于第一种解决思路就不过多分析了，下面重点分析第二种思路中的一些解决方案。1.自行开发中间代理层在决定选择通过数据库的中间代理层来解决数据源整合的架构方向之后，有不少公司（或者企业）自行开发了符合自身应用特定场景的代理层应用程序。自行开发中间代理层可以最大程度地应对自身应用的特点，最大化定制个性化需求，在面对变化的时候也可以灵活应对。这应该是自行开发代理层最大的优势了。当然，选择自行开发，享受个性化定制最大化乐趣的同时，自然也需要投入更多的成本来进行前期研发及后期的持续升级改进工作，而且本身的技术门槛可能也比简单的Web应用更高。所以，在决定选择自行开发之前，仍须要进行比较全面的评估。由于自行开发更多时候考虑的是如何更好地适应自身应用系统，应对自身的业务场景，所以这里也不好分析太多。下面将主要分析当前比较流行的几种数据源整合解决方案。2.利用MySQLProxy实现数据切分及整合MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer一样，它也是一个基于GPL开源协议的开源产品。可用来监视、分析或传输它们之间的通讯信息。它的灵活性允许最大限度地使用它，目前具备的功能主要有连接路由、Query分析、Query过滤和修改、负载均衡，以及基本的HA机制等。实际上，MySQLProxy本身并不具有上述所有的功能，而是提供了实现上述功能的基础。要实现这些功能，还须要我们自行编写LUA脚本。MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都发向MySQLProxy，然后经由MySQLProxy进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起到负载均衡的效果。如MySQLProxy基本架构图（图14-4）：图14-4MySQLProxy架构通过上面的架构简图，可以清晰地看到MySQLProxy在实际应用中所处的位置，以及能做的基本事情。MySQLProxy详细的实施细则在MySQL官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读，这里就不赘述。3.利用Amoeba实现数据切分及整合Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。目前，Amoeba已经具有Query路由、Query过滤、读写分离、负载均衡及HA机制等相关内容，如图14-5所示。Amoeba主要解决以下几个问题：（1）数据切分后复杂数据源整合；（2）提供数据切分规则并降低数据切分规则给数据库带来的影响；（3）降低数据库与客户端的连接数；（4）读写分离路由。图14-5AmoebaForMySQL架构可以看出，Amoeba所做的事情，正好就是通过数据切分来提升数据库的扩展性所需要的。Amoeba并不是一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的框架，目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。AmoebaForMySQL是专门针对MySQL数据库的解决方案，前端应用程序请求的协议及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说，AmoebaForMySQL和一个MySQL数据库没有什么区别，任何使用MySQL协议的客户端请求，都可以被AmoebaForMySQL解析并进行相应的处理。AmoebaFor可以告诉我们AmoebaForMySQL的架构信息（出自Amoeba开发者博客）：AmoebaForAladin则是一个适用更为广泛、功能更为强大的Proxy程序。它可以同时连接不同数据库的数据源为前端应用程序提供服务，但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说，只要前端应用程序通过MySQL协议连接上来，AmoebaForAladin会自动分析Query语句，根据Query语句中所请求的数据来自动识别出该Query的数据源是在什么类型数据库的哪一个物理主机上。AmoebaForAladdin架构图（图14-6）展示了AmoebaForAladin的架构细节（出自Amoeba开发者博客）。乍一看，两者好像完全一样嘛。细看才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后，根据分析结果判断出数据源数据库，然后选择特定的JDBC驱动和相应协议连接后端数据库。其实通过上面两个架构图大家可能已经发现了Amoeba的特点，它只是一个开发框架，我们除了选择它已经提供的ForMySQL和ForAladin这两款产品之外，还可以基于自身的需求进行二次开发，得到更适合自己应用特点的Proxy程序。但对于使用MySQL数据库来说，不论是AmoebaForMySQL还是AmoebaForAladin都可以很好地使用。当然，考虑到任何一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会更高一些。所以，在仅仅须要使用MySQL数据库的时候，还是建议使用AmoebaForMySQL。AmoebaForMySQL的使用非常简单，所有的配置文件都是标准的XML文件，总共有4个，分别如下：amoeba.xml——主配置文件，配置所有数据源及Amoeba自身的参数；rule.xml——配置所有Query路由规则的信息；functionMap.xml——配置用于解析Query中的函数所对应的Java实现类；rullFunctionMap.xml——配置路由规则中需要使用到的特定函数的实现类。图14-6AmoebaForAladdin架构如果您的规则不是太复杂，基本上仅使用上面4个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离、负载均衡等配置都在amoeba.xml中进行。此外，Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由，路由规则可以在rule.xml进行设置。目前Amoeba稍有欠缺的主要就是其在线管理功能及对事务的支持方面了，曾经在与相关开发者的沟通过程中提出过这方面的建议，希望能够提供一个可以进行在线维护管理的命令行管理工具，方便在线维护使用，得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面Amoeba暂时还无法做到，即使客户端应用在提交给Amoeba的请求时包含事务信息的，Amoeba也会忽略事务相关信息。当然，在经过不断完善之后，我相信事务支持肯定是Amoeba重点考虑的功能。关于Amoeba更为详细的使用方法读者可以通过Amoeba开发者博客（）上面提供的使用手册获取，这里就不再细述了。4.利用HiveDB实现数据切分及整合和前面的MySQLProxy及Amoeba一样，HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异，它并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现数据切分工作。在HiveDB中，通过用户自定义的各种Partitionkeys（即制定数据切分规则），将数据分散到多个MySQLServer中。访问时运行Query请求，则会自动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给客户端应用程序。单纯从功能方面来讲，HiveDB可能并不如MySQLProxy和Amoeba那样强大，但是其数据切分的思路与前面二者并无本质差异。此外，HiveDB并不只是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。HiveDB官方网站上的HiveDB架构示意图（图14-7），描述了HiveDB如何来组织数据的基本信息，虽然不能详细地表现出架构方面的信息，但是也基本可以展示其在数据切分上独特的一面了。图14-7HiveDB架构示意5.其他实现数据切分及整合的解决方案除了上面介绍的几个数据切分及整合的整体解决方案之外，还存在很多其他的解决方案、如在MySQLProxy的基础上做进一步扩展的HSCALE，通过Rails构建的SpockProxy，以及基于Pathon的Pyshards，等等。不管大家选择使用哪一种解决方案，总体设计思路基本上都不应该有任何变化，即通过数据的垂直和水平切分，增强数据库的整体服务能力，让应用系统的整体扩展能力尽量得到提升，扩展方式尽可能便捷。只要通过中间层Proxy应用程序较好地解决了数据切分和数据源整合问题，那么数据库的线性扩展能力将像应用程序一样方便：只要通过添加廉价的PCServer服务器，即可线性增加数据库集群的整体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。