很多时候，那些出色的设计思路或者新颖的工具并没有让事情变得更快。相反，它们却拖慢了你的速度。
这在为大规模使用设计的工具上尤为明显。它们刻意增加复杂性以增强可扩展性。
但如果你现在的规模还不够大，那么你就不需要这个工具。
让我举个例子...
你的 Hadoop 集群比我的命令行慢 235 倍
常用的工具通常能很好地完成工作。
我最近在 Adam Drake 的博客上发现了一篇很好的文章。在这篇文章中，任务是分析 200 万局棋的胜率，数据大约有 1.75GB。他比较了 Hadoop 集群与一些简单的命令行工具的性能。
他的发现是什么？
对于同样的数据量，我使用我的笔记本电脑大约 12 秒就得到了结果（处理速度约为 270MB/秒），而 Hadoop 的处理时间大约为 26 分钟（处理速度约为 1.14MB/秒）。
这是 235 倍的差异。
使用大数据工具，如 Hadoop，来完成流处理工具可以在命令行中完成的工作是过度设计。Hadoop 集群并没有带来任何好处。事实上，复杂的架构正在减缓速度。
复杂性盲点
作为一名软件开发者，你需要注意的是...
添加复杂性经常看似会更快/更好。但除非你测试你的假设，否则你永远不会真的确定！
这适用于数据库索引、并行处理、缓存、数据管道以及作为开发者的其他许多时刻。
你可能会认为 Hadoop 集群更适合批处理。这就是这个工具的构建目的！但这完全取决于手头的任务、数据的格式以及你期望的输出。
如果你按照这个假设去执行，你可能会在应用中引入不必要的复杂性。一个更简单的解决方案可能会更好！
简单几乎总是更好
这个教训是首先构建简单的版本，然后测试关于更复杂版本的假设。
通常，简单的版本已经足够快并能够满足你的需求。开始时不要过度设计。
然后，当你的简单解决方案达到其可扩展性的极限时，找到瓶颈并针对瓶颈进行优化。
如果你读了 Adam Drake 的博客文章，你会看到他的国际象棋分析器的第一个版本已经比 Hadoop 集群更快。但当他寻找可扩展性时，他优化了解决方案以并行化简单方法的一部分。
我认为这种方法在现实世界中会走得很远。它可以处理除了最大的大数据集之外的所有内容。他需要在大规模下使用 Hadoop 来解决问题还需要一段时间。
也许 Hadoop 永远都不是最佳的工具选择。只有通过测试你的假设，你才会知道。
每日清单
2,000 名软件开发人员会收到我的每日文章，直接发送到他们的订阅消息中。
如果你喜欢我的文章，点赞，关注，转发！
