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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當查詢時：

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