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

聊聊架构 · 公众号 · 架构 · 2017-06-13 11:25

正文

请到「今天看啥」查看全文

如果你还在使用 Google 搜索新技术来重建你的软件架构，那么我建议你不要再这么做了。相反，你可以考虑应用 UNPHAT 原则。

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

你不是 Amazon

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

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

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