一語點醒技術人：你不是google。在為問題尋找解決方案時要先充分了解問題本身，而不是一味地盲目崇拜那些巨頭公司。ozan onay 以 amazon、linkedin 和 google 為例，為執迷不悟的人敲響警鐘。以下內容已獲得作者翻譯授權，檢視原文：you are not google。
軟體工程師總是著迷於荒唐古怪的事。我們看起來似乎很理性，但在面對技術選型時，總是陷入抓狂——從 hacker news 到各種部落格，像乙隻飛蛾一樣，來回折騰，最後精疲力盡，無助地飛向一團亮光，跪倒在它的前面——那就是我們一直在尋找的東西。
真正理性的人不是這樣做決定的。不過工程師一貫如此，比如決定是否使用 mapreduce。
joe hellerstein 在他的大學資料庫教程**中說道：
世界上只有差不多 5 個公司需要執行這麼大規模的作業。至於其他公司……他們使用了所有的 io 來實現不必要的容錯。在 2000 年代，人們狂熱地追隨著 google：「我們要做 google 做過的每一件事，因為我們也執行著世界上最大的網際網路資料服務。」
超出實際需求的容錯沒有什麼問題，但我們卻為此付出了的慘重的代價：不僅增加了 io，還有可能讓原先成熟的系統——包含了事務、索引和查詢優化器——變得破碎不堪。這是乙個多麼嚴重的歷史倒退！有多少個 hadoop 使用者是有意識地做出這種決定的？有多少人知道他們的決定到底是不是乙個明智之舉？
mapreduce 已經成為乙個眾矢之的，那些盲目崇拜者也意識到事情不對勁。但這種情況卻普遍存在：雖然你使用了大公司的技術，但你的情況卻與他們大不一樣，而且你的決定並沒有經過深思熟慮，你只是習以為常地認為，模仿巨頭公司就一定也能給你帶來同樣的財富。
是的，這又是一篇勸大家「不要盲目崇拜」的文章。不過這次我列出了一長串有用的清單，或許能夠幫助你們做出更好的決定。
很酷的技術？unphat
如果你還在使用 google 搜尋新技術來重建你的軟體架構，那麼我建議你不要再這麼做了。相反，你可以考慮應用 unphat 原則。
在徹底了解（understand）你的問題之前，不要急著去尋找解決方案。你的目標應該是在問題領域內「解決」問題，而不是在方案領域內解決問題。 列出（enumerate）多種方案，不要只把眼睛盯在你最喜歡的方案上。 選擇乙個候選方案，並閱讀相關**（*****）。 了解候選方案的產生背景（historical context）。 比較優點（advantages）和缺點，揚長避短。 思考（think）！冷靜地思考候選方案是否適合用於解決你的問題。要出現怎樣異常的情況才會讓你改變注意？例如，資料要少到什麼程度才會讓你打消使用 hadoop 的念頭？
你不是 amazon
unphat 原則十分直截了當。最近我與乙個公司有過一次對話，這個公司打算在乙個讀密集的系統裡使用 cassandra，他們的資料是在夜間載入到系統裡的。
他們閱讀了 dynamo 的相關**，並且知道 cassandra 是最接近 dynamo 的乙個產品。我們知道，這些分布式資料庫優先保證寫可用性（amazon 是不會讓「新增到購物車」這種操作出現失敗的）。為了達到這個目的，他們在一致性以及幾乎所有在傳統 rdbms **現過的特性上做出了妥協。但這家公司其實沒有必要優先考慮寫可用性，因為他們每天只有一次寫入操作，只是資料量比較大。
他們之所以考慮使用 cassandra，是因為 postgresql 查詢需要耗費幾分鐘的時間。他們認為是硬體的問題，經過排查，我們發現資料表裡有 5000 萬條資料，每條資料最多 80 個位元組。如果從 ssd 上整塊地讀取所有資料大概需要 5 秒鐘，這個不算快，但比起實際的查詢，它要快上兩個數量級。
我真的很想多問他們幾個問題（了解問題！），在問題變得愈加嚴重時，我為他們準備了 5 個方案（列出多個候選方案！），不過很顯然，cassandra 對於他們來說完全是乙個錯誤的方案。他們只需要耐心地做一些調優，比如對部分資料重新建模，或許可以考慮使用（當然也有可能沒有）其他技術……但一定不是這種寫高可用的鍵值儲存系統，amazon 當初建立 cassandra 是用來解決他們的購物車問題的！
你不是 linkedin
我發現乙個學生創辦的小公司居然在他們的系統裡使用 kafka，這讓我感到很驚訝。因為據我所知，他們每天只有很少的事務需要處理——最好的情況下，一天最多只有幾百個。這樣的吞吐量幾乎可以直接記在記事本上。
kafka 被設計用於處理 linkedin 內部的吞吐量，那可是乙個天文數字。即使是在幾年前，這個數字已經達到了每天數萬億，在高峰時段每秒鐘需要處理 1000 萬個訊息。不過 kafka 也可以用於處理低吞吐量的負載，或許再低 10 個數量級？
或許工程師們在做決定時確實是基於他們的預期需求，並且也很了解 kafka 的適用場景。但我猜測他們是抵擋不住社群對 kafka 的追捧，並沒有仔細想過 kafka 是否適合他們。要知道，那可是 10 個數量級的差距！
再一次，你不是 amazon
比 amazon 的分布式資料庫更為著名的是它的可伸縮架構模式，也就是面向服務架構。werner vogels 在 2006 年的一次訪談中指出，amazon 在 2001 年時就意識到他們的前端需要橫向伸縮，而面向服務架構有助於他們實現前端伸縮。工程師們面面相覷，最後只有少數幾個工程師著手去做這件事情，而幾乎沒有人願意將他們的靜態網頁拆分成小型的服務。
不過 amazon 還是決定向 soa 轉型，他們當時有 7800 個員工和 30 億美元的銷售規模。
當然，並不是說你也要等到有 7800 個員工的時候才能轉向 soa……只是你要多想想，它真的能解決你的問題嗎？你的問題的根源是什麼？可以通過其他的方式解決它們嗎？
如果你告訴我說，你那 50 個人的公司打算轉向 soa，那麼我不禁感到疑惑：為什麼很多大型的公司仍然在樂此不彼地使用具有模組化的大型單體應用？
甚至 google 也不是 google
使用 hadoop 和 spark 這樣的大規模資料流引擎會非常有趣，但在很多情況下，傳統的 dbms 更適合當前的負載，有時候資料量小到可以直接放進記憶體。你是否願意花 10,000 美金去購買 1tb 的記憶體？如果你有十億個使用者，每個使用者僅能使用 1kb 的記憶體，所以你的投入遠遠不夠。
或許你的負載大到需要把資料寫回磁碟。那麼你需要多少磁碟？你到底有多少資料量？google 之所以要建立 gfs 和 mapreduce，是要解決整個 web 的計算問題，比如重建整個 web 的搜尋索引。
或許你已經閱讀過 gfs 和 mapreduce 的**，google 的部分問題在於吞吐量，而不是容量，他們之所以需要分布式的儲存，是因為從磁碟讀取位元組流要花費太多的時間。那麼你在 2017 年需要使用多少裝置吞吐量？你一定不需要像 google 那麼大的吞吐量，所以你可能會考慮使用更好的裝置。如果都用上 ssd 會給你增加多少成本？
或許你還想要伸縮性。但你有仔細算過嗎，你的資料增長速度會快過 ssd 降價的速度嗎？在你的資料撐爆所有的機器之前，你的業務會有多少增長？截止 2016 年，stack exchange 每天要處理 2 億個請求，但是他們只用了 4 個 sql server，乙個用於 stack overflow，乙個用於其他用途，另外兩個作為備份複本。
或許你在應用 unphat 原則之後，仍然決定要使用 hadoop 或 spark。或許你的決定是對的，但關鍵的是你要用對工具。google 非常明白這個道理，當他們意識到 mapreduce 不再適合用於構建索引之後，他們就不再使用它。
先了解你的問題
我所說的也不是什麼新觀點，不過或許 unphat 對於你們來說已經足夠了。如果你覺得還不夠，可以聽聽 rich hickey 的演講「吊床驅動開發」，或者看看 polya 的書《how to solve it》， 或者學習一下 hamming 的課程「the art of doing science and engineering」。我懇請你們一定要多思考！在嘗試解決問題之前先對它們有充分的了解。最後送上 polya 的乙個金句名言：
回答乙個你不了解的問題是愚蠢的，到達乙個你不期望的終點是悲哀的。
魔獸世界，你不是乙個人
網路遊戲，大家一定都不陌生。說起來很可笑，我本來一直是不玩這種遊戲的，還曾經信誓旦旦的跟同事說，少玩點遊戲，多學點東西。世事本無常，聽楓一夜秋雨 可能是因為放大假無聊，玩上了魔獸世界。開始的時候，叫沉迷，幾乎天天都在練級中 那個時候，基本也是乙個人在，很孤獨，很無聊。而且，時常的空虛也會席捲整個身心...
使人疲憊的不是遠方的高山，而是你鞋子裡的一粒沙子
今天上班途中聽到乙個概念 慢性日常麻煩 描述的時我們日常生活中那些看似不起眼，但又時常困擾我們的小事情。通常擊垮我們的往往不是什麼驚天動地的大事情，而是一些微不足道的小事情。伏爾泰有句話 使人疲憊的不是遠方的高山，而是你鞋子裡的一粒沙子 聽到這裡很受感觸，有些社會經歷後就偶爾會回憶過去，回憶的可能不...
站長，你不是技術員，而應該是乙個銷售員
網際網路的發展造就了站長行業的發展，有人說站長是個苦逼的行業，有人說站長也是一項賺錢的行業。至於誰是誰非不做討論，我們想要知道的是為什麼別人做 可以過得很好，為什麼別人的 可以運營的那麼成功 賺錢 正因為站長行業的發展，建站已經越來越簡單化，任何乙個朋友都可以一鍵式的建站了。而大多數的 並不能盈利，...