若是使用得當，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 官方博客。