如果使用得當，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查詢，只做主鍵或者索引查詢。
</li> -
不要使用自增主鍵因為會有鎖，取而代之，使用客戶端生成鍵，比如GUIDs。同時，如果你使用主主備份，自增鍵還可能會沖突，因此你需要為每個實例都定制鍵的范圍。
</li> -
沒有索引的字段通通刪掉或者使用JSON集合成單一字段。
</li> </ul>在Wix，MySQL經常會被當做鍵值存儲，比如在一列中儲存JSON對象，從而在不改變數據庫模式下對數據結構模式進行擴展。在MySQL中，使用主鍵讀取也很快，Wix就通過這個方式獲得了亞毫秒級的讀取速度，完全可以支撐整個使用場景。基于以上這些原因，MySQL完全可以看作一個符合 ACID原則的NoSQL數據庫。至于數據庫的大小，一個MySQL實例支持幾億條數據是沒什么問題的。
關系型數據庫的一個鮮明的優勢是不用考慮最終一致性，而這個在NoSQL數據庫中并不是原生支持的。本文也不是貶低NoSQL，因為關系型數據庫已有限制也非常多：嚴格的數據結構和大小限制。這里只是想提醒開發人員，在選擇新技術時不要忽視運維成本。
</div> </div>
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！