立即注册找回密码

QQ登录

只需一步,快速开始

查看: 9|回复: 0

一语点醒技术人:你不是Google2018/12/6 21:35:29

[复制链接]

6万

主题

6万

帖子

18万

积分

版主

Rank: 7Rank: 7Rank: 7

积分
187539
发表于 2018-12-6 21:34:47 | 显示全部楼层 |阅读模式

在为问题寻找解决方案时要先充分了解问题本身,而不是一味地盲目崇拜那些巨头公司。O O 以 A、LI 和 G 为例,为执迷不悟的人敲响警钟。以下内容已获得作者翻译授权,查看原文:Y A N G。  关注odoo,有帮助!

  软件工程师总是着迷于荒唐古怪的事。我们看起来似乎很理性,但在面对技术选型时,总是陷入抓狂从 H N 到各种博客,像一只飞蛾一样,来回折腾,最后精疲力尽,无助地飞向一团亮光,跪倒在它的前面那就是我们一直在寻找的东西。
  真正理性的人不是这样做决定的。不过工程师一贯如此,比如决定是否使用 MR。
  J H 在他的大学数据库教程视频中说道:

世界上只有差不多  个公司需要运行这么大规模的作业。至于其他公司他们使用了所有的 IO 来实现不必要的容错。在  年代,人们狂热地追随着 G:我们要做 G 做过的每一件事,因为我们也运行着世界上最大的互联数据服务。

  超出实际需求的容错没有什么问题,但我们却为此付出了的惨重的代价:不仅增加了 IO,还有可能让原先成熟的系统包含了事务、索引和查询优化器变得破碎不堪。这是一个多么严重的历史倒退!有多少个 H 用户是有意识地做出这种决定的?有多少人知道他们的决定到底是不是一个明智之举?
  MR 已经成为一个众矢之的,那些盲目崇拜者也意识到事情不对劲。但这种情况却普遍存在:虽然你使用了大公司的技术,但你的情况却与他们大不一样,而且你的决定并没有经过深思熟虑,你只是习以为常地认为,模仿巨头公司就一定也能给你带来同样的财富。
  是的,这又是一篇劝大家不要盲目崇拜的文章。不过这次我列出了一长串有用的清单,或许能够帮助你们做出更好的决定。
  很酷的技术?UNPHAT
  如果你还在使用 G 搜索新技术来重建你的软件架构,那么我建议你不要再这么做了。相反,你可以考虑应用 UNPHAT 原则。 

