「数据库传奇」Digg启示录——你选对数据库了吗

年夜家好,给年夜家介绍一下,这是我男神@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.

从年初到8月份,年夜半年的时间,对于替换所有底层数据库这样的年夜动作来说,还算是快的了.

故事到这里,是不是听起来像“从此公主与王子幸福的生活在城堡中”?

但可惜,幸福总是短暂的,奎恩很快就会明白这一点.虽然其时,他还不明白.

完成了这次基础数据库改造,奎恩已经变身为硅谷科技界红人,他相当于在硅谷动员了一场去IOE的运动.

时间到了2010年9月份,“去M”(去MySQL)才刚一个月.在这一个月内,Digg最繁忙的部分,是客服部.

自从改版之后,Digg的网站一直处于非常不稳定的状态,各种功能频繁出错,很多时候站点干脆就没法拜访.

怒火高涨的用户打爆Digg的客户电话,然而,既使把客服人员爆打一顿,仍然没什么卵用,网站依旧频繁失足.

最危险的情况出现了,大量用户弃Digg,开始玩起了类似的Reddit.想象一下,豆瓣由于网站经常打不开,大量用户弃豆瓣转向知乎.(免责声明,此处只是比方,此种情况并没发生在豆瓣和知乎之间).

9月份时,Digg的拜访量跌到了谷底.而竞争对手Reddit的拜访量再创新高,并在12月份超过Digg,从此把 Digg 远远地甩在了后面,绝尘而去.

有些东西,失去了就再也不会回来.Digg便是这样,后来又经历了一系列的调整,Digg才终于明白,应该让合适的场景使用合适的数据库.但一切都为时已晚,机会窗口已经关闭.

Digg勉强维持了将近两年,到2012年7月,被Betaworks 收购,收购价仅为 50 万美元.与颠峰时期 Google 接近 5 亿美元的收购意向相比,其缩水水平令人瞠目结舌.

这么大的错误,总要有人背锅,约翰·奎恩自然难逃其咎.在成功改换数据库一个月后,也便是当年9月份,奎恩就从高点跌到低点,面对愤怒的用户,和频繁出错的网站,奎恩不得不黯然离开Digg.

但数据库团队的大部分人都没动,虽然数据架构的负责人是最直接的责任人.但由于接下来数据架构的调整还是必要他们,这个时候辞退数据库部门的重要技术人员,不单于事无补,反而更加雪上加霜.

数据架构人,只是结合Digg的场景,对Cassandra进行了测试.测试是大量的、复杂的,而且耗时必定不短,最终得出了相对于MySQL,Cassandra性能更佳、扩容更方便的结论.但实际应用场景的复杂度,是测试无法模拟的.

而且,NoSQL并不是解决所有问题的银弹.幻想有一种办法,可以解决一切问题,这本身就违背了系统架构师的基本法则.

“合适的场景,使用合适的数据库”,才是真正的王道!

一个“惨痛”的数据库选型的例子,告诉我们,数据库选择的重要性.那如何选择得当的数据库,SQL和NoSQL数据库各有什么特点?

欲知后事如何,请听下回分化!