一語點醒技術人：你不是 Google（轉載）

轉載連接：https://www.infoq.cn/article/2017/06/U-no-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）多種方案，不要只把眼睛盯在你最喜歡的方案上。
選擇一個候選方案，並閱讀相關論文（Paper）。
瞭解候選方案的產生背景（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 的一個金句名言：

回答一個你不瞭解的問題是愚蠢的，到達一個你不指望的終點是悲哀的。