一语点醒技术人：你不是 Google（转载）

转载连接：https://www.infoq.cn/article/2017/06/U-no-Google

在为问题寻找解决方案时要先充分了解问题自己，而不是一味地盲目崇拜那些巨头公司。Ozan Onay 以 Amazon、LinkedIn 和 Google 为例，为执迷不悟的人敲响警钟。如下内容已得到做者翻译受权，查看原文： You Are Not Google 。

软件工程师老是着迷于荒唐古怪的事。咱们看起来彷佛很理性，但在面对技术选型时，老是陷入抓狂——从 Hacker News 到各类博客，像一只飞蛾同样，来回折腾，最后精疲力尽，无助地飞向一团亮光，跪倒在它的前面——那就是咱们一直在寻找的东西。

真正理性的人不是这样作决定的。不过工程师一向如此，好比决定是否使用 MapReduce。

Joe Hellerstein 在他的大学数据库教程视频中说道：

世界上只有差很少 5 个公司须要运行这么大规模的做业。至于其余公司……他们使用了全部的 IO 来实现没必要要的容错。在 2000 年代，人们狂热地追随着 Google：“咱们要作 Google 作过的每一件事，由于咱们也运行着世界上最大的互联网数据服务。”

超出实际需求的容错没有什么问题，但咱们却为此付出了的惨重的代价：不只增长了 IO，还有可能让原先成熟的系统——包含了事务、索引和查询优化器——变得破碎不堪。这是一个多么严重的历史倒退！有多少个 Hadoop 用户是有意识地作出这种决定的？有多少人知道他们的决定究竟是不是一个明智之举？

MapReduce 已经成为一个众矢之的，那些盲目崇拜者也意识到事情不对劲。但这种状况却广泛存在：虽然你使用了大公司的技术，但你的状况却与他们大不同，并且你的决定并无通过深思熟虑，你只是习觉得常地认为，模仿巨头公司就必定也能给你带来一样的财富。

是的，这又是一篇劝你们“不要盲目崇拜”的文章。不过此次我列出了一长串有用的清单，或许可以帮助大家作出更好的决定。

很酷的技术？UNPHAT

若是你还在使用 Google 搜索新技术来重建你的软件架构，那么我建议你不要再这么作了。相反，你能够考虑应用 UNPHAT 原则。

在完全了解（Understand）你的问题以前，不要急着去寻找解决方案。你的目标应该是在问题领域内“解决”问题，而不是在方案领域内解决问题。
列出（eNumerate）多种方案，不要只把眼睛盯在你最喜欢的方案上。
选择一个候选方案，并阅读相关论文（Paper）。
了解候选方案的产生背景（Historical context）。
比较优势（Advantages）和缺点，扬长避短。
思考（Think）！冷静地思考候选方案是否适合用于解决你的问题。要出现怎样异常的状况才会让你改变注意？例如，数据要少到什么程度才会让你打消使用 Hadoop 的念头？
你不是 Amazon

UNPHAT 原则十分直截了当。最近我与一个公司有过一次对话，这个公司打算在一个读密集的系统里使用 Cassandra，他们的数据是在夜间加载到系统里的。

他们阅读了 Dynamo 的相关论文，而且知道 Cassandra 是最接近 Dynamo 的一个产品。咱们知道，这些分布式数据库优先保证写可用性（Amazon 是不会让“添加到购物车”这种操做出现失败的）。为了达到这个目的，他们在一致性以及几乎全部在传统 RDBMS 中出现过的特性上作出了妥协。但这家公司其实没有必要优先考虑写可用性，由于他们天天只有一次写入操做，只是数据量比较大。

他们之因此考虑使用 Cassandra，是由于 PostgreSQL 查询须要耗费几分钟的时间。他们认为是硬件的问题，通过排查，咱们发现数据表里有 5000 万条数据，每条数据最多 80 个字节。若是从 SSD 上整块地读取全部数据大概须要 5 秒钟，这个不算快，但比起实际的查询，它要快上两个数量级。

我真的很想多问他们几个问题（了解问题！），在问题变得越发严重时，我为他们准备了 5 个方案（列出多个候选方案！），不过很显然，Cassandra 对于他们来讲彻底是一个错误的方案。他们只须要耐心地作一些调优，好比对部分数据从新建模，或许能够考虑使用（固然也有可能没有）其余技术……但必定不是这种写高可用的键值存储系统，Amazon 当初建立 Cassandra 是用来解决他们的购物车问题的！

