一种非常规的数据库设计方法：Sharding - shawnliu

公告

Sharding ==Horizontal Partitioning

当你剥离了用于装扮Sharding的许多美妙的修饰之后，你会发现Sharding并不是什么新的或高深的东西，它几乎等同于我们常说的Horizontal Partitioning(水平切分)。我们可以认为他们就是同一个概念，毕竟两个术语都没有确定的严格定义，区分反而容易把我们绕晕了。

Sharding是一个非常规的DB设计方法
那么正统的方法是什么？我们平常规规矩矩用的基本都是。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。这时候replication可能会成为鸡肋了。

Replication搞不定，那么为什么Sharding可以work呢？道理很简单，因为它可以很好的scale。我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向Scale, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。

如何Sharding?

这里可以借鉴MySql partition设计的思想。MySql partition可以算是物理存储层面的sharding了，在某些场景可能适合，但是自身有明显的缺点，虽然我们可以把数据库存储放到SAN等存储网络上，但是还是受到单台机器计算能力等限制。业界更多的是考虑根据自身的业务逻辑来进行手工切分，这样效果可能更好，可以进行细腻度的控制。切分尽量做到每个分片(Shards)都能够很好的独立，彼此之间交互要尽量少，使得一个请求尽量通过一个分片中就能提供服务。

你可以根据一个KEY或范围来进行切分，这些key往往是一个确定的小的集合体。例如大众点评网可以考虑将它每个大的城市的数据放在一个单独的数据库里，而一些小城市可以根据某些规则放在一个数据库里。这里的思想和我在做一个Lucene索引时碰到的问题很相似。这里用Lucene实际上算是数据库文本匹配查询的一个拓展模块。当时有大概七八百万条数据要做index,如果做在一个目录下面，查询性能和index速度都很有问题。我就考虑让每个城市的索引结果放在单独的目录下，最后我的index速度基本上可以达到每秒一千左右个文档了，也可容易地扩展成分布式的搜索。还遇到一个地图的应用，我以前也大概谈到过这次切分<<.Net架构网站遇到大表该怎么办？ >>，在这个应用里我是根据数据的经纬度坐标范围的物理空间特性来进行切分的，主要切分的区域是砍掉了中国地图的鸡头鸡尾几个部分后剩下的区域，对这里面的区域进行了进一步细分，像上海，北京，深圳几个地方进行更深层次的切分，这样切分以后我就可以像平常操作基本表那样来动这个大表了。切分过后大部分应用的请求也仅仅会涉及到一个表，边界条件或者其它业务需求才会并发的操作多个表。还可能有些应用你可以通过日期来切分，例如07，08年的每年的订单分拆成单独的数据库。更牛的可能用个hash函数，思想也很容易理解，不过选择好的hash函数倒是不大容易，你要想办法把数据划分均匀了，具体可能还有很多的细节需要考虑。特别是对于某个shard过载如何进一步对他进行切分，但又不违反已有的规则等等。