对你的应用过度设计导致性能下降

很多时候，那些出色的设计思路或者新颖的工具并没有让事情变得更快。相反，它们却拖慢了你的速度。

这在为大规模使用设计的工具上尤为明显。它们刻意增加复杂性以增强可扩展性。

但如果你现在的规模还不够大，那么你就不需要这个工具。

让我举个例子...

你的 Hadoop 集群比我的命令行慢 235 倍

常用的工具通常能很好地完成工作。

我最近在 Adam Drake 的博客上发现了一篇很好的文章。在这篇文章中，任务是分析 200 万局棋的胜率，数据大约有 1.75GB。他比较了 Hadoop 集群与一些简单的命令行工具的性能。

他的发现是什么？

对于同样的数据量，我使用我的笔记本电脑大约 12 秒就得到了结果（处理速度约为 270MB/秒），而 Hadoop 的处理时间大约为 26 分钟（处理速度约为 1.14MB/秒）。

这是 235 倍的差异。

使用大数据工具，如 Hadoop，来完成流处理工具可以在命令行中完成的工作是过度设计。Hadoop 集群并没有带来任何好处。事实上，复杂的架构正在减缓速度。

复杂性盲点

作为一名软件开发者，你需要注意的是...

添加复杂性经常看似会更快/更好。但除非你测试你的假设，否则你永远不会真的确定！

这适用于数据库索引、并行处理、缓存、数据管道以及作为开发者的其他许多时刻。

你可能会认为 Hadoop 集群更适合批处理。这就是这个工具的构建目的！但这完全取决于手头的任务、数据的格式以及你期望的输出。

如果你按照这个假设去执行，你可能会在应用中引入不必要的复杂性。一个更简单的解决方案可能会更好！

简单几乎总是更好

这个教训是首先构建简单的版本，然后测试关于更复杂版本的假设。

通常，简单的版本已经足够快并能够满足你的需求。开始时不要过度设计。

然后，当你的简单解决方案达到其可扩展性的极限时，找到瓶颈并针对瓶颈进行优化。

如果你读了 Adam Drake 的博客文章，你会看到他的国际象棋分析器的第一个版本已经比 Hadoop 集群更快。但当他寻找可扩展性时，他优化了解决方案以并行化简单方法的一部分。

我认为这种方法在现实世界中会走得很远。它可以处理除了最大的大数据集之外的所有内容。他需要在大规模下使用 Hadoop 来解决问题还需要一段时间。

也许 Hadoop 永远都不是最佳的工具选择。只有通过测试你的假设，你才会知道。

每日清单