那我為什么要寫(xiě)這個(gè)？

原因很簡(jiǎn)單——幾年前，我見(jiàn)證了設(shè)計(jì)一個(gè)為遙測(cè)事件提供模式管理設(shè)施的系統(tǒng)。事實(shí)證明，這比最初計(jì)劃的要昂貴得多。為什么呢？因?yàn)檫x擇了錯(cuò)誤的數(shù)據(jù)庫(kù)解決方案。

這個(gè)系統(tǒng)的一個(gè)要求是確保模式編輯是一致的，并且模式的最新版本被顯示給每個(gè)模式編輯器。它還應(yīng)該支持并發(fā)編輯。

此外，同時(shí)訪問(wèn)這個(gè)系統(tǒng)的用戶數(shù)量永遠(yuǎn)不會(huì)超過(guò)幾百個(gè)。存儲(chǔ)的數(shù)據(jù)量不會(huì)是Tb級(jí)——最多幾百Gb。

因此，如果我們考慮了CAP定理的權(quán)衡，那么選擇應(yīng)該是顯而易見(jiàn)的——使用RDBMS。這樣做的好處是支持系統(tǒng)的一致性和事務(wù)支持需求。

相反，選擇了NoSQL數(shù)據(jù)庫(kù)（Azure表存儲(chǔ)）來(lái)進(jìn)行原型設(shè)計(jì)。這一選擇的官方原因是，它使原型設(shè)計(jì)更快，并提供了更大的靈活性，同時(shí)更新了單個(gè)遙測(cè)事件的模式。與Azure SQL相比，Azure表存儲(chǔ)的低成本被認(rèn)為是另一個(gè)原因。

?

快進(jìn)5個(gè)月……

該系統(tǒng)開(kāi)始經(jīng)歷許多關(guān)于維護(hù)CRUD操作完整性的問(wèn)題。設(shè)計(jì)用來(lái)處理事務(wù)的瘦應(yīng)用程序邏輯層已經(jīng)不再那么薄了。升級(jí)和向后兼容性的故事開(kāi)始變得更加復(fù)雜。

由于受到許多其他問(wèn)題的困擾，工程師們又回到了繪圖板——這次是用Azure SQL替換存儲(chǔ)層！我不記得具體的細(xì)節(jié)，但是這個(gè)改變?cè)黾恿舜蠹s40%的額外時(shí)間和成本。

管理層很不高興，這個(gè)項(xiàng)目幾乎被砍掉了。但是團(tuán)隊(duì)的工程師們非常優(yōu)秀，他們能夠完成這個(gè)項(xiàng)目，盡管有了一些延遲和最初的錯(cuò)誤的技術(shù)決定。

這個(gè)項(xiàng)目有一個(gè)圓滿的結(jié)局——但它也可能不是這樣的。事實(shí)上，很多內(nèi)部項(xiàng)目都被關(guān)閉了，因?yàn)樗麄儾荒茉诔兄Z的日期范圍內(nèi)交付承諾的功能。

那么，您如何知道NoSQL解決方案適合您的下一個(gè)軟件項(xiàng)目呢？首先問(wèn)問(wèn)你自己和你的團(tuán)隊(duì)這十個(gè)問(wèn)題：

#1：您是否準(zhǔn)備好接受開(kāi)發(fā)人員/系統(tǒng)管理員的培訓(xùn)成本？

如果你是一家成熟的IT軟件開(kāi)發(fā)公司，那么你很有可能已經(jīng)有了熟悉SQL的人。這個(gè)組不僅包括開(kāi)發(fā)人員，還包括數(shù)據(jù)庫(kù)管理員（DBA）。

除非您打算為新的NoSQL項(xiàng)目進(jìn)行招聘，否則將會(huì)有對(duì)現(xiàn)有開(kāi)發(fā)人員和DBA的培訓(xùn)成本。額外的培訓(xùn)也可能會(huì)延長(zhǎng)項(xiàng)目交付日期。

一種簡(jiǎn)單的思考方式是：

• 計(jì)算您的團(tuán)隊(duì)成員（開(kāi)發(fā)人員和DBA）擁有關(guān)系數(shù)據(jù)庫(kù)技術(shù)的總年數(shù)。

• 計(jì)算出通過(guò)培訓(xùn)或新招聘獲得經(jīng)驗(yàn)相同NoSQL經(jīng)驗(yàn)?zāi)陻?shù)的成本。

• 最后，弄清楚你從這個(gè)成本中得到了什么。你的投資回報(bào)率？

