綜上所述：

NoSQL數(shù)據(jù)庫更具可擴展性并提供更好的性能，并且它們的數(shù)據(jù)模型更接近應(yīng)用程序內(nèi)部使用的域模型?；贜oSQL數(shù)據(jù)庫啟動項目的公司數(shù)量正在增長。NoSQL數(shù)據(jù)庫也往往是開源的，這意味著開發(fā)，實現(xiàn)和共享軟件的成本相對較低。

NoSQL的限制

在評估NoSQL數(shù)據(jù)庫的局限性時，重要的是要記住NoSQL世界是一個多樣化的生態(tài)系統(tǒng)。并非所有NoSQL存儲產(chǎn)品都具有相同程度的所有缺點。這是一件好事，因為這意味著在權(quán)衡不同NoSQL解決方案的優(yōu)缺點時，組織有很多選擇，以決定哪一個最適合他們的特定需求。本章總結(jié)了使用NoSQL解決方案可能會遺漏的一些功能。

通過閱讀這篇文章，你會發(fā)現(xiàn)本章擴展的不僅僅是優(yōu)勢之一。這不是阻止使用NoSQL的方法。本章將對NoSQL技術(shù)的所有限制進行公正的描述，并且只是想讓您了解使用它們時可能遇到的每個問題。許多要點可能會因?qū)嵤┒兴煌?，當我說支持的工具很少時，大多數(shù)工具都適合，但并非所有工具都適用），因此請將它們視為一個概述，提醒您可能存在的風險找。我期望的是，在您選擇使用NoSQL產(chǎn)品之后，您可以使用本章作為核對表來了解您的特定數(shù)據(jù)庫中是否存在此問題以及它是否與應(yīng)用程序相關(guān)。

安全

安全是每個人都想要的，但很難達到。從理論上講，每種技術(shù)都可能存在安全問題。SQL系統(tǒng)上也存在安全問題，也許存在安全問題。那么為什么我將此標記為NoSQL的可能問題？

關(guān)于安全性的NoSQL“概念”沒有真正的問題，但我們可能會遇到與我們采用的產(chǎn)品的成熟度相關(guān)的安全問題。產(chǎn)品增長時出現(xiàn)安全問題，然后修復(fù)。直觀地說，年輕的產(chǎn)品可能有許多未知的安全問題。此外，一個年輕的產(chǎn)品在市場上銷售的時間較短，因此顧問沒有時間獲得它們的經(jīng)驗，許多安全限制可以忽略不計。所以，問題是大多數(shù)NoSQL平臺的新特性。對于商業(yè)用途，我建議只使用成熟的解決方案，背后有供應(yīng)商。

數(shù)據(jù)一致性

當我們開始學(xué)習RDBMS時，他們告訴我們ACID事務(wù)是使整個數(shù)據(jù)庫保持一致的操作的最佳選擇。好吧，大多數(shù)NoSQL技術(shù)都沒有實現(xiàn)這種交易。NoSQL系統(tǒng)基于最終一致性原則。在實踐中，擁抱一點風險（一個節(jié)點可能與其他節(jié)點不同步），它們會獲得一些性能提升。是的，這是妥協(xié)，但我們不能擁有一切。

我必須提到一些NoSQL實現(xiàn)，比如FoundationDB，允許類似ACID的事務(wù)保持NoSQL性能高。順便說一下，當我們繼續(xù)使用NoSQL時，數(shù)據(jù)一致性仍然是一個關(guān)鍵部分：基于您正在開發(fā)的應(yīng)用程序，這可能是一個問題。

JOIN的

當您與試圖將您轉(zhuǎn)換為NoSQL技術(shù)的人交談時，您可以從中聽到的第一個好處之一是由于刪除關(guān)系而帶來的性能優(yōu)勢。我們都同意一種關(guān)系可能會降低性能，但我們會失去什么呢？

