轉載自??為什么MySQL將會是一個更好的NoSQL

前言

MySQL是一個更好的NoSQL數據庫。當考慮到NoSQL的使用案例，比如對Key/Value鍵值存儲來講，MySQL在性能、易用性和穩定性方面更有意義。MySQL畢竟是一款成熟穩定的產品，在互聯網上有大量的在線教程，范圍從操作到失敗案例，從主從復制到其它不同模式的應用，不一而足?；谶@個原因，MySQL相比其他新興并沒有經過多年洗禮的NoSQL來講，確實有一定的優勢。

近些年來，NoSQL慢慢成為了主流。許多開發者把這些NoSQL數據庫，比如MongoDB、Cassandra、Redis或者Hadoop等，當作他們構建應用的數據庫首選，而把老舊的傳統數據庫廢棄不用。

選用NoSQL數據庫，經常是建立在其不實或者夸大的宣傳，和對傳統關系型數據庫性能不佳的假定上。開發者在選擇數據庫時，會特別看重操作成本，以及穩定性和成熟性。更多的不同NoSQL和關系型數據庫的局限對比，可以參考Aphyr上Jepsen的一些列文章。

這篇文章會解釋給大家為什么我們發現MySQL對于鍵值存儲場景來說，比大多數專有NoSQL引擎還要好。另外，本文也會提供給大家在MySQL中此應用的參考。

歸一化模型的問題

當用戶點擊一個鏈接到Wix網站時，他/她的瀏覽器會發送一個帶有網站地址的HTTP請求給Wix的服務器。無論是自定義域名（比 如：domain.com）請求一個Wix的優質地址，還是一個在Wix域名下的免費的子域名（比如：user.wix.com/site），這個 HTTP請求都會發生。服務器不得不在網站地址中執行鍵值查詢來處理用戶對某個地址的請求。我們用路由來表示URL，進行下面的討論。

路由表用于將站點地址解析為一個站點對象。因為站點可以暴露在多個路由中，所以是多對一的關系。一旦網站被發現，則應用將其加載以備使用。站點對象本身具有 復雜的結構，其中包涵兩個子列表，列表中的對象表示了站點使用的不同服務。下面是一個對象的模型圖，假設使用了標準SQL數據庫和歸一化模型：

?

當使用傳統的歸一化模型更新網站時，我們需要一個事務來更新多表，以確保保持數據一致性（注意，這里的事務使用的是數據庫級別的鎖來避免并發寫，有些時候用 來避免在受影響的表中并發讀）。繼續使用這一模型，我們可能會有每張表的串行鍵、外鍵以及在路由表中對于URL列的索引。

然而，這里有幾個使用歸一化模型帶來的問題：

• 數據庫鎖限制了對表的訪問，所以在高吞吐量的場景下，我們的性能可能會受一些影響

• 讀取對象涉及幾個SQL查詢(在本例中使用了4個)或聯接——再次影響了延遲

• 串行鍵施加鎖和再次限制寫入吞吐量

這些問題相當于限制了我們使用MySQL（或者其它任何SQL引擎）時的吞吐量和并發。因為這些短板，外加事實上我們需要的是鍵值存儲，所以許多開發者傾向于使用NoSQL作為解決方案以提供更高的吞吐和更多的并發，甚至是更好的穩定性、一致性和高可用。

MySQL來作為引擎的優勢

在Wix，我們發現，當我們“有創造性的”使用MySQL作為鍵值存儲時，能夠提供比上面提到的使用歸一化數據模型或者其它大多數NoSQL數據庫引擎更好的性能。簡單的使用MySQL來作為NoSQL引擎，我們現有的系統，無論是在伸縮性、吞吐量、并發和延遲指數上，相較NoSQL都具有令人驚艷的性能。 下面列舉一些數據：

• 橫跨三個數據中心的異地多活

• 吞吐量在200，000RPM的數量級

• 路由表記錄在100，000，000的數量級，10GB的存儲

• 站點表記錄在100，000，000的數量級，200GB的存儲

• 讀延遲平均在1.0-1.5毫秒（事實上，在一個數據中心，延遲為0.2-03毫秒）

值得注意的是，對于絕大多數的鍵值引擎，無論是開源數據庫還是云數據庫，1.0毫秒的延遲被認為是相當令人驚訝的水平。然而我們用MySQL就實現了這一壯舉（考慮到還使用了基本的SQL引擎）

這是我們實際使用的模型：

?

?

任何未被當做查詢條件的字段，都被放置在一個單一的blob字段（上面的site_data字段）。其中包含子對象表，和其他表本身的字段。另外注意，我們 并未使用串行鍵，相反的，我們使用了一個varchar(50)的字段，用于存儲客戶端生成的GUID值。

下面是我們使用的一個查詢，具備高吞吐的同時，還具備了低延遲：

?

工作原理是這樣的，首先使用唯一索引在路由表上執行查詢，應該盡的到一條記錄。接著使用這條記錄的主鍵，在站點表執行查詢，返回的記錄也是一條。

嵌套的查詢語法可以確保這兩個 SQL查詢僅在數據庫記錄中查詢一次。

上面的結果顯示，平均延遲在1毫秒以下，并且在高流量和高更新率的情況下能保證一致性。雖然沒有使用事務，但是update卻是半事務的。因為我們在一條插入語句中輸入了完整的網站地址，直到進入路由表，這條記錄才會被發現。

所以如果我們首先輸入了站點網址，然后是路由，我們就能確保有一個一致性的狀態，即使是在最邊緣的情況下，我們也僅僅是在站點表中有一些“孤兒”數據。

使用從上面例子（或者在Wix的其它案例）中的到的經驗，我們簡要的列舉出了一個使用MySQL當做NoSQL引擎使用的參考。

當使用MySQL當做NoSQL引擎使用時，首先要記住的一點是避免使用數據庫級別的鎖或者是復雜查詢：

• 不要使用事務，因為事務引入了鎖。相反的，使用應用來控制事務

• 不要使用串行鍵。串行鍵引入了鎖和其它敷在的啟動配置

• 使用客戶端生成唯一鍵，我們使用了GUID

當為優化讀設計模型時，鞋面是額外的一些經驗僅供參考：

• 不使用歸一化模型

• 所有的字段在被索引時才有必要存在。如果字段在查詢時不需要，則將其放到一個blob/text字段中（如JSON或者XML）

• 不要使用外鍵

• 設計你的模型，來確保查詢時僅讀取單獨的一行

• 不要在表上使用alter命令。修改表的命令引入了鎖和停機時間，相反的，嘗試使用實時遷移

當查詢時：

• 使用主鍵或者索引查詢記錄

• 避免使用表連接

• 避免使用聚合函數

• 盡量在從庫上執行較為復雜的查詢（如BI，數據研究等），避免在master數據庫上執行上述操作

總結

最值得在這篇文章中看到的是如何打破思維嘗試不同的思考。使用MySQL來當做NoSQL引擎，看起來是不錯的，雖然MySQL最開始并不是為此而設計的。 本文中演示的，是一個使用MySQL而不是NoSQL引擎來構建鍵值訪問。在Wix，MySQL是我們的鍵值存儲場景的選擇是因為操作簡單、使用簡單，并且MySQL本身有極好的生態。此外，MySQL還能提供額外的低延遲、高吞吐和數據一致性保證。

總結

以上是生活随笔為你收集整理的为什么MySQL将会是一个更好的NoSQL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。