From : http://eddysheng.iteye.com/blog/461393
From : http://www.elecfans.com/news/wangluo/20120215260321.html
sharding是将一个大数据库按照一定规则拆分成多个小数据库的一门技术.
当我们的应用数据量越来越多，访问量越来越大的时候，我们会作何选择？继续提升数据库服务器的性能还是采用一项技术让数据库平滑扩展？虽然伴随着服务器的更新换代，性能越来越好，更换更加豪华的服务器能暂时解决这个问题，但是无论是从花费和可控都无法让人满意。这时数据库sharding是一个更加可行的方案。
常用的sharding方案有以下几种，
1。按功能划分（垂直切分）
将不同功能相关的表放到不同的数据库中，譬如将用户管理相关表放到shard 1上，将blog相关表放到shard 2上。。。这样做的好处是非常直观，当需要用户列表时，我就到shard 1上获取。。。。这样也有一个问题，当某一部分的功能其数据量或性能要求超出了可控的范围，我们就需要继续对其进行深入的sharding。
2。按表中某一字段值的范围划分（水平切分）
当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对她进行进一步的切分。一种选择是根据key的范围来做切分，譬如userID为1-10000的放到shard 10上，userID为10000到20000的放到shanrd 11上。。。这样的扩展就是可预见的。另一种是根据某一字段值得来划分，譬如根据用户名的首字母，如果是a-d，就属于shard 20，e-h就属于shard 21。。。这样做也存在不均衡性，当某个范围超出了shard所能承受的范围就需要继续切分。还有按日期切分等等，
3。基于hash的切分
类似于memcached的key hash算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台shard。这种方法能够平均的来分配数据，但是伴随着数据量的增大，需要进行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash算法重新运算，数据需要重新割接。
4。基于路由表的切分
前面的几种方式都是跟据应用的数据来决定操作的shard，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。譬如我们在系统中维护一张表-（用户所属省-〉shard），这样每个用户我们知道是哪个省的，去路由表查找，就知道它所在的shard。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用程序的架构设计相关，你的设计必须适用这种增加。
虽然应用sharding会带来显而易见的好处，但是它也有一些固有的问题需要我们了解，这些问题大致分成以下几类，
1。shard的扩容
当当前的shard已经不能适用当前的应用需求时，就需要对shard数据库进行扩容，增加shard意味着需要对原有的shard数据进行迁移，这个过程是非常复杂，而且可能会导致数据的不一致（一边写、一边迁移）或者其他应用问题，因此扩容一般选择在凌晨等时间进行。
2。联合多个shard的表数据查询
这个是shard固有的问题，当遇到这样的问题时，你需要获取各个shard的数据，然后对这些数据进行汇总，很多时候因为现在的网络速度比较发达这个问题可以几乎被忽略掉。但是如果要进行数据的分析或挖掘，shard就会存在问题，通常面对这种对于数据要求不是那么实时的情况下，可以采用将shard数据同步到汇总数据库的方案，olap可以在这台汇总数据库上进行，这就需要在每台shard上进行数据的定时同步，这增加了程序的复杂性；如果要求实时的情况下，采用sharding方案会是一个毁灭性打击。
3。其他
我们现在做的系统就是采用的按照路由表切分的sharding方案，而且我们需要要求不是那么实时的汇总数据以提供数据的分析和挖掘，同时我们的基础数据都是在汇总数据库中进行管理，通过oracle的高级复制到shard节点上。在shard数据库向汇总数据库同步数据的时候，我们是通过oracle数据库的存储过程实现的，这种架构方式导致了数据库非常的复杂，同时还存在了一些其他问题，譬如同步会无缘无故的断掉。。。这就需要采用一些其他手段来维持数据的延迟一致性。
我们的sharding还在改进，我们的shard还在增加，我们还需要不断努力使我们的应用更加高效。
有时候觉得我们的社会就像一个巨大的多层sharding方案，中央、省（自治区）、市。。。
-------------------------------------------------------------
还有一种数据库方案是master-slave，一台master主要负责数据的更新，然后通过高级复制等手段将数据复制到各个slave节点，slave节点负责查询。这种结构是不管master和slave都拥有全部的数据，master到slave的数据存在一定的延迟。可以跟sharding方案结合使用。
数据库的sharding技术作为一个“新瓶装旧酒”的概念，在新的应用环境中被赋予了新的意义。随着云计算的发展，sharding在最近几年是越来越火热，越来越多的产品开始声称自己支持sharding功能。那么到底什么是sharding，sharding到底能为你的数据库应用带来哪些好处。另外最重要的，如何实现一个sharding系统，有哪些sharding算法可供选择。本文将为你解决这些问题。
一. 简介
1. 背景
数据库的扩展是一个永恒的话题。对于传统的关系数据库，采用的是纵向扩展(Scale Up)的方式，即买更好的机器添加更多的资源来取得更好的性能(如硬件升级、更快更多的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与分区的比较
Sharding与分区有着千丝万缕的联系，它们所采取的技术本质上是类似的，可以说sharding的概念就是由分区而来。在某些情况下sharding可能指的就是水平分区。另外有些文档中使用了fragment(也是碎片的意思)的术语(在并行数据库中的这些分区称为partition，在分布式数据库中则称为fragment)。\ref footnote 1
Foot note 1:
[[
Daniel C. Zilio. Physical Database Design Decision Algorithms and ConcurrentReorganization for Parallel Database Systems. PhD thesis 1997.
M. Tamer Özsu, Patrick Valduriez. Principles ofDistributed Database Systems, Third Edition. Springer. 2011
]]
但是我们所说的sharding和分区还是有很大区别的。下面罗列一下：
(1)扩展方式不同。Sharding属于scaleout，而分区则属于scale up方式。
(2)目的不同。分区的目的是为了将一个查询进行并行处理，这样所有的节点能并行处理一个查询;而sharding是让每个节点尽量处理不同的查询。
(3)应用场景：分区适用与传统的企业应用，尤其是OLAP的应用，基本上每个查询都需要访问大部分的数据;而sharding适用于云Web应用，特征是有大量的用户和查询，但是每个查询访问到的元组是非常少的，sharding可以将负载分散到多个物理节点上。
(4)可用性：对于分布式数据库基本上每个查询都需要所有的节点参与，如果某些节点down掉后，系统会大受影响;而sharding所处理的应用一般只涉及到少数几个节点，所以可用性上sharding要好一些。另外分布式数据库需要有一个主节点来生成执行计划并协调相关节点执行等，很容易形成单点瓶颈。
(5)分割粒度：分区一般只针对于一个数据库内部进行分割;而sharding可以以数据库为粒度进行分割，因此可用来构建多租房数据库系统(multi-tenantdatabase)。
4.Sharding的优点
对于Sharding来说，主要有以下主要的优点：
(1)提高了数据库的可扩展性，可以随着应用的增长来增加更多的服务器，只需要将新增加的数据以及负载放到新加的服务器上就可以。
(2)提高了数据库的可用性。其中几个shard服务器down掉之后，并不会使整个系统对外停止服务，而只会影响到需要访问这几个shard服务器上的数据的用户。
(3)小的数据库的查询压力比较小，查询更快，性能更好。
(4)系统有更好的可管理性。对系统的升级和配置可以按照shard一个一个来做，并不会对服务产生大的影响。