你不是Google，沒必要學它的一切！

策劃｜Ozan Onay

編輯｜薛命燈

軟體工程師總是著迷於荒唐古怪的事。我們看起來似乎很理性，但在面對技術選型時，總是陷入抓狂——從 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 的演講「吊床驅動開發（Hammock Driven Development）」，或者看看 Polya 的書《How to Solve It》， 或者學習一下 Hamming 的課程「The Art of Doing Science and Engineering」。我懇請你們一定要多思考！在嘗試解決問題之前先對它們有充分的了解。最後送上 Polya 的一個金句名言：

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

今日薦文

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！