想象一下，你在徒步旅行時背著沉重的背包。當然，放棄它你會更快。這樣做很方便嗎？取決于這個包裝包含什么，這取決于背包內(nèi)容的價值是什么。如果它包含一個夜晚的帳篷，也許最好在一小時后到達目的地，但要保持溫暖而不是走得更快。如果你帶來有用的一次性用品，也許你可以做相反的事情。

遵循這種并行性，我們是否可以接受松散的一致性以獲得性能？方便值得嗎？

退后一步，我將從連接的起源開始。RDBMS使用該關(guān)系將數(shù)據(jù)從一個表鏈接到另一個表，以將數(shù)據(jù)保存在一個位置而不復(fù)制它們。構(gòu)造連接以允許我們在查詢中重新連接它們。當然，在表之間進行連接需要額外的計算成本，而不是直接在要查詢的表中查找數(shù)據(jù)。但是這個成本對于保持關(guān)系（沒有復(fù)制，一致性）是必要的。

很明顯，雖然這個功能有可接受的開銷，但這沒關(guān)系，可能是最好的選擇。但什么時候它減慢了一切或需要太多的硬件？這個問題允許NoSQL開發(fā)人員聲稱缺少JOIN到一個功能，但NoSQL始終是解決方案嗎？

不總是。有時我們只需要重新設(shè)計數(shù)據(jù)庫結(jié)構(gòu)，可能會刪除一些關(guān)系或重組數(shù)據(jù)。是的，我們將失去一些關(guān)系，或者我們將復(fù)制日期的某些部分，但它可以接受（在NoSQL中我們將失去所有的關(guān)系）。

另一個問題是一致性?？紤]類別和產(chǎn)品。我們可能有一個嵌套的類別樹，許多產(chǎn)品作為樹的葉子。在傳統(tǒng)的RDMS中，更改類別樹只是對類別表上的外鍵（自我關(guān)系）的更新。這些更改會自動反映所有子類別和產(chǎn)品。在NoSQL中，我們可以在所有類別/產(chǎn)品上擁有冗余數(shù)據(jù)，并且需要對子元素進行大量更新。

棘手的交易

讓我假設(shè)我們的應(yīng)用程序可以放棄JOIN以獲得速度，在我們的例子中，這是一個可接受的權(quán)衡。我們說過，在許多NoSQL實現(xiàn)中，很難保持各種條目的一致性。當您在沒有事務(wù)的情況下工作時，您可以按順序執(zhí)行許多操作，但過了一段時間后會出現(xiàn)不一致 這對于NoSQL的第一次實現(xiàn)是正確的，并且一些新技術(shù)試圖給出事務(wù)。您還可以考慮在應(yīng)用程序級別管理事務(wù)，嘗試回滾臟數(shù)據(jù)，但在許多情況下可能很難管理。

缺少供應(yīng)商技術(shù)的標準

SQL是一種標準語言?？赡軙性S多變化帶來特定的方言，但這很復(fù)雜并不禁止抽象數(shù)據(jù)訪問。想想Hibernate，NHibernate，Doctrine，Entity Framework或其他ORM。它們證明了SQL方言之間的區(qū)別并不重要。我們可以得出結(jié)論，即使許多供應(yīng)商實現(xiàn)了不同的數(shù)據(jù)庫技術(shù)，SQL也是一種標準語言。此外，如果您不是基于ORM層，如果您為DB生成查詢，則大多數(shù)代碼可以在其他代碼中重用。這使遷移更容易，開發(fā)人員可以快速適應(yīng)不同的DB解決方案。

另一方面，在NoSQL世界中，存在更多混亂。每個供應(yīng)商實現(xiàn)其特定語法，而不涉及任何共享標準。這意味著在不同的NoSQL實現(xiàn)之間遷移應(yīng)用程序更加困難。這意味著找到一個熟悉許多NoSQL技術(shù)的程序員更難。

架構(gòu)靈活性可能是一個麻煩

