如果使用得當，MySQL 也可以化身 NoSQL

【編者按】隨著網際網路和移動網際網路的發展，各個機構都需要支撐遠超過以往的資料。而在這個需求的刺激下，IT 領域出現了大量資料處理技術，其中之一就是 NoSQL 。靈活的資料型別，高效的處理能力，讓 NoSQL 已佔據資料管理系統的一席之地，比如人氣 NoSQL 資料庫 MongoDB。然而在 Wix 工程實踐中，他們發現，大量場景中其實並不需 要 NoSQL，反而成熟的 RDBMS 更具效益，比如 MySQL。下面一起看 Wix 工程主管 Aviran Mordo 的分享，本文系 OneAPM 工程師翻譯。

開發人員選擇 NoSQL 資料庫一般都是根據主觀臆斷，或者“關係型資料庫效能不如 NoSQL 資料庫”這個錯誤的理念。此外，在做資料庫選型時，開發人員往往還忽視了運維上的開銷。實際上根據 Wix 的實踐發現，大部分情況下都不必去選擇 NoSQL 資料庫，而且如果使用得當的話，MySQL 也可以是一個優秀的 NoSQL 資料庫。

在可擴充套件系統構建時，一個很重要的考量是使用的技術是否成熟，選擇成熟的技術意味著出錯時能夠迅速恢復。當然，開發者也可以在專案中使用最新最牛的 NoSQL 資料庫，而這個資料庫在理論上也可以良好地執行，然而在生產環境中出現了問題恢復需要多久？技術上已有的知識和經驗積累對於問題緩解至關重要，當然這個積累也包括了 Google 可以搜尋到的內容。相比之下，關係型資料庫已經存在了超過四十年，業界對於關係型資料庫的維護也積累了大量的經驗。基於這些考慮，在新專案做技術選型時通常會選擇 MySQL，而不是 NoSQL 資料庫，除非 NoSQL 真的有非常非常明顯的優勢，比如資料量太大就不適合使用 MySQL。

必須承認 MySQL 也有自己的問題。在大規模系統中使用的話可能會碰到效能上的問題。為實現 MySQL 效能的最優化，這裡總結了幾條經驗，其中之一是避免資料庫級別的事務。因為事務需要資料庫採用鎖來實現，從而會影響資料庫效能。通常情況下會使用邏輯應用程式級的鎖來 替換，從而減少負載並獲得一個更好的效能。

舉個例子，以發票結構為例。如果某個發票有多個行專案，取代在單事務將所有行專案寫入，這裡更應該在非事務情況下逐行寫入。在所有行全部寫入資料庫後，這裡還會寫入一個首記錄，它包含了指向所有行專案 ID 的指標。這樣一來，如果所有行中有一行寫入失敗，那麼這行的首記錄就會不存在，從而整個事務失敗。這麼做雖然可能會造成一些垃圾記錄，但在儲存介質如此便宜的今天這顯然不是什麼大問題，而這些垃圾記錄也可以做定期刪除。

下面也中介了一些 MySQL 實踐經驗：

不要使用 joins 查詢，只做主鍵或者索引查詢。 不要使用自增主鍵因為會有鎖，取而代之，使用客戶端生成鍵，比如 GUIDs。同時，如果你使用主主備份，自增鍵還可能會衝突，因此你需要為每個例項都定製鍵的範圍。 沒有索引的欄位通通刪掉或者使用 JSON 集合成單一欄位。 在 Wix，MySQL 經常會被當做鍵值儲存，比如在一列中儲存 JSON 物件，從而在不改變資料庫模式下對資料結構模式進行擴充套件。在 MySQL 中，使用主鍵讀取也很快，Wix 就通過這個方式獲得了亞毫秒級的讀取速度，完全可以支撐整個使用場景。基於以上這些原因，MySQL 完全可以看作一個符合 ACID 原則的 NoSQL 資料庫。至於資料庫的大小，一個 MySQL 例項支援幾億條資料是沒什麼問題的。

關係型資料庫的一個鮮明的優勢是不用考慮最終一致性，而這個在 NoSQL 資料庫中並不是原生支援的。本文也不是貶低 NoSQL，因為關係型資料庫已有限制也非常多：嚴格的資料結構和大小限制。這裡只是想提醒開發人員，在選擇新技術時不要忽視運維成本。

原文連結：MySQL is a Great NoSQL Database

OneAPM 是應用效能管理領域的新興領軍企業，能幫助企業使用者和開發者輕鬆實現：緩慢的程式程式碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方部落格。