Sharding

  1. 背景

数据库的扩展是一个永恒的话题。对于传统的关系数据库，采用的是纵向扩展（ScaleUp）的方式，即买更好的机器添加更多的资源来取得更好的性能（如硬件升级、更快更多的CPU、更大的内存、更多更大的磁盘等）。而形式上采用的是并行数据库、分布式数据库的模式，具体细 节依赖水平分区或者垂直分区的技术。关系数据库通过ScaleUp方式已在传统的企业应用环境中统治了将近三十多年。

但是近年来随着数据量的暴增尤其是云计算模式的出现，这种扩展模式对于某些应用已经不太适合，这时便出现了横向扩展 （Scale Out）模式。这种方式采用一些Ad-hoc的技术，比如说对数据库进行主从配置（Master-Slave）、采用数据库复制 （Replication）技术以及服务器的缓存（Server Cache）等，来将负载分布到多个物理节点上去。另外sharding技术也逐步发展，并在近年来吸引了众人的眼球。

2. 什么是Sharding

Sharding 是把数据库Scale Out到多个物理节点上的一种有效的方式。Shard这个词的意思是“碎片”。如果将一个数据库当作一块大玻璃，将这块玻璃打碎，那么每一小块都称为数据 库的碎片（DatabaseShard）。将整个数据库打碎的过程就叫做sharding，可以翻译为分片。

形式上，Sharding可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部 分，称为一个shard，分区方式可以是任意的，并不局限于传统的水平分区和垂直分区。一个shard可以包含多个表的内容甚至可以包含多个数据库实例中 的内容。 每个shard被放置在一个数据库服务器上。一个数据库服务器可以处理一个或多个shard的数据。系统中需要有服务器进行查询路由转发，负责将查询转发 到包含该查询所访问数据的shard或shards节点上去执行。

 

3.常用的sharding方案

    1。按功能划分（垂直切分）

将不同功能相关的表放到不同的数据库中，譬如将用户管理相关表放到shard1上，将blog相关表放到shard 2上。。。这样做的好处是非常直观，当需要用户列表时，我就到shard 1上获取。。。。这样也有一个问题，当某一部分的功能其数据量或性能要求超出了可控的范围，我们就需要继续对其进行深入的sharding。

    2。按表中某一字段值的范围划分（水平切分）

当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对她进行进一步的切分。一种选择是根据key的范围来 做切分，譬如userID为1-10000的放到shard 10上，userID为10000到20000的放到shanrd11上。。。这样的扩展就是可预见的。另一种是根据某一字段值得来划分，譬如根据用户名 的首字母，如果是a-d，就属于shard 20，e-h就属于shard21。。。这样做也存在不均衡性，当某个范围超出了shard所能承受的范围就需要继续切分。还有按日期切分等等，

    3。基于hash的切分

类似于memcached的keyhash算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台 shard。这种方法能够平均的来分配数据，但是伴随着数据量的增大，需要进 行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash算法重新运算，数据需要重新割接。

    4。基于路由表的切分

前面的几种方式都是跟据应用的数据来决定操作的shard，基于路由表的切分是一种更加松散的方法。它单独维护一张路由 表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。譬如我们在系统中维护一张表-（用户所属省-〉 shard），这样每个用户我们知道是哪个省的，去路由表查找，就知道它所在的shard。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容 存储到一台独立cache上是一个非常好的方 式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用程序的架构设计相关，你的设计必须适用这种增加。

4. Sharding与分区的比较

Sharding与分区有着千丝万缕的联系，它们所采取的技术本质上是类似的，可以说sharding的概念就是由分区 而来。在某些情况下sharding可能指的就是水平分区。另外有些文档中使用了fragment（也是碎片的意思）的术语（在并行数据库中的这些分区称 为 partition，在分布式数据库中则称为fragment）。但是我们所说的sharding和分区还是有很大区别的。下面罗列一下：

（1）扩展方式不同。Sharding属于scaleout，而分区则属于scale up方式。

（2）目的不同。分区的目的是为了将一个查询进行并行处理，这样所有的节点能并行处理一个查询；而sharding是让每个节点尽量处理不同的查询。

（3）应用场景：分区适用与传统的企业应用，尤其是OLAP的应用，基本上每个查询都需要访问大部分的数据；而sharding适用于云Web应用，特征是有大量的用户和查询，但是每个查询访问到的元组是非常少的，sharding可以将负载分散到多个物理节点上。

（4）可用性：对于分布式数据库基本上每个查询都需要所有的节点参与，如果某些节点down掉后，系统会大受影响；而 sharding所处理的应用一般只涉及到少数几个节点，所以可用性上sharding要好一些。另外分布式数据库需要有一个主节点来生成执行计划并协调 相关节点执行等，很容易形成单点瓶颈。

（5）分割粒度：分区一般只针对于一个数据库内部进行分割；而sharding可以以数据库为粒度进行分割，因此可用来构建多租房数据库系统（multi-tenantdatabase）。的确，Sharding 的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库，甚至跨越物理机器的。（见对比表格）

5.Sharding的优点

对于Sharding来说，主要有以下主要的优点：

（1）提高了数据库的可扩展性，可以随着应用的增长来增加更多的服务器，只需要将新增加的数据以及负载放到新加的服务器上就可以。

（2）提高了数据库的可用性。其中几个shard服务器down掉之后，并不会使整个系统对外停止服务，而只会影响到需要访问这几个shard服务器上的数据的用户。

（3）小的数据库的查询压力比较小，查询更快，性能更好。

（4）系统有更好的可管理性。对系统的升级和配置可以按照shard一个一个来做，并不会对服务产生大的影响。

6.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 达到了预期效果。

7.现有的 Sharding 软件简介

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

MySQLProxy + HSCALE

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

Hibernate Shards

这是 Google 技术团队贡献的项目 （http://www.hibernate.org /414.html），该项目是在对 Google 财务系统数据Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能搞定，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。

SpockProxy

这也是在实际需求中产生的一个开源项目。Spock （http://www.spock.com/）是一个人员查找的 Web 2.0 网站。通过对自己的单一DB 进行有效 Sharding化 而产生了Spock Proxy(http://spockproxy.sourceforge.net/) 项目，Spock Proxy 算得上 MySQLProxy 的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以SpockProxy 也是基于 Rails 构建，关注 RoR 的朋友不应错过这个项目。

HiveDB

上面介绍了 RoR 的实现，HiveDB (http://www.hivedb.org/)则是基于Java 的实现，另外，稍有不同的是，这个项目背后有商业公司支持。

PL/Proxy

前面几个都是针对 MySQL 的 Sharding 方案，PL/Proxy 则是针对 PostgreSQL 的，设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发。 PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy服务器即可。大名鼎鼎的Skype 用的就是 PL/Proxy 的解决方案。

Pyshards

http://code.google.com/p/pyshards/wiki/Pyshards 这是个基于 Python的解决方案。该工具的设计目标还有个Re-balancing 在里面，这倒是个比较激进的想法。目前只支持 MySQL 数据库。