哈哈，如果使用得當，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，因為關係型資料庫已有限制也非常多：嚴格的資料結構和大小限制。這裡只是想提醒開發人員，在選擇新技術時不要忽視運維成本。