二喵看到了一篇比較好的文章，今天推薦給大家，希望你也能喜歡…
同時，如果你是一個內心向往自由的開發者，別忘記時常關注自由自在的雲沃客
——————————————————————————————————————————
[在爲問題尋找解決方案時要先充分了解問題本身，而不是一味地盲目崇拜那些巨頭公司。Ozan Onay 以 Amazon、LinkedIn 和 Google 爲例，爲執迷不悟的人敲響警鐘。以下內容已獲得作者翻譯授權，查看原文：You Are Not Google。]
真正理性的人不是這樣做決定的。不過工程師一貫如此，比如決定是否使用 MapReduce。
Joe Hellerstein 在他的大學數據庫教程視頻中說道：
[世界上只有差不多 5 個公司需要運行這麼大規模的作業。至於其他公司……他們使用了所有的 IO 來實現不必要的容錯。在 2000 年代，人們狂熱地追隨着 Google：“我們要做 Google 做過的每一件事，因爲我們也運行着世界上最大的互聯網數據服務。”]
MapReduce 已經成爲一個衆矢之的，那些盲目崇拜者也意識到事情不對勁。但這種情況卻普遍存在：雖然你使用了大公司的技術，但你的情況卻與他們大不一樣，而且你的決定並沒有經過深思熟慮，你只是習以爲常地認爲，模仿巨頭公司就一定也能給你帶來同樣的財富。
是的，這又是一篇勸大家“不要盲目崇拜”的文章。不過這次我列出了一長串有用的清單，或許能夠幫助你們做出更好的決定。
很酷的技術？UNPHAT
如果你還在使用 Google 搜索新技術來重建你的軟件架構，那麼我建議你不要再這麼做了。相反，你可以考慮應用 UNPHAT 原則。
- 在徹底瞭解（Understand）你的問題之前，不要急着去尋找解決方案。你的目標應該是在問題領域內“解決”問題，而不是在方案領域內解決問題。
- 列出（eNumerate）多種方案，不要只把眼睛盯在你最喜歡的方案上。
- 選擇一個候選方案，並閱讀相關論文（Paper）。
- 瞭解候選方案的產生背景（Historical context）。
- 比較優點（Advantages）和缺點，揚長避短。
- 思考（Think）！冷靜地思考候選方案是否適合用於解決你的問題。要出現怎樣異常的情況纔會讓你改變注意？例如，數據要少到什麼程度纔會讓你打消使用 Hadoop 的念頭？
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 的一個金句名言：
回答一個你不瞭解的問題是愚蠢的，到達一個你不期望的終點是悲哀的。