写点什么

一语点醒技术人:你不是 Google

  • 2017-06-13
  • 本文字数:3126 字

    阅读完需:约 10 分钟

在为问题寻找解决方案时要先充分了解问题本身,而不是一味地盲目崇拜那些巨头公司。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 原则。

  1. 在彻底了解(Understand)你的问题之前,不要急着去寻找解决方案。你的目标应该是在问题领域内“解决”问题,而不是在方案领域内解决问题。
  2. 列出(eNumerate)多种方案,不要只把眼睛盯在你最喜欢的方案上。
  3. 选择一个候选方案,并阅读相关论文(Paper)。
  4. 了解候选方案的产生背景(Historical context)。
  5. 比较优点(Advantages)和缺点,扬长避短。
  6. 思考(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 的一个金句名言:

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


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017-06-13 19:0011687
用户头像

发布了 322 篇内容, 共 151.3 次阅读, 收获喜欢 148 次。

关注

评论

发布
暂无评论
发现更多内容

StarRocks 元数据管理及 FE 高可用机制

邸星星

BerkeleyDB-JE bdbje StarRocks元数据管理

万字通俗讲解何为复杂度

华为云开发者联盟

数据结构 时间复杂度 复杂度 空间复杂度 复杂度分许

Window下Redis的安装和部署详细教程

明金同学

redis

Apache APISIX 新技能,代理 gRPC-Web 请求

API7.ai 技术团队

gRPC HTTP 网关 APISIX

浅析企业云服务之SaaS、PaaS、IaaS对比分析

郑州埃文科技

IaaS PaaS SaaS

阿里云资深专家李国强:云原生的一些趋势和新方向

Serverless Devs

Nacos 在 Apache APISIX API 网关中的服务发现实践

API7.ai 技术团队

nacos 注册中心 服务发现 API网关 APISIX

计算IIS

杉数科技

求解器 优化求解器 计算IIS 混合整数规划 杉数科技

常青藤开源科技加入,龙蜥社区再迎 HPC 和开源领域新伙伴

OpenAnolis小助手

Linux 开源 高性能计算

学生外包管理系统架构设计文档

孙强

#架构实战营

网络安全:SQL 注入漏洞

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

报名直达丨HarmonyOS开发者创新大赛线下城市交流会来了,约吗?

HarmonyOS开发者

HarmonyOS 交流 创新大赛

斯图飞腾Stratifyd入选「2022爱分析·营销科技厂商全景报告」

极客天地

JWT Token在线编码生成

入门小站

工具

如何使用 Apache APISIX CSRF 安全插件拦截跨站点伪造攻击

API7.ai 技术团队

CSRF API网关 Apache APISIX

第十五节:SpringBoot使用JPA访问数据库

入门小站

spring-boot

COPT4.0新增凸QP、QCP和QCQP求解能力

杉数科技

求解器 优化求解器 凸QP 凸QCP

【场景化集成方案】如何让企业快速集成钉钉各种能力

钉钉开发者

钉钉能力中心 钉钉官网 场景化能力包 场景化解决方案 应用集成方案

生态扩大进行中!Apache APISIX 集成 Splunk HTTP Event Collector

API7.ai 技术团队

API网关 Apache APISIX

SQL注入-“错误”的语句为什么会得到“正确”的结果?

BUG侦探

MySQL 网络安全 SQL注入

异步请求积压可视化|如何 1 分钟内快速定位函数计算积压问题

Serverless Devs

新插件上线,public API 处理能力更进一步

API7.ai 技术团队

HTTP APISIX APISIX 网关

企业级 APIs 安全实践指南 (建议初中级工程师收藏)

领创集团Advance Intelligence Group

API

使用goofys挂载S3 bucket为文件系统

阿呆

文件系统 goofys aws s3

你知道钓鱼网站的形成步骤吗?一次网络钓鱼演练带你了解(增强安全意识)

H

网络安全 钓鱼网站

如何在设计时保证RPA机器人的稳定运行?

金小K

为什么国企要加快推进数字化转型?

用友BIP

数字化转型 用友 用友iuap 用友YonBIP 国企

2022写作计划2月文章排行榜

TGO鲲鹏会

TGO鲲鹏会 写作计划

极速生成缩略图,Serverless 支撑赛事转播锁定冬奥亮点

Serverless Devs

手把手教学电瓶车进电梯检测、多类别车辆追踪、异常行为检测产业级应用

百度开发者中心

APP热更新技术最优解,不只是支持热更新...

Speedoooo

小程序 APP开发 容器安全 热更新 小程序容器

一语点醒技术人:你不是Google_Google_Ozan Onay_InfoQ精选文章