TB前卫网

TB前卫网店铺大全为您精选最好的精品店铺导航,欢迎您。收藏本站

你不是Google,没必要学它的一切!

栏目:科技数码   发布时间:2017/06/30   来源:InfoQ   编辑:infoqchina



策动|Ozan Onay
编纂|薛命灯
软件工程师老是着迷于荒唐怪僻的事。我们看起来仿佛很理性,但在面对技术选型时,老是堕入抓狂——从 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 的演讲“吊床驱动开发(Ha妹妹ock Driven Development)”,或看看 Polya 的书《How to Solve It》, 或学习一下 Ha妹妹ing 的课程“The Art of Doing Science and Engineering”。我恳请你们必定要多思考!在尝试解决问题以前先对它们有充沛的知道。最后送上 Polya 的一个金句名言:
回答一个你不知道的问题是笨拙的,达到一个你不指望的终点是悲痛的。AI 降临:揭秘京东智慧物流







【公众号】:InfoQ
【微信号】:infoqchina
【微宣言】:有内容的技术社区媒体

下一篇:行情中国移动质量报告:金立S10拍照效果第一
*版权声明及防欺诈提醒