你选对数据库了吗 Digg 启示录 光环大数据培训

光环大数据（大数据培训班的专业机构）， 未来的世界是属于数据的，而数据则存储在数据库中。数据库，无疑是企业所有应用的基石。数据库种类有很多，你选对数据库了吗？美国有一家互联网公司，Digg。创办于 2004 年，又叫掘客，就是个新闻网站，但不同于传统 ...

数据库 SQL MySQL 分布式 NoSQL 分表

未来的世界是属于数据的，而数据则存储在数据库中。数据库，无疑是企业所有应用的基石。数据库种类有很多，你选对数据库了吗？
美国有一家互联网公司，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 并不是解决所有问题的银弹。幻想有一种方法，可以解决一切问题，这本身就违背了系统架构师的基本法则。
“合适的场景，使用合适的数据库”，才是真正的王道！

大数据培训、人工智能培训、Python培训、大数据培训机构、大数据培训班、数据分析培训、大数据可视化培训，就选光环大数据！光环大数据，聘请专业的大数据领域知名讲师，确保教学的整体质量与教学水准。讲师团及时掌握时代潮流技术，将前沿技能融入教学中，确保学生所学知识顺应时代所需。通过深入浅出、通俗易懂的教学方式，指导学生更快的掌握技能知识，成就上万个高薪就业学子。 更多问题咨询，欢迎点击------>>>>在线客服！