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

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

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

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

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

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

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

然而，這里有幾個(gè)使用歸一化模型帶來(lái)的問(wèn)題：

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

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

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

這是我們實(shí)際使用的模型：

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

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

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

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

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

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

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

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

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

當(dāng)查詢時(shí)：

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