NoSQL系統(tǒng)的一個特點是它們不需要架構(gòu)。在實踐中，程序員在保存數(shù)據(jù)時決定數(shù)據(jù)結(jié)構(gòu)。因此，沒有任何地方可以寫出數(shù)據(jù)的結(jié)構(gòu)以及數(shù)據(jù)的含義。即使您可以使用某種自動化工具輕松地從數(shù)據(jù)關(guān)系重新創(chuàng)建數(shù)據(jù)庫模型，這可能是傳統(tǒng)應(yīng)用程序中缺少的。

而且，如果發(fā)生錯誤怎么辦？我們知道可能存在代碼出錯的情況。傳統(tǒng)的RDMS是腳手架，因此如果您切換某些字段或者您的字段格式錯誤，它們可以保護您免受不一致。在NoSQL的情況下，DB沒有任何幫助，因為沒有定義任何模式，沒有任何關(guān)于數(shù)據(jù)的信息應(yīng)該保存：沒有人可以說數(shù)據(jù)是否錯誤。最糟糕的副作用是，該過程為開發(fā)人員帶來了很多權(quán)力和很多責任，通常不了解所有流程或完整結(jié)構(gòu)。

而且，即使你現(xiàn)在知道什么是保存的，你認為你會記得下個月的所有內(nèi)容？和第二年？并非所有項目都需要持續(xù)開發(fā)，在我們需要進行一些更改之前，可能會有一個業(yè)務(wù)應(yīng)用程序保持原樣多年。

在IT部門，公司通常會將項目委托給某個供應(yīng)商，因此必須考慮這一部分，以確保在項目結(jié)束時輕松移交，可能要求準確記錄有關(guān)數(shù)據(jù)的結(jié)構(gòu)以及每個字段/集合的含義。與模式靈活性相關(guān)的最后一個問題是團隊中的每個成員都無法在項目中工作，因此，對于小團隊來說，流量是至關(guān)重要的并非所有成員都對數(shù)據(jù)結(jié)構(gòu)有完整的了解，或者沒有足夠的文檔。

Analytics（分析）

將多個嵌套數(shù)據(jù)保存在單個文檔中可能會丟失“SUM”，“COUNT”等分析功能。在第一次應(yīng)用程序開發(fā)期間這可能不是問題的壞事，但有人可能會在稍后詢問某些報告，那么在這種情況下該怎么做？在填充數(shù)據(jù)庫之后很難改變數(shù)據(jù)結(jié)構(gòu)，并且由于明確定義的數(shù)據(jù)結(jié)構(gòu)的泄漏，這樣做可能具有不可預(yù)測的影響。分析對于NoSQL來說是一個難點。

此外，雖然有許多商業(yè)工具可以連接到傳統(tǒng)數(shù)據(jù)庫來管理分析部分，但對NoSQL系統(tǒng)的支持有限。

可以采取的另一個解決方案是在NoSQL DB中復(fù)制某種與非結(jié)構(gòu)化數(shù)據(jù)的“關(guān)系”，可能會創(chuàng)建許多集合并將對象與其他集合鏈接起來。如果您計劃遵循此路徑以允許分析報告，請記住，這可能會降低性能，使其與標準SQL系統(tǒng)相媲美。當此DB中涉及的部分最小且記錄數(shù)量有限時，這是可以接受的。無論如何，即使根據(jù)我的經(jīng)驗，構(gòu)造允許加入NoSQL查詢的數(shù)據(jù)，因為背后沒有明確定義的關(guān)系，非常有限并且性能不如我們預(yù)期的那么好（即，在撰寫本文時） ，MongoDB不支持內(nèi)連接，每次只能進化到表而不創(chuàng)建臨時表）。

更少的工具

我們談到了NoSQL查詢語言和語法缺乏標準化。這個問題也可以反映在工具中，以及大多數(shù)平臺的年輕性。我說的是用于查詢的工具，也用于在數(shù)據(jù)庫之間遷移數(shù)據(jù)，管理備份等。當然，大多數(shù)NoSQL項目正在增長，我們期望工具會隨之增長，所以這個問題會在某些時候自動解決。