你不是 LinkedIn

我发现一个学生创办的小公司竟然在他们的系统里使用 Kafka，这让我感到很惊讶。由于据我所知，他们天天只有不多的事务须要处理——最好的状况下，一天最多只有几百个。这样的吞吐量几乎能够直接记在记事本上。

Kafka 被设计用于处理 LinkedIn 内部的吞吐量，那但是一个天文数字。即便是在几年前，这个数字已经达到了天天数万亿，在高峰时段每秒钟须要处理 1000 万个消息。不过 Kafka 也能够用于处理低吞吐量的负载，或许再低 10 个数量级？

或许工程师们在作决定时确实是基于他们的预期需求，而且也很了解 Kafka 的适用场景。但我猜想他们是抵挡不住社区对 Kafka 的追捧，并无仔细想过 Kafka 是否适合他们。要知道，那但是 10 个数量级的差距！

再一次，你不是 Amazon

比 Amazon 的分布式数据库更为著名的是它的可伸缩架构模式，也就是面向服务架构。Werner Vogels 在 2006 年的一次访谈中指出，Amazon 在 2001 年时就意识到他们的前端须要横向伸缩，而面向服务架构有助于他们实现前端伸缩。工程师们面面相觑，最后只有少数几个工程师着手去作这件事情，而几乎没有人愿意将他们的静态网页拆分红小型的服务。

不过 Amazon 仍是决定向 SOA 转型，他们当时有 7800 个员工和 30 亿美圆的销售规模。

固然，并非说你也要等到有 7800 个员工的时候才能转向 SOA……只是你要多想一想，它真的能解决你的问题吗？你的问题的根源是什么？能够经过其余的方式解决它们吗？

若是你告诉我说，你那 50 我的的公司打算转向 SOA，那么我不由感到疑惑：为何不少大型的公司仍然在乐此不彼地使用具备模块化的大型单体应用？

甚至 Google 也不是 Google

使用 Hadoop 和 Spark 这样的大规模数据流引擎会很是有趣，但在不少状况下，传统的 DBMS 更适合当前的负载，有时候数据量小到能够直接放进内存。你是否愿意花 10,000 美金去购买 1TB 的内存？若是你有十亿个用户，每一个用户仅能使用 1KB 的内存，因此你的投入远远不够。

或许你的负载大到须要把数据写回磁盘。那么你须要多少磁盘？你到底有多少数据量？Google 之因此要建立 GFS 和 MapReduce，是要解决整个 Web 的计算问题，好比重建整个 Web 的搜索索引。

或许你已经阅读过 GFS 和 MapReduce 的论文，Google 的部分问题在于吞吐量，而不是容量，他们之因此须要分布式的存储，是由于从磁盘读取字节流要花费太多的时间。那么你在 2017 年须要使用多少设备吞吐量？你必定不须要像 Google 那么大的吞吐量，因此你可能会考虑使用更好的设备。若是都用上 SSD 会给你增长多少成本？

或许你还想要伸缩性。但你有仔细算过吗，你的数据增加速度会快过 SSD 降价的速度吗？在你的数据撑爆全部的机器以前，你的业务会有多少增加？截止 2016 年，Stack Exchange 天天要处理 2 亿个请求，可是他们只用了 4 个 SQL Server，一个用于 Stack Overflow，一个用于其余用途，另外两个做为备份复本。

或许你在应用 UNPHAT 原则以后，仍然决定要使用 Hadoop 或 Spark。或许你的决定是对的，但关键的是你要用对工具。Google 很是明白这个道理，当他们意识到 MapReduce 再也不适合用于构建索引以后，他们就再也不使用它。

先了解你的问题

我所说的也不是什么新观点，不过或许 UNPHAT 对于大家来讲已经足够了。若是你以为还不够，能够听听 Rich Hickey 的演讲“吊床驱动开发”，或者看看Polya 的书《 How to Solve It 》， 或者学习一下 Hamming 的课程“ The Art of Doing Science and Engineering ”。我恳请大家必定要多思考！在尝试解决问题以前先对它们有充分的了解。最后送上 Polya 的一个金句名言：

回答一个你不了解的问题是愚蠢的，到达一个你不指望的终点是悲哀的。