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

前言

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

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

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

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

歸一化模型的問題

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

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

?

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

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

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

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

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

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

MySQL來作為引擎的優(yōu)勢

在Wix，我們發(fā)現，當我們“有創(chuàng)造性的”使用MySQL作為鍵值存儲時，能夠提供比上面提到的使用歸一化數據模型或者其它大多數NoSQL數據庫引擎更好的性能。簡單的使用MySQL來作為NoSQL引擎，我們現有的系統(tǒng)，無論是在伸縮性、吞吐量、并發(fā)和延遲指數上，相較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值。

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

?

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

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

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

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

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

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

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

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

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

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

• 不使用歸一化模型

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

• 不要使用外鍵

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

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

當查詢時：

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

• 避免使用表連接

• 避免使用聚合函數

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

總結

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

總結

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

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