在這個(gè)特定的項(xiàng)目中，這個(gè)團(tuán)隊(duì)的開(kāi)發(fā)人員以前都沒(méi)有NoSQL經(jīng)驗(yàn)，但是有大量的SQL Server經(jīng)驗(yàn)。使用NoSQL解決方案在培訓(xùn)中增加了大約1個(gè)sprint，當(dāng)然，這也是由于缺乏經(jīng)驗(yàn)和設(shè)計(jì)上的失誤。

#2：您的數(shù)據(jù)事務(wù)是基于什么？或者，您需要什么級(jí)別的事務(wù)支持？

如果您的系統(tǒng)需要ACID屬性，那么您最好還是堅(jiān)持使用RDBMS解決方案。否則，您將花費(fèi)大量的時(shí)間試圖在您的應(yīng)用程序/業(yè)務(wù)邏輯層復(fù)制ACID保證，并且您可能仍然沒(méi)有RDBMS解決方案那么高效。

#3: 您需要Web/高可伸縮性嗎？

總是在先計(jì)算出您需要什么樣的可伸縮性。在這個(gè)特殊的例子中，我們正在為微軟內(nèi)部游戲工作室構(gòu)建系統(tǒng)。

• 有10到15個(gè)游戲工作室正在考慮中——這取決于有多少注冊(cè)用戶使用這個(gè)系統(tǒng)

• 每個(gè)工作室最多有3-5個(gè)活躍的游戲標(biāo)題。

• 每個(gè)游戲標(biāo)題為三個(gè)環(huán)境存儲(chǔ)遙測(cè)模式——開(kāi)發(fā)、預(yù)生產(chǎn)（PPE）和生產(chǎn)

• 對(duì)于每個(gè)標(biāo)題，將會(huì)有2-5個(gè)數(shù)據(jù)科學(xué)家同時(shí)修改游戲標(biāo)題數(shù)據(jù)

• 每一個(gè)標(biāo)題事件都有大約50 KB的max事件數(shù)據(jù)

• 我們被要求存儲(chǔ)所有的版本——我們估計(jì)這個(gè)數(shù)字是1000除以一個(gè)標(biāo)題的生命周期

有了以上粗略的估計(jì)，我們就可以計(jì)算并發(fā)性和存儲(chǔ)需求：

總并發(fā)數(shù) = 工作室數(shù)量 * 標(biāo)題數(shù)量每工作室 * 用戶數(shù)量每標(biāo)題

=? 15 * 5 * 5 =?375 并發(fā)用戶

最大存儲(chǔ) =??工作室數(shù)量 * 標(biāo)題數(shù)量每工作室 * 環(huán)境數(shù)量 * 事件存儲(chǔ)大小每版本* 需要存儲(chǔ)的版本數(shù)

= 15 * 5 * 3 * 50 KB * 1000 = 11250000 KB =?11.25 GB最大存儲(chǔ)

SQL Azure支持1024個(gè)并發(fā)打開(kāi)連接，并且能夠很容易地支持并發(fā)需求。另外，在考慮云計(jì)算時(shí)，11.25 GB實(shí)際上是一個(gè)非常小的數(shù)字。

這個(gè)系統(tǒng)并不是下一個(gè)FaceBook或必應(yīng)——那么NoSQL的路線真的值得嗎？

#4：NoSQL解決方案真的能幫你省錢(qián)嗎？

在紙面上，Azure表存儲(chǔ)是一種更便宜的選擇，因?yàn)樗拿縂b數(shù)據(jù)僅為美分，而SQL Azure則在此期間收取大約5美元的數(shù)據(jù)。

但是因?yàn)槲覀兿到y(tǒng)的存儲(chǔ)空間不會(huì)超過(guò)12 GB——這真的很重要嗎？每月60美元是我們?cè)谕粋€(gè)系統(tǒng)上花30分鐘寫(xiě)代碼的錢(qián)。

因此，在決定使用NoSQL僅僅是因?yàn)樗膯挝怀杀靖椭?，先弄清楚?jié)省下來(lái)的錢(qián)是否占了預(yù)算的很大一部分。

#5：你需要吸引風(fēng)險(xiǎn)投資嗎？

有趣的是，硅谷對(duì)NoSQL有偏見(jiàn)。這是因?yàn)楦杏X(jué)上NoSQL被認(rèn)為具有內(nèi)在的可伸縮性，并且RDBMS被認(rèn)為是不可伸縮的。記住，關(guān)鍵字是“感覺(jué)上”！

這種可擴(kuò)展性的感覺(jué)可能會(huì)讓投資者相信，你的軟件正處于正確的軌道上，準(zhǔn)備好接受大規(guī)模的采用，從而吸引他們的投資資金。

許多NoSQL公司本身就是風(fēng)投公司，這也給他們帶來(lái)了積極的偏見(jiàn)。

最后，圍繞“NoSQL”的所有營(yíng)銷(xiāo)活動(dòng)都有助于推動(dòng)投資者對(duì)你的產(chǎn)品的正面情緒。

