MySQL: 开源数据库Sharding技术

核心提示： Sharding 策略 数据 Sharding 的策略与分区表的方式有很多类似的地方，有基于表、ID 范围、数据产生的时间或是SOA 下理念下的基于服务等众多方式可选择，MySQL: 开源数据库Sharding技术(3)，而与传统的表分区方式不同的是，Sharding 策略和业务结合的更为

Sharding 策略

数据 Sharding 的策略与分区表的方式有很多类似的地方，有基于表、ID 范围、数据产生的时间或是SOA 下理念下的基于服务等众多方式可选择。而与传统的表分区方式不同的是，Sharding 策略和业务结合的更为紧密，成功的 Sharding 必须对自己的业务足够熟悉，进行众多可行性分析的基础上进行，"业务逻辑驱动"。

Sharding 实现案例分析：Digg 网站

作为风头正劲的 Web 2.0 网站之一的 Digg.com，虽然用户群庞大，但网站数据库数据并非海量，去年同期主数据大约只有 30GB 的样子，现在应该更大一些，但应该不会出现数量级上增长，数据库软件采用 MySQL 5.x。Digg.com的 IO 压力非常大，而且是读集中的应用(98%的 IO 是读请求)。因为提供的是新闻类服务，这类数据有其自身特点，最近时间段的数据往往是读压力最大的部分。

根据业务特点，Digg.com 根据时间范围对主要的业务数据做 Sharding，把不到 10% 的"热"数据有效隔离开来，同时对这部分数据用以更好的硬件，提供更好的用户体验。而另外 90% 的数据因用户很少访问，所以尽管访问速度稍慢一点，对用户来说，影响也很小。通过 Sharding，Digg 达到了预期效果。

现有的 Sharding 软件简介

现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，作一下简要的介绍。

MySQL Proxy + HSCALE

一套比较有潜力的方案。其中 MySQL Proxy (http://forge.mysql.com/wiki/MySQL_Proxy) 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy 的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用 Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE 各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。