對(duì)你的應(yīng)用過度設(shè)計(jì)導(dǎo)致性能下降

很多時(shí)候,那些出色的設(shè)計(jì)思路或者新穎的工具并沒有讓事情變得更快。相反,它們卻拖慢了你的速度。

這在為大規(guī)模使用設(shè)計(jì)的工具上尤為明顯。它們刻意增加復(fù)雜性以增強(qiáng)可擴(kuò)展性。

但如果你現(xiàn)在的規(guī)模還不夠大,那么你就不需要這個(gè)工具。

讓我舉個(gè)例子...

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

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

我最近在 Adam Drake 的博客上發(fā)現(xiàn)了一篇很好的文章。在這篇文章中,任務(wù)是分析 200 萬局棋的勝率,數(shù)據(jù)大約有 1.75GB。他比較了 Hadoop 集群與一些簡單的命令行工具的性能

他的發(fā)現(xiàn)是什么?

對(duì)于同樣的數(shù)據(jù)量,我使用我的筆記本電腦大約 12 秒就得到了結(jié)果(處理速度約為 270MB/秒),而 Hadoop 的處理時(shí)間大約為 26 分鐘(處理速度約為 1.14MB/秒)。

這是 235 倍的差異。

使用大數(shù)據(jù)工具,如 Hadoop,來完成流處理工具可以在命令行中完成的工作是過度設(shè)計(jì)。Hadoop 集群并沒有帶來任何好處。事實(shí)上,復(fù)雜的架構(gòu)正在減緩速度。

復(fù)雜性盲點(diǎn)

作為一名軟件開發(fā)者,你需要注意的是...

添加復(fù)雜性經(jīng)常看似會(huì)更快/更好。但除非你測試你的假設(shè),否則你永遠(yuǎn)不會(huì)真的確定!

這適用于數(shù)據(jù)庫索引、并行處理、緩存、數(shù)據(jù)管道以及作為開發(fā)者的其他許多時(shí)刻。

你可能會(huì)認(rèn)為 Hadoop 集群更適合批處理。這就是這個(gè)工具的構(gòu)建目的!但這完全取決于手頭的任務(wù)、數(shù)據(jù)的格式以及你期望的輸出。

如果你按照這個(gè)假設(shè)去執(zhí)行,你可能會(huì)在應(yīng)用中引入不必要的復(fù)雜性。一個(gè)更簡單的解決方案可能會(huì)更好!

簡單幾乎總是更好

這個(gè)教訓(xùn)是首先構(gòu)建簡單的版本,然后測試關(guān)于更復(fù)雜版本的假設(shè)。

通常,簡單的版本已經(jīng)足夠快并能夠滿足你的需求。開始時(shí)不要過度設(shè)計(jì)。

然后,當(dāng)你的簡單解決方案達(dá)到其可擴(kuò)展性的極限時(shí),找到瓶頸并針對(duì)瓶頸進(jìn)行優(yōu)化。

如果你讀了 Adam Drake 的博客文章,你會(huì)看到他的國際象棋分析器的第一個(gè)版本已經(jīng)比 Hadoop 集群更快。但當(dāng)他尋找可擴(kuò)展性時(shí),他優(yōu)化了解決方案以并行化簡單方法的一部分。

我認(rèn)為這種方法在現(xiàn)實(shí)世界中會(huì)走得很遠(yuǎn)。它可以處理除了最大的大數(shù)據(jù)集之外的所有內(nèi)容。他需要在大規(guī)模下使用 Hadoop 來解決問題還需要一段時(shí)間。

也許 Hadoop 永遠(yuǎn)都不是最佳的工具選擇。只有通過測試你的假設(shè),你才會(huì)知道。

每日清單

2,000 名軟件開發(fā)人員會(huì)收到我的每日文章,直接發(fā)送到他們的訂閱消息中。

如果你喜歡我的文章,點(diǎn)贊,關(guān)注,轉(zhuǎn)發(fā)!

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容