数据切分及整合方案
我们已经非常清晰了通过数据库的数据切分能够极大的提高系统的扩展性, 可是数据库中的数据在经过垂直和 (或) 水平切分被存放在不同的数据库主机之后, 应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合.
数据的整合非常难依靠数据库本身来达到这个效果, 尽管 MySQL 存在 Federated 存储引擎, 能够解决部分相似的问题. 可是在实际应用场景中却非常难较好的运用. 那我们该怎样来整合这些分散在各个 MySQL 主机上面的数据源呢?
总的来说, 存在两种解决思路:
在每一个应用程序模块中配置管理自己须要的一个 (或者多个) 数据源. 直接访问各个数据库, 在模块内完毕数据的整合;
通过中间代理层来统一管理全部的数据源. 后端数据库集群对前端应用程序透明;
可能 90% 以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种, 尤其是系统不断变得庞大复杂的时候, 尽管短期内须要付出的成本可能会相对更大一些, 可是对整个系统的扩展性来说, 是非常有帮助的. 所以, 对于第一种解决思路我这里就不准备过多的分析, 以下我重点分析一下在另外一种解决思路中的一些解决方式.
自行开发中间代理层
通过自行开发中间代理层能够最大程度的应对自身应用的特点, 最大化的定制非常多个性化需求, 在面对变化的时候也能够灵活的应对. 当然, 选择自行开发享受让个性化定制最大化的乐趣的同一时候, 自然也须要投入很多其它的成本来进行前期研发以及后期的持续升级改进工作, 并且本身的技术门槛可能也比简单的 web 应用要更高一些.
利用 MySQLProxy 实现数据切分及整合
基于 MySQLProxy 自行编写 LUA 脚本实现数据切分相关代理功能.
利用 Amoeba 实现数据切分及整合
Amoeba 是一个基于 Java 开发的, 专注于解决分布式数据库数据源整合 Proxy 程序的开源框架, 基于 GPL3 开源协议. 眼下 Amoeba 已经具有 Query 路由, Query 过滤, 读写分离, 负载均衡以及 HA 机制等相关内容.
Amoeba 主要解决的以下几个问题:
数据切分后复杂数据源整合;
提供数据切分规则并降低数据切分规则给数据库带来的影响.
降低数据库与 client 的连接数.
读写分离路由;
我们能够看出, 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, 就可以线性添加数据库集群的总体服务能力, 让数据库不再轻易成为应用系统的性能瓶颈.
来源: http://www.jianshu.com/p/d4b90fd95ec9