#6：你是在雇傭創(chuàng)業(yè)精神的人嗎？

如果你打算雇傭創(chuàng)業(yè)精神的人，他們中的很多人可能已經(jīng)有NoSQL的知識(shí)了。

然而，如果你不在一個(gè)主要的科技中心，那么獲得這些人才的機(jī)會(huì)就很少了。您所在的區(qū)域可能有一個(gè)現(xiàn)成的RDBMS開(kāi)發(fā)人員池——試圖在這樣的區(qū)域中招募NoSQL工程師和DBA可能會(huì)延遲項(xiàng)目交付日期，并且由于供應(yīng)需求曲線，也會(huì)花費(fèi)您更多的錢(qián)。

我的建議是與你的招聘機(jī)構(gòu)/人力資源部門(mén)合作，對(duì)開(kāi)發(fā)者進(jìn)行市場(chǎng)調(diào)查，并將其納入你的技術(shù)選擇中。

#7：你的客戶在下游使用什么技術(shù)？

考慮這樣一個(gè)場(chǎng)景：您向客戶交付分析數(shù)據(jù)。您正在使用NoSQL來(lái)存儲(chǔ)分析數(shù)據(jù)。然而，您的一個(gè)客戶決定堅(jiān)持使用基于SQL的報(bào)告系統(tǒng)。

這對(duì)你來(lái)說(shuō)意味著什么？

這意味著您現(xiàn)在需要將所有NoSQL數(shù)據(jù)轉(zhuǎn)換為SQL格式，并通過(guò)Azure數(shù)據(jù)工廠等服務(wù)將其向下推到客戶的SQL數(shù)據(jù)庫(kù)。這是您需要承擔(dān)額外的開(kāi)發(fā)和運(yùn)營(yíng)成本。如果您的所有下游客戶都在使用SQL，那么您需要認(rèn)真地考慮是否使用NoSQL和做所有這些昂貴的數(shù)據(jù)轉(zhuǎn)換對(duì)您的系統(tǒng)有意義嗎？

#8：對(duì)于你的產(chǎn)品，可用性是否勝過(guò)一致性？

如果你正在建立一個(gè)像Facebook newsfeed這樣的系統(tǒng)，你可能會(huì)希望這個(gè)系統(tǒng)是高可用性的，并且是最終一致。

另一方面，如果您正在構(gòu)建一個(gè)銀行系統(tǒng)（或者像我們的案例那樣的模式存儲(chǔ)），您可能希望支持強(qiáng)一致性，并放棄高可用性。

無(wú)論采用哪種方式，您都應(yīng)該首先考慮CAP定理的含義，然后決定您的系統(tǒng)是否需要SQL或NoSQL解決方案。

#9：您是否預(yù)期對(duì)數(shù)據(jù)庫(kù)模式進(jìn)行大量更改？

如果您期望對(duì)數(shù)據(jù)庫(kù)模式進(jìn)行大量更改，就像移動(dòng)應(yīng)用程序、實(shí)時(shí)分析、內(nèi)容管理系統(tǒng)等經(jīng)常發(fā)生的情況一樣，那么NoSQL解決方案可能就是一種方法。

您可以使用一個(gè)分區(qū)方案，它允許您以一種比大多數(shù)SQL數(shù)據(jù)庫(kù)允許的更方便的方式更新您的數(shù)據(jù)庫(kù)模式。

#10：你想用NoSQL來(lái)獲得個(gè)人的充實(shí)/滿足嗎？

請(qǐng)不要這樣做！

我曾見(jiàn)過(guò)一些人，他們只是迷戀于學(xué)習(xí)一個(gè)NoSQL系統(tǒng)，并將其放入他們的簡(jiǎn)歷中。這并沒(méi)有什么錯(cuò)——我對(duì)NoSQL技術(shù)也很著迷。

但是，請(qǐng)不要讓這成為選擇技術(shù)堆棧背后的驅(qū)動(dòng)因素（有意識(shí)的或下意識(shí)的）。如果你愿意的話，你可以在自己的時(shí)間里學(xué)習(xí)。

誰(shuí)贏得了數(shù)據(jù)庫(kù)戰(zhàn)爭(zhēng)？

坦率地說(shuō) – 沒(méi)有哪個(gè)玩家能贏者通吃!

在很多情況下，您可能需要SQL和NoSQL技術(shù)在同一系統(tǒng)中并存。 例如，如果您正在構(gòu)建像Instagram這樣的照片共享應(yīng)用程序，則您的照片可能位于NoSQL數(shù)據(jù)庫(kù)中，而您的登錄/ ACL信息可能位于SQL數(shù)據(jù)庫(kù)中。