缺乏標準化使第三方供應(yīng)商難以構(gòu)建可支持多種NoSQL解決方案的工具。此外，年輕平臺意味著更少的用戶，更少的客戶，更少的時間來開發(fā)成熟的工具。

性能比較

指定比較的方式很重要。首先，我需要將兩種解決方案置于相同的條件下。這意味著，例如，使用相同的硬件并具有相同的調(diào)整級別。所以我在同一臺機器上安裝了MongoDB（最新版本）和SQLServer Express。因為我們對數(shù)據(jù)庫本身的性能不感興趣，所以我使用基于標準框架的C＃代碼構(gòu)建了我的基準測試。

通過這兩種方式來保存數(shù)據(jù)，一切都是共享的（實體，邏輯，數(shù)據(jù)生成）以確保公平。

我們將比較的所有操作列表：

• 質(zhì)量插入
• 詢問
• 分析
• 事務(wù)（或更好，在NoSQL情況下，事務(wù)模擬）

對單個實體的批量操作

該基準測試包含一組可在較短時間內(nèi)插入的對象。使用越來越多的項目來復(fù)制此測試以保存以證明兩個系統(tǒng)中的性能規(guī)模。該基準測試以毫秒為單位測量執(zhí)行時間，并堅持使用單個表/集合。

搜索

此基準測試側(cè)重于查詢功能。我們將以下模式分開：

• CASE 1使用主鍵獲取一個實體：此模式用于從DB獲取單個實體，使用唯一標識符
• CASE 2完全掃描失敗：當您要查找已刪除的元素時，數(shù)據(jù)庫必須在回復(fù)“否”之前掃描所有索引。
• CASE 3分頁查詢：一個復(fù)雜的查詢，其中有一些過濾器，一個訂單條件，并且您只想獲取一頁數(shù)據(jù)。

我創(chuàng)建了一些基準模擬上面不同比例的模式。在一個示例中，第一個基準假定5％的類型1的查詢，70％的類型2和25％的類型3.該基準測量以ms為單位的執(zhí)行時間。此基準測試堅持使用單個表\集合。

您可以在git-hub上找到用于執(zhí)行這些測試的所有代碼。

第一個測試是在“小”數(shù)據(jù)集上，大約2.500,000行。

對“更大”的數(shù)據(jù)集進行第二次測試，大約5M行。

此基準測試突出顯示了對索引的查詢性能的重大改進，但是當使用MongoDB讀取一組數(shù)據(jù)時，增益會降低并且在數(shù)據(jù)增加時保持穩(wěn)定。

交易

我們知道NoSQL世界的事務(wù)大多不受支持。我們也明白放棄交易可以從表演中獲益，一個問題是：我從中獲得多少收益？我構(gòu)建了這個基準來比較插入與一個與許多孩子相關(guān)的主行的事務(wù)?；鶞蕼y試的重點是執(zhí)行時間，以ms表示。

Analytics（分析）

該基準專注于分析。假設(shè)我們有一個分類的主 - 詳細數(shù)據(jù)模型，您希望：

• export：整個加入整體數(shù)據(jù)樹
• 報告：匯總所有類別的所有項目，即為所有客戶提供發(fā)票金額
• 關(guān)鍵績效指標：總結(jié)所有總計總計詳細小計

在內(nèi)連接后的4M行的基礎(chǔ)上：

興趣點

革命在科技領(lǐng)域是不可避免的。新技術(shù)帶來了一些革命性的功能，但往往不得不打敗開發(fā)人員的先入之見。有時他們會被誤解，所以他們的弱點在他們受雇后就會出現(xiàn)。

關(guān)于創(chuàng)新，我們必須“對立”人群：

1. “熱心”的人：希望無條件地接受變革，并準備好處理過去所做的一切，以便使用最后的技術(shù);
2. “保守派”人：討厭改變，寧愿保持其習慣，拒絕任何新技術(shù)。

