编者按：没错，Google用了一些很酷的技术，你想用吗?当然。不过，在布拉德菲尔德学院教计算机科学的 Ozan Onay 建议你先坐下来想一想，搞清自己的问题是什么，看看是否有必要使用新奇的技术。

　　软件工程师因为一些可笑的事物而疯狂。我们会认为自己是超级合理的，但是当我们选择一门技术时，最终却陷入了迷乱：从一个人在Hacker News留下的评论到另一个人的博客文章，我们神智混乱，茫然无助朝着最明亮的亮光前进，匍匐在光明之前，忘了我们最初追求的是什么。

　　我们所说的并不是理智之人如何做决策，而是说软件工程师为何决定使用 MapReduce。

　　Joe Hellerstein给学生上数据库课程时说过：

　　“在世界上，可能只有5家公司有如此多的员工。对于其它人来说……你从事相关的I/O工作，对容错性提出很高要求，这种要求是没有必要的。2000年代，人们因Google而狂热：‘我们做一切事都要按Google的方式进行，因为我们也运营着世界上最大的互联网数据服务。”

　　在容错率上提出更高要求，超过你的需要，听起来不错，不过要考虑一下成本：你不只要做更多的I/O工作，还要从成熟的系统(包括交易、索引、查询优化器)转向相对破旧的系统。简直就是重大的倒退。有多少Hadoop用户无意中妥协?又有多少用户的妥协是明智的?

　　就目前而言，MapReduce/Hadoop只是一个软目标，甚至连“货物崇拜者”(当货物崇拜者看见外来的先进科技物品，便会将之当作神祇般崇拜。)也知道飞机偏离了航线。从更广泛的层面上我们也可以看到同样的现象：如果你使用一门技术，这门技术原本是针对大企业的，你的使用情况大不相同，可能无法得到预料的结果;不能，模仿巨头就能获得同样的财富，这只是仪式般的信念，无法变成现实。

　　我有一张实用的清单供你检查，你可以用它来制定更好的决策。

　　很酷的技术?UNPHAT

　　下一次，如果你发现自己模仿Google，想将一些很酷的新技术拿来用，我希望你停下来，用UNPHAT标准检查一下：

　　1、在真正理解(Understant)问题之前，不要考虑新的解决方案。你的目标应该是在问题的范围之内“解决”大部分问题，而不是在解决方案内解决。

　　2、枚举(eNumerate)多个候选解决方案，不要选那些你喜欢的。

　　3、考虑候选解决方案，如果有论文(Paper)拿来读一读。

　　4、候选解决方案是如何设计的?如何开发出来的?搞清它的历史环境(Historical Context)。

　　5、搞清优点(Advantages)和缺点。为了将优先的事情做好，搞清哪些事情是非优先的。

　　6、思考(Think)!冷静一点，谦虚一点，多想想这个方案能从多大程度上解决你的问题。如果要让你改变想法，事实必须有多大的变化?例如，如果让你不选择Hadoop，数据必须小多少?

　　你也不是亚马逊

　　使用UNPHAT法很直白。最近我与一家企业交流，这家公司要在夜间处理数据，当中包括大量读取操作的工作流，它想使用Cassandra。

　　读了Dynamo的论文之后，我知道Cassandra分布式数据库将“写操作”放在优先位置(亚马逊需要完成“加入购物车”的动作，不能出现错误)。我还知道，亚马逊选择这种技术牺牲了一致性，传统RDBMS的每一个功能也都牺牲了。不过与我交流的公司没有必要将写操作放在优先位置，因为它的读取模式是每天大规模写一次。

　　这家公司为什么考虑Cassandra?因为用PostgreSQL查询问题需要几分钟，他们认为是硬件局限性造成的。问了几个问题之后，我发现表格有大约5000万行，80字节宽，能不能用5秒左右的时间从所有SSD中读取数据。仍然很慢，但是比实际查询速度快了很多很多。

　　在这件事情上，我想问更多的问题(理解问题)，当问题出现时我权衡了5种策略(枚举多个候选解决方案)，有一点很明显，选择Cassandra是完全错误的。它们要做的是优化系统，可能还要对一些数据重新建模，或者(也可能不是)选择另一种技术……显然不是Cassandra技术，亚马逊将关键值存储起来，这些数据高度重视写操作，它们是为购物车创建的。

　　你也不是LinkedIn

　　我的一名学生创办了一家公司，他的公司根据Kafka搭建系统，我感到很惊讶。为什么吃惊?因为据我所知，他们的企业每天只处理几十宗高价值交易——最多可能几百宗。既然处理的数据如此少，最好的数据库可能是让人写在实体书上。

　　对比一下，Kafka是用来处理LinkedIn所有分析事件的：海量的数字。放在几年前，每天这样的事件可能有1万亿件，高峰时期每秒1000万条信息。我知道，即使吞吐量低，Kafka仍然可以使用，但是如果少了10个数量级呢?