MySQL 分表分数据库服务器的一种方案HSCALE, 基于MySQL proxy

 

在大型的应用中,我们经常碰到MySQL的表数据需要无限扩充的情形。我们通常有以下一些解决方案,但是现成的方案都不是完美的。

比如,
MySQL master/slave: 只适合大量读的情形,未必适合海量数据。
MySQL cluster: 提供的可能不是大家想要那种功能。
MySQL proxy: MySQL master/slave配合
MySQL 5.1 partition: 只是将一个表存储上逻辑分开,部分改善了性能,但是可扩展性仍然是问题。
MySQL 按应用逻辑分表和分数据库,通过程序来决定数据存放的表,目前很多公司都是这么做的。它的主要问题是跨区查询,可参考Tim以前的文章MySQL分表实现上百万上千万记录分布存储的批量查询设计模式

使用程序来分表分服务器最大的问题是比较繁琐,需要程序做很多特殊处理,需要程序员了解数据存放在哪个服务器哪个表,这样,几乎所有的程序员都牵涉了进来, 也容易出错。那如果我们把分表的逻辑放到中间层则上层的应用就简单很多,而且可以单点控制分表的逻辑,方便调整与扩展。

  • HSCALE分表分数据库的思路


    HSCALE就是这样一个产品,它是在MySQL proxy的 基础上,在MySQL proxy的层面将上层的请求分配到实际的表上。实际的原理是通过拦截SQL进行替换和服务器重定向再将SQL传递到目标服务器上。它的分表算法可以由自定义的Lua脚本来实现,非常灵活。目前已经能支持同数据库分表,跨数据库的实现也将增加,因为在MySQL proxy的框架下,这并不是很困难的事情。现在的版本或许不是很成熟,但是在原理上我觉得是基本上没多大障碍,发展下去将是一个不错的选择。

    HSCALE具体的性能测试简单介绍如下。
    • 测试
    使 用HSCALE有2个开销,一是网络层面的,下面的测试环境大约MySQL proxy对每个SQL会增加0.02ms的网络延迟,如果增加了HSCALE, 则会增加到0.3ms,第2个开销则是MySQL proxy, Lua, SQL解析,HSCALE算法等造成,可看下面数据。

    (图片来源:pero.blogs.aprilmayjune.org)

    结论是最极端的情况下,在10个线程的情况下,使用MySQL proxy会需要大约3倍时间,HSCALE则是10倍。
    注意结论是MySQL方面最优化的情况,查找一个三条记录的表。在实际环境中的latency和这个没有直接比例关系(比如1:3)。测试结果不太令人满意,幸好后面新版本MySQL proxy的测试数据得到了改善。

    使用了MySQL proxy 的 svn版本,性能提升很大。MySQL/MySQL proxy从1:3提升到1:2, HSCALE同样也提升比较大。具体结果见连接。但是仍然迫切希望作者再有提升。

    今天说到大部分技术Blog都以介绍国外技术与产品的文章为主,没有深度,当然我这篇也不例外。:)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值