在現(xiàn)實生活中，我們必須保持中間位置，因此了解和了解新技術(shù)可以為我們做些什么并準備好在項目需要之前采用新技術(shù)非常重要。“在工作中進行審判”是一種可能導(dǎo)致不良后果的壞習慣。

同樣的原則適用于NoSQL技術(shù)。因為我們之前看過NoSQL，現(xiàn)在我們知道贊成和利弊，所以我們可以利用這種工具。當我們分析這項技術(shù)時，我們不能停止從傳統(tǒng)習慣（如交易，模式和標準）中看到我們想念的東西。我們需要研究和熟悉這些技術(shù)，這些技術(shù)在幾年前還很年輕，但現(xiàn)在卻是一個具體的選擇。學(xué)習，學(xué)習，理解，使用：這是進步的本質(zhì)。

什么時候我應(yīng)該使用NoSQL Db？

為什么NoSQL會比使用SQL數(shù)據(jù)庫更好？閱讀完本文后，我確信您會理解NoSQL不是SQL數(shù)據(jù)庫的替代品，而是具有不同功能的不同存儲系統(tǒng)，并且在某些特定領(lǐng)域中非常有用。所以答案不能與“它取決于”有所不同。因為它取決于項目的許多特征。

說實話，謹慎，當以下所有陳述都成立時，NoSQL是最佳解決方案：

• 當您的項目需要擴展時，或?qū)砜赡堋?/li>
• 當你必須處理大數(shù)據(jù)時，或者你的數(shù)據(jù)在不久的將來會變得很大
• 當應(yīng)用程序中的分析組件簡單或不那么重要時
• 當您的應(yīng)用程序需要適合數(shù)據(jù)庫目的時（即您在圖表和數(shù)據(jù)庫中保存數(shù)據(jù)）

在某些情況下，NoSQL可能是一個很好的選擇，但對于構(gòu)​​建耐用的基礎(chǔ)架構(gòu)并不是必不可少的。當然，如果在您的應(yīng)用程序中，NoSQL系統(tǒng)覆蓋了99％的所有需求，則沒有理由將其與RDBMS結(jié)合使用。但是，如果您需要標準RDBMS的關(guān)系，事務(wù)和其他功能，可能最好將它們用作主存儲系統(tǒng)，并使用NoSQL僅覆蓋關(guān)鍵部分（可能源自數(shù)據(jù)的大?。?。

在上面的情況下，表現(xiàn)有多好？

這取決于具體的用例。從一方面來說，我們在大型表或大量使用方面有很多好處，但從另一方面來說，我們使用查找而不是加入小型數(shù)據(jù)集會有一些性能損失。一個現(xiàn)實的估計，如果有使用NoSQL DB的基礎(chǔ)，我們可以將性能從10提高到100。當然，這種估計考慮了應(yīng)用程序的所有方面，并且與最終用戶體驗有關(guān)。這意味著您可以在數(shù)據(jù)庫層上測量更好的加速，但最終用戶體驗會因許多減少差距的因素（緩存，網(wǎng)絡(luò)延遲，頁面呈現(xiàn)）而失真。

只是為了解釋我所說的內(nèi)容，當有一個頁面進行查詢并返回數(shù)據(jù)時，請參考示例中的極限情況。假設(shè)此頁面使用傳統(tǒng)數(shù)據(jù)庫獲取結(jié)果為500毫秒，使用NoSQL為50毫秒，渲染頁面為200毫秒，通過互聯(lián)網(wǎng)傳輸數(shù)據(jù)為1秒。DB層的性能提升為-90％，但對于最終用戶，1700只增加了450ms，因此只有26％。通過這個例子，我會解釋說很難衡量復(fù)雜系統(tǒng)的改進，在很多情況下，NoSQL還不足以解決性能問題。更直接的是，如果您考慮解決因遷移到NoSQL的應(yīng)用程序中的設(shè)計不良而導(dǎo)致的性能問題，那么您就沒有走上正確的道路。

但最大的問題是：為了獲得這種表現(xiàn)，我失去了什么？因為在某些情況下，不可能放棄某些功能，如交易或關(guān)系。在移動之前理解這一點非常重要。

NoSQL系統(tǒng)在生產(chǎn)環(huán)境中應(yīng)用是否成熟？

這主要取決于您的需求，或更好地取決于項目要求。我們可以說NoSQL肯定足夠成熟。所以，如果你需要它，你可以毫無顧慮地使用它。但并非所有應(yīng)用程序都需要處理大數(shù)據(jù)或大規(guī)模擴展。大多數(shù)Saas產(chǎn)品確實如此，在企業(yè)環(huán)境中也有很多關(guān)鍵應(yīng)用程序，但現(xiàn)在大多數(shù)應(yīng)用程序仍然非常簡單。

根據(jù)我的經(jīng)驗，很難在數(shù)據(jù)庫中找到超過10萬行的表。想想你的數(shù)據(jù)庫，排除你上面的2-3個更大的表并查看行數(shù)。它們有多大？DB應(yīng)用程序上的常用DB結(jié)構(gòu)計數(shù)很多“小”表（小于10萬行）相關(guān)。對于這種類型的應(yīng)用程序，傳統(tǒng)的RDBMS就足夠了，它將永遠存在。重要的是，而不是開始使用它，就是要了解在您的案例需要時準備好的利益和發(fā)展模式。

SQL過時了嗎？

當男人發(fā)明飛機時，汽車已經(jīng)過時了？不，當然。如果飛機比汽車快。它們只是兩種不同的系統(tǒng)來移動人，具有不同的特征。根據(jù)您的旅行類型，您在旅行和預(yù)算上花費的時間，您將決定什么是最適合您的選擇。同樣，NoSQL即將推出過時的SQL。它們只是兩種不同的存儲數(shù)據(jù)的方式，具有不同的特征。您將根據(jù)自己的需求決定什么是最適合您的。

SQL不適合存在問題，因此您不必使用它來啟動大數(shù)據(jù)項目。這將是試圖用汽車而不是飛機到達島嶼。但SQL仍然有其優(yōu)勢。許多數(shù)據(jù)模型最好表示為相互引用的表的集合。這就像試圖用飛機去買牛奶一樣。NoSQL數(shù)據(jù)庫不是SQL的替代品，但它們是替代品。

市場是否為NoSQL做好準備？

回答這個問題的關(guān)鍵點是更接近開發(fā)人員實現(xiàn)的經(jīng)驗。大多數(shù)數(shù)據(jù)庫程序員都接受了一年的培訓(xùn)，以便相關(guān)地思考數(shù)據(jù)。他們?nèi)绾卧谶@么短的時間內(nèi)改變思維方式？它并不容易，特別是當開發(fā)人員必須在許多項目中工作時，其中一些是SQL和其他NoSQL。將SQL上的相同模式復(fù)制到NoSQL系統(tǒng)的誘惑很難被擊敗，并且經(jīng)常會導(dǎo)致糟糕的結(jié)果。

實際上，有更多的SQL專有技術(shù)，RDBMS上的開發(fā)人員比NoSQL更多。同時，DBA花費大部分時間專注于關(guān)系數(shù)據(jù)庫，我們不能指望在不到十年前出生的技術(shù)上找到相同的東西。在學(xué)校和大學(xué)都達到了SQL，NoSQL正在開始。

在第一點之后，第二點是，因為這些系統(tǒng)較新，開發(fā)工具較少，或者它們不像其他系統(tǒng)那么先進，但我確信這不是一個真正的問題。有一些“企業(yè)就緒”的解決方案，它提供了管理所有基本需求的工具，我們希望這些工具隨著平臺的發(fā)展而增長。

什么是最好的解決方案？

沒有涵蓋任何案例的最佳解決方案。答案很簡單，但仍然相同：“這取決于”。通過本文，我希望能夠概述這些系統(tǒng)的所有功能以及了解它們何時有用的一些基礎(chǔ)知識。