大家好，给大家介绍一下，这是我男神@VAGE

吕海波

国内知名数据库技术专家、数据架构师

曾任阿里/京东/ebay高级专家、首席DBA 

Oracle传奇技术大师

ITPUB Oracle 管理版版主

噔噔噔，吕大主笔数据库系列文章——《数据库传奇》，从数据库选型例子入手，介绍SQL和NoSQL数据库的特点，把所有数据库的特性、适用范围，加上一些业内故事、传说，写上一遍。

本着“一般不出手，出手就是大作”的原则，文章更新不定期。本期推出《数据库传奇》第一章：Digg启示录----你选对数据库了吗？

未来的世界是属于数据的，而数据则存储在数据库中。数据库，无疑是企业所有应用的基石。数据库种类有很多，你选对数据库了吗？

美国有一家互联网公司，Digg。创办于2004年，又叫掘客，就是个新闻网站，但不同于传统的新闻门户，Digg根据用户的行为（差不多就是评论、点赞之类的），决定那些新闻显示在首页。这在当年叫做Web2.0，由用户决定显示什么东西，火的不得了。

它开创了Web2.0概念，首创“用户创造内容”先河，在美国互联网公司中，曾一度排名第24位，其地位相当于中国的知乎和豆瓣。Google曾想花5亿美元收购它，但被其创始人拒绝。

Digg之前一直在使用MySQL数据库，直到遇到了这个人

约翰·奎恩（John Quinn），曾在Oracle但任工程师，是数据库老鸟一枚。

2010年时，Digg发展一路高歌猛进，相应的，数据库的压力，自然也是高歌猛进。

数据库压力大，怎么破？

现在地球人都知道，分库分表啊。

纠正一下，“分库分表”其实不是学术上的叫法，专业术语叫“数据分区”，也就是Partition。不过，咱们也不是要讨论特理论的学术问题，什么CAP之类的。咱们还是沿用“分库分表”的叫法。

分库分表可不是你说想分就分的，涉及应用改造、一致性、数据同步等等一系列复杂无比的问题。

业内第一家分库分表的公司，是美国电商ebay。ebay的架构师早在2003年，率先提出了分库分表的方案，并成功实施。

不过，要说影响力最大的，还是阿里巴巴。

阿里巴巴利用分库分表技术，实现了超大规模分布式数据库，将绝大部分数据移到了开源的MySQL，或自研的OceanBase（当然，仍有少量关键数据在Oracle）。并且多年来成功应对超高并发的“双十一”，让美国同行都为之惊讶不已。其推出的名词“去IOE”，甚至上了央视某新闻频道。

所以从影响力上说，阿里巴巴让分库分表成为了专有名词，牛。

转过头再说约翰·奎恩。2010年初，奎恩此时已经在Digg高居VP（副总裁），并刚刚担任CTO不久。Digg的数据层解决方案，使用的是MySQL，本来也是分库分表的，只是分的不彻底，面对数据库压力逐步增大的情况，需要进一步的、更加彻底的分库分表，这就要求对应用进行大范围的改造。

2010年，彼时国内NoSQL如清风拂面，但在太平洋对面的美国西海岸，世界第一大湾区——旧金山湾，美国的高科技产业聚集地，也就是硅谷，NoSQL已如飓风般摧枯拉朽。

奎恩显然没有经受住飓风的吹拂。

2010年初，圣诞节的假期刚结束，Digg的员工意犹未尽地回到工作岗位，去MySQL换Cassandra的工作就正式开始了。

Digg并不是第一家尝试Cassandra的公司。Cassandra，作为当年炙手可热的NoSQL数据库，诞生自社交巨头FaceBook，而后另一个社交巨头Twitter也采用了Cassandra。当年可谓是最成功的NoSQL数据库。

有别人家的成功经验，再加上自家数据库团队的充分测试，奎恩终于决定动手了。

根据数据库团队的测试结果，Cassandra性能更快，而且扩容更加方便。

打动奎恩的，正是扩容方便。

比如，有一个集群中有20台主机，现在由于性能不足，需要扩展到30台。基于MySQL的分布式当然也可以扩容，但每次扩容都是伤筋动骨的大动作，搞的数据库团队人困马乏。

相比之下，性能表现更加出色的Cassandra，扩容是非常方便的。有了这个特性，数据库压力增大多少，就扩多少台主机，甚至还可以减少压力不高集群的主机数量，这才是真正的动态扩展啊。

有了Cassandra，工作更轻松。

为什么MySQL的分布式扩容复杂，而NoSQL的Cassandra分布式扩容就简单呢？这个问题并不容易回答，我抖胆为大家解读一下。（以下满满都是干货）

这个问题，是公众认为“NoSQL是分布式、SQL型数据库不是分布式”的重要原因之一。

分布式，最关键的部件是“路由”，它相当于“传达室”。

假如这家单位有100间办公室，你要找老张，但你并不知道老张在哪儿，你先到传达室问了一下：“同志，老张在那个办公室”。

传达室告诉你，“老张在二楼左边第二个办公室。”然后，你去找老张办事。

这里，传达室就是一个“路由”，或叫做“转发器”。他并不能为你办事，他只是告诉你，你要找的人在哪儿。

分布式数据库中的路由部件同样，它不能执行你的操作，他只是告诉你，你要操作的数据应该在哪里，哪个sub database（子数据库）可以完成你的操作。

更进一步，为了优化人员结构，这家单位裁撤了传达室，设置一种规则，根据规则一下子就可以算出要找的人在哪里。比如说，有一家单位

（对，就是白宫，看图片一点都不宏伟）假设一共有30个办公室，规则如下，按人名笔画数，除以30，余数为几，就在几号办公室工作。

比如，总统先生，唐纳德·特朗普，应该在几号办公室？

唐纳德·特朗普，笔画数一共64，除以30，余数为4。

?

总统先生在4号办公室办公。

前总统奥巴马呢，贝拉克·侯赛因·奥巴马，笔画数一共68，除以30，余数为8，按照我们的规则，前总统先生在8号办公室。

怎么样，这样一来，每次你去白宫找人办事，只需要根据人名笔划数计算一下，就知道要找的人在哪里了。通过这种方式，不再有“传达室”，可以少花纳税人的钱。路由方式，则变成了“规则”（即笔划数除以30取余）。

规则式路由，是分布式数据库最常采用的。而“笔划数除以30取余”这样的规则，则属于HASH规则类。

在IT领域中，根据某种确定的方式，将一个数字进行计算，得到另一个数字，这就是HASH算法的本质，对HASH在这里不必深究，以后再专门开篇文章好好讲讲这些著名的算法。

我们例子中的HASH规则，像不像一样生活中常见的东东，给你三秒想一下，是什么：

没猜出来，对吗！没关系，翻开一本新华字典，它的目录编排方式，就是一种HASH规则。

Oracle、MySQL等SQL型数据库的分布式就是这样，基于某种HASH规则，将数据存储在某一个Sub Database（子数据库中）。操作数据时，同样根据HASH规则，计算得出数据存储在哪一个Sub Database中，然后到相应的Sub database中执行操作。

说白了，就是先查一下目录再翻书。

这里有一个问题，比如随着人员的扩展，白宫的办公室不够用了，预算部门决定明年新增1间办公室。这就是分布式数据库的扩容了。也叫横向扩展。

办公室数量增加到31之后，原来的规则“笔划数除以30取余”，要改为“笔划数除以31取余”了，除以30，要改为除以31了。因为现在办公室数量已经由30增至31了。

总统先生唐纳德·特朗普的笔划数是64，基于原来的HASH规则，是在4号办公室，但现在，他应该在2号办公室。64除以31余数是2了。

前总统奥巴马呢，贝拉克·侯赛因·奥巴马，笔画数一共68，除以31，余数为6。前总统先生的新办法室在6号。

不但总统先生，副总统、各位参赞、秘书，所有人的办公室都变了。除以30取余，和除以31取余，结果将大不相同。

这就是为什么分布式数据库扩容这么难了。本来30个子库，扩展到31个子库，所有数据要全部改变一下它所属的子库。所有数据都要辗转腾挪一边，这当然是个大工程了。

而Cassandra有一个非常好的特性，它的分布式是按照一致性HASH算法，计算数据应该存储在哪个Sub Database（子数据库）。一致性HASH，英文名称Consistent Hashing。它是普通HASH算法的修正，目的就是为了解决HASH算法在扩容（或缩容）时，要对所有数据重新计算HASH值的问题。

说到Consistent Hashing，不能不上一张图：

所有介绍Consistent Hashing的文章，都必须祭出这张图，才能显得自己专业。我们就不照这个图解说了，来个简单的。

这次咱们又要到五角大楼找人了。假设五角大楼只有5个办公室，分别分布在5个角上。

这次又要怎么安排办公室呢？姓名笔画数除以5取余吗？先别急做除法，虽然目前五角大楼办公室数少，但它目标宏大：

据说，很快就会发展到30间办公室。可目前只有5间，没关系，要面向未来吗！

具体怎么做呢？先把5间办公室的编号改的大气点：

1号办公室就不叫“1号”了，为了面向未来，直接叫“6号办公室”。然后，2号改为12号，3号改为18号，以此类推。

好了，现在五角大楼已经有30号办公室了。

看图片，没有1、2、3……直接蹦出来个6，然后是12，等等，这多别扭啊。没关系，可以发扬无产阶级空想精神，假想在6号前面，有1、2、3、4、5号办公室存在。当然，它们现在还不存在，可以称它们为虚拟办公室，如下图：

（图中的1到5，7到11，都是虚拟办公室）

现在，每名五角大楼工作人员，按姓名笔画数除以30其余，余数为1到6的，在6号办公室（原1号）。余数为7到12的，在12号办公室（原2号）等等，以此类推。

除以30其余，计算出的是虚拟办公室编号，只要顺时针向后找，找到的第一个实际办公室，就是真正所在的办公室。

如果两位总统先生到了五角大楼，应该在哪个办公室呢？

现总统先生唐纳德•特朗普的笔划数是64，除以30取余是4，也就是虚拟办公室编号为4，顺时针向后找，第一个大于4的实际办公室是6号。所以特朗普在6号办公室。

而前总统贝拉克•侯赛因•奥巴马先生，笔画数一共68，除以30取余是8。

如上图，从8开始，顺时针向后找，奥巴马在12号办公室。

这就是一致性HASH的计算过程。现在，让我们把背景碍眼的五角大楼图去掉：

是不是和下面官方资料中的图比较像了？

?

（特别说明：文中虚拟办公室和Cassandra中的虚拟节点并不是一个概念）。

相较普通的HASH，一致性HASH的优点是扩/缩容的时候影响小，这一点如何表现出来的呢？看下图：

现在要在18到24之间增加一间实际办公室。本来19到23号虚拟办公室的人，都按排在24号实际办公室办公的。或者说，19到23，属于24。

假设21变为了实际办公室：

原来都属于24号，19到23，又如何安排呢？很简单啊，原则一样，“顺时针向后找，第一个实际办公室就是最终位置”。按照新的办公室数量，22号、23号虚拟办公室，还属24号实际办公室不变。19号、20号则属于新的21号办公室。

重点是，在18和24号办公室之间新增一个办公室，只影响在24号办公室中的人。其他实际办公室的人不会有任何变化。这就是一致性HASH的独特之处。

在只有5个实际办公室的情况下，使用普通HASH算法，增加一个办公室，影响所有人。所有人都要重新计算位置。一致性HASH算法，只有五分之一的人受影响。

我们把“办公室”换成节点，把“人”换成数据，再把实际办公室数量增大。如果有500个节点，节点扩容时，使用一致性HASH算法，只有五百分之一的数据受影响。怎么样，节点数量一多，扩容或缩容受影响的数据就越少。而普通HASH算法，无论有多少节点，每次扩/缩容都要影响全部数据。

因此，采用了一致性HASH的Cassandra的，理论上扩/缩容的影响会比较小。正是这个特性，深深的打动了奎恩。在奎恩的推动下，Digg的应用开发部门，重写了所有的应用代码，以适应NoSQL的Cassandra数据库。

不再有SQL，这会使应用的开发更加复杂，但好处也是显而易见的。横向扩展（也就是扩容）更加方便、更好的性能……

故事继续。至2010年8月，Digg的技术团队完成了这次购模浩大的重构。底层数据库，成功换为了NoSQL的Cassandra。