Digg启示录:你选对数据库了吗?

2017-10-27 45219人围观 资讯

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

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

Digg.jpg

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

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

图片1.png

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

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

数据库压力大,怎么破?

图片2.png

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

图片3.png

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

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

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

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

图片4.png

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

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

图片5.png

转过头再说约翰·奎恩。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的分布式当然也可以扩容,但每次扩容都是伤筋动骨的大动作,搞的数据库团队人困马乏。

图片6.png

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

有了Cassandra,工作更轻松。

图片7.png

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

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

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

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

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

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

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

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

图片9.png

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

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

图片10.png

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

图片11.png

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

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

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

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

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

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

图片12.png

目录

没猜出来,对吗!没关系,翻开一本新华字典,它的目录编排方式,就是一种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,不能不上一张图:

图片13.png

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

图片14.png

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

图片15.png

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

图片16.png

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

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

图片17.png

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

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

图片18.png

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

图片19.png

(图中的1到5,7到11,都是虚拟办公室)

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

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

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

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

图片20.png

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

图片21.png

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

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

图片22.png

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

图片23.png

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

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

图片24.png

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

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

图片25.png

原来都属于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月份,大半年的时间,对于替换所有底层数据库这样的大动作来说,还算是快的了。

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

图片26.png

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

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

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

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

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

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

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

reddit.png

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

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

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

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

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

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

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

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

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

取消
Loading...

特别推荐

推荐关注

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php