在彻底了解(U)你的问题之前,不要急着去寻找解决方案。你的目标应该是在问题领域内解决问题,而不是在方案领域内解决问题。
列出(N)多种方案,不要只把眼睛盯在你最喜欢的方案上。
选择一个候选方案,并阅读相关论文(P)。 
了解候选方案的产生背景(H )。
比较优点(A)和缺点,扬长避短。
思考(T)!冷静地思考候选方案是否适合用于解决你的问题。要出现怎样异常的情况才会让你改变注意?例如,数据要少到什么程度才会让你打消使用 H 的念头?

  你不是 A
  UNPHAT 原则十分直截了当。最近我与一个公司有过一次对话,这个公司打算在一个读密集的系统里使用 C,他们的数据是在夜间加载到系统里的。
  他们阅读了 D 的相关论文,并且知道 C 是最接近 D 的一个产品。我们知道,这些分布式数据库优先保证写可用性(A 是不会让添加到购物车这种操作出现失败的)。为了达到这个目的,他们在一致性以及几乎所有在传统 RDBMS 中出现过的特性上做出了妥协。但这家公司其实没有必要优先考虑写可用性,因为他们每天只有一次写入操作,只是数据量比较大。
  他们之所以考虑使用 C,是因为 PSQL 查询需要耗费几分钟的时间。他们认为是硬件的问题,经过排查,我们发现数据表里有  万条数据,每条数据最多  个字节。如果从 SSD 上整块地读取所有数据大概需要  秒钟,这个不算快,但比起实际的查询,它要快上两个数量级。
  我真的很想多问他们几个问题(了解问题!),在问题变得愈加严重时,我为他们准备了  个方案(列出多个候选方案!),不过很显然,C 对于他们来说完全是一个错误的方案。他们只需要耐心地做一些调优,比如对部分数据重新建模,或许可以考虑使用(当然也有可能没有)其他技术但一定不是这种写高可用的键值存储系统,A 当初创建 C 是用来解决他们的购物车问题的!
  你不是 LI
  我发现一个学生创办的小公司居然在他们的系统里使用 K,这让我感到很惊讶。因为据我所知,他们每天只有很少的事务需要处理最好的情况下,一天最多只有几百个。这样的吞吐量几乎可以直接记在记事本上。
  K 被设计用于处理 LI 内部的吞吐量,那可是一个天文数字。即使是在几年前,这个数字已经达到了每天数万亿,在高峰时段每秒钟需要处理  万个消息。不过 K 也可以用于处理低吞吐量的负载,或许再低  个数量级?
  或许工程师们在做决定时确实是基于他们的预期需求,并且也很了解 K 的适用场景。但我猜测他们是抵挡不住社区对 K 的追捧,并没有仔细想过 K 是否适合他们。要知道,那可是  个数量级的差距!
  再一次,你不是 A
  比 A 的分布式数据库更为著名的是它的可伸缩架构模式,也就是面向服务架构。W V 在  年的一次访谈中指出,A 在  年时就意识到他们的前端需要横向伸缩,而面向服务架构有助于他们实现前端伸缩。工程师们面面相觑,最后只有少数几个工程师着手去做这件事情,而几乎没有人愿意将他们的静态页拆分成小型的服务。
  不过 A 还是决定向 SOA 转型,他们当时有  个员工和  亿美元的销售规模。
  当然,并不是说你也要等到有  个员工的时候才能转向 SOA只是你要多想想,它真的能解决你的问题吗?你的问题的根源是什么?可以通过其他的方式解决它们吗?
  如果你告诉我说,你那  个人的公司打算转向 SOA,那么我不禁感到疑惑:为什么很多大型的公司仍然在乐此不彼地使用具有模块化的大型单体应用?
  甚至 G 也不是 G
  使用 H 和 S 这样的大规模数据流引擎会非常有趣,但在很多情况下,传统的 DBMS 更适合当前的负载,有时候数据量小到可以直接放进内存。你是否愿意花 , 美金去购买 TB 的内存?如果你有十亿个用户,每个用户仅能使用 KB 的内存,所以你的投入远远不够。
  或许你的负载大到需要把数据写回磁盘。那么你需要多少磁盘?你到底有多少数据量?G 之所以要创建 GFS 和 MR,是要解决整个 W 的计算问题,比如重建整个 W 的搜索索引。
  或许你已经阅读过 GFS 和 MR 的论文,G 的部分问题在于吞吐量,而不是容量,他们之所以需要分布式的存储,是因为从磁盘读取字节流要花费太多的时间。那么你在  年需要使用多少设备吞吐量?你一定不需要像 G 那么大的吞吐量,所以你可能会考虑使用更好的设备。如果都用上 SSD 会给你增加多少成本?
  或许你还想要伸缩性。但你有仔细算过吗,你的数据增长速度会快过 SSD 降价的速度吗?在你的数据撑爆所有的机器之前,你的业务会有多少增长?截止  年,S E 每天要处理  亿个请求,但是他们只用了  个 SQL S,一个用于 S O,一个用于其他用途,另外两个作为备份复本。
  或许你在应用 UNPHAT 原则之后,仍然决定要使用 H 或 S。或许你的决定是对的,但关键的是你要用对工具。G 非常明白这个道理,当他们意识到 MR 不再适合用于构建索引之后,他们就不再使用它。
  先了解你的问题
  我所说的也不是什么新观点,不过或许 UNPHAT 对于你们来说已经足够了。如果你觉得还不够,可以听听 R H 的演讲吊床驱动开发,或者看看 P 的书《H  S I》, 或者学习一下 H 的课程T A  D S  E。我恳请你们一定要多思考!在尝试解决问题之前先对它们有充分的了解。最后送上 P 的一个金句名言:

回答一个你不了解的问题是愚蠢的,到达一个你不期望的终点是悲哀的。 2018/12/6 21:35:29
回复

使用道具 举报

发表回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则