第 14 章 可扩展性设计之数据切分前言 通过 MySQL Replication 功能所实现的扩展总是会受到数据库大小的限制,一旦数据库过于庞大,尤其是当写入过于频繁,很难由一台主机支撑的时候,我们还是会面临到扩展瓶颈。这时候,我们就必须许找其他技术手段来解决这个瓶颈,那就是我 ...
第 14 章 可扩展性设计之数据切分
前言 通过 MySQL Replication 功能所实现的扩展总是会受到数据库大小的限制,一旦数据库过于庞大,尤其是当写入过于频繁,很难由一台主机支撑的时候,我们还是会面临到扩展瓶颈。这时候,我们就必须许找其他技术手段来解决这个瓶颈,那就是我们这一章所要介绍恶的数据切分技术。
14.1 何谓数据切分
可能很多读者朋友在网上或者杂志上面都已经多次见到关于数据切分的相关文章了,只不过在有些文章中称之为数据的 Sharding。其实不管是称之为数据的 Sharding 还是数据的切分,其概念都是一样的。简单来说,就是指通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面,以达到分散单台设备负载的效果。数据的切分同时还可以提高系统的总体可用性,因为单台设备 Crash 之后,只有总体数据的某部分不可用,而不是所有的数据。 14.2 数据的垂直切分
我们先来看一下,数据的垂直切分到底是如何一个切分法的。数据的垂直切分,也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成,我们垂直的将这些“数据块”切开,然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。 当然,很难有系统能够做到所有功能模块所使用的表完全独立,完全不需要访问对方的表或者需要两个模块的表进行 Join 操作。这种情况下,我们就必须根据实际的应用场景进行评估权衡。决定是迁就应用程序将需要 Join 的表的相关某快都存放在同一个数据库中, 还是让应用程序做更多的事情,也就是程序完全通过模块接口取得不同数据库中的数据,然后在程序中完成 Join 操作。 1. 用户模块表:user,user_profile,user_group,user_photo_album ◆ 相册模块仅仅与用户模块存在通过用户的关联。这两个模块之间的关联基本就有通过用户 id 关联的内容,简单清晰,接口明确; ◆ 事件模块与各个模块可能都有关联,但是都只关注其各个模块中对象的ID信息, 同样可以做到很容易分拆。 所以,我们第一步可以将数据库按照功能模块相关的表进行一次垂直拆分,每个模块所涉及的表单独到一个数据库中,模块与模块之间的表关联都在应用系统端通过藉口来处理。 如下图所示:
通过这样的垂直切分之后,之前只能通过一个数据库来提供的服务,就被分拆成四个数据库来提供服务,服务能力自然是增加几倍了。 可能在某些操作的单次响应时间会稍有增加,但是系统的整体性能很可能反而会有一定的提升。而扩展瓶颈问题,就只能依靠下一节将要介绍的数据水平切分架构来解决了。 14.3 数据的水平切分
上面一节分析介绍了数据的垂直切分,这一节再分析一下数据的水平切分。数据的垂直切分基本上可以简单的理解为按照表按照模块来切分数据,而水平切分就不再是按照表或者是功能模块来切分了。一般来说,简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。 如根据某个数字类型字段基于特定数目取模,某个时间类型字段的范围,或者是某个字符类型字段的 hash 值。如果整个系统中大部分核心表都可以通过某个字段来进行关联,那这个字段自然是一个进行水平分区的上上之选了,当然,非常特殊无法使用就只能另选其他了。 切分之后基本上不会出现各个库之间的交互。 水平切分的优点 14.4 垂直与水平联合切分的使用在这一节中,我将结合垂直切分和水平切分各自的优缺点,进一步完善我们的整体架构, 让系统的扩展性进一步提高。 实际上,在很多大型的应用系统中,垂直切分和水平切这两种数据的切分方法基本上都是并存的,而且经常在不断的交替进行,以不断的增加系统的扩展能力。我们在应对不同的应用场景的时候,也需要充分考虑到这两种切分方法各自的局限,以及各自的优势,在不同的时期(负载压力)使用不同的结合方式。 联合切分的优点 14.5 数据切分及整合方案
通过前面的章节,我们已经很清楚了通过数据库的数据切分可以极大的提高系统的扩展性。但是,数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是如何来让这些数据源得到较好的整合,可能这也是很多读者朋友非常关心的一个问题。这一节我们主要针对的内容就是分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。 1. 在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,直接访问各个数据库,在模块内完成数据的整合; 当然,选择自行开发,享受让个性化定制最大化的乐趣的同时,自然也需要投入更多的成本来进行前期研发以及后期的持续升级改进工作,而且本身的技术门槛可能也比简单的Web 应用要更高一些。所以,在决定选择自行开发之前,还是需要进行比较全面的评估为好。 通过上面的架构简图,我们可以很清晰的看出 MySQL Proxy 在实际应用中所处的位置, 以及能做的基本事情。关于 MySQL Proxy 更为详细的实施细则在 MySQL 官方文档中有非常详细的介绍和示例,感兴趣的读者朋友可以直接从 MySQL 官方网站免费下载或者在线阅读,我这里就不累述浪费纸张了。
★ 利用 Amoeba 实现数据切分及整合 Amoeba 并不是一个代理层的 Proxy 程序,而是一个开发数据库代理层 Proxy 程序的开发框架,目前基于 Amoeba 所开发的 Proxy 程序有 Amoeba For MySQL 和 Amoeba For Aladin 两个。 Amoeba For Aladin 则是一个适用更为广泛,功能更为强大的 Proxy 程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务,但是仅仅接受符合 MySQL 协议的客户端应用程序请求。也就是说,只要前端应用程序通过 MySQL 协议连接上来之后,Amoeba For Aladin 会自动分析 Query 语句,根据 Query 语句中所请求的数据来自动识别出该所Query 的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了 Amoeba For Aladin 的架构细节(出自 Amoeba 开发者博客):
咋一看,两者好像完全一样嘛。细看之后,才会发现两者主要的区别仅在于通过 MySQL Protocal Adapter处理之后,根据分析结果判断出数据源数据库,然后选择特定的 JDBC 驱动和相应协议连接后端数据库。其实通过上面两个架构图大家可能也已经发现了 Amoeba 的特点了,他仅仅只是一个开发框架,我们除了选择他已经提供的 For MySQL 和 For Aladin 这两款产品之外,还可以基于自身的需求进行相应的二次开发,得到更适应我们自己应用特点的 Proxy 程序。 主要解决大数据量下数据库的扩展性及数据的高性能访问问题,同时支持数据的冗余及基本的 HA 机制。 在 HiveDB 中,通过用户自定义的各种 Partition keys(其实就是制定数据切分规则), 将数据分散到多个 MyServer.aspx' target='_blank'>SQL Server 中。在访问的时候,在运行 Query 请求的时候,会自动分析过滤条件,并行从多个 MySQL Server 中读取数据,并合并结果集返回给客户端应用程序。 14.6 数据切分与整合中可能存在的问题
这里,大家应该对数据切分与整合的实施有了一定的认识了,或许很多读者朋友都已经根据各种解决方案各自特性的优劣基本选定了适合于自己应用场景的方案,后面的工作主要就是实施准备了。 14.7 小结
通过数据切分技术将一个大的 MySQL Server 切分成多个小的 MySQL Server,既解决了写入性能瓶颈问题,同时也再一次提升了整个数据库集群的扩展性。不论是通过垂直切分,还是水平切分,都能够让系统遇到瓶颈的可能性更小。尤其是当我们使用垂直和水平相结合的切分方法之后,理论上将不会再遇到扩展瓶颈了。
摘自:《MySQL性能调优与架构设计》简朝阳
转载请注明出处:
作者:JesseLZJ
原标题:MySQL性能调优与架构设计——第 14 章 可扩展性设计之数据切分
关键词:MYSQL
*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们:
admin#shaoqun.com
(#换成@)。