近年來，我們目睹了NoSQL的興起，並觀察它在各種應用中的應用。本文旨在對SQL和NoSQL技術進行客觀比較，並嘗試澄清一些不明確的方面，以幫助人們熟悉地選擇後端。

我對NoSQL的態度

一切都有時間，2014年我開始使用NoSQL。也許我遲到了，但我之前的項目需求完全被傳統數據庫所滿足，所以我沒有被迫學習NoSQL。

NoSQL技術被神祕的光環所包圍。我第一次發現開發人員有一件名為“NoSQL”的東西，他穿著一件帶有“向我詢問MongoDB”標記的T恤。我當時沒有問過。我被答案嚇到了，我畫得很長很複雜。然後我看到兩個不同的方面：誰是NoSQL的重要推動者，他們討厭舊數據庫，而傳統開發人員則拒絕NoSQL的所有好處。

當我意識到這種情況時，我確信我會發現並學習。這讓我進入了一個小項目，我將這兩個解決方案與基準進行比較，以顯示NoSQL的所有優點和限制。最後，我理解NoSQL和SQL只是為不同項目設計的不同工具（即使在某些情況下你需要兩者）。五年後，我無法確定文化差距是否已經填補。這就是為什麼我刷新文章，切割無聊的部分，我在這裡重新發表。

什麼是NoSQL

簡單來說，NoSQL是一個不遵循關係數據庫模型的新數據存儲後端。這意味著我們所說的“容器”與傳統的基於SQL的後端的工作方式不同。

NoSQL技術的誕生是為了滿足傳統數據庫已經成熟時出現的一系列新需求。當然，在最近幾年，應用程序需求發生了變化，變得更加挑剔（大數據，集群，文件存儲庫），因此這個新的存儲系統的設計考慮到了這些新的需求。

但是，我的意思是“要求”？這裡有一組NoSQL旨在支持的案例。

• 該應用程序使用大量數據（大數據）
• 該應用程序使用快速更改關係和數據類型（半結構化，非結構化和多態數據）的數據。
• 開發人員使用敏捷方法在一個小團隊中工作：針對長期瀑布迭代的許多小衝刺
• 作為服務的應用程序可以在Web上發佈
• 為數千名用戶而非公司內部的少數人提供的應用程序
• 對應用程序的未來負載一定不確定：需要具有可擴展性和動態性，需要輕鬆地在後端集群上使用基礎軟件

市場上提供了許多NoSQL解決方案，無論是開源還是非開源。它們中的每一個都有所不同，可能專門針對某些特定需求，但基本思想和共同特徵是提供更好的可擴展性和性能。為此，他們放棄了通用RDBMS的一些功能，引入了新功能，但保留了足夠的功能。

NoSQL實現

SQL DB的一個重大變化是SQL後端是一個通用存儲系統，NoSQL分發專注於特定類型的數據。這允許DB在其範圍內更有效，並允許我們擁有更高性能的系統。在本節中，我們將討論NoSQL數據庫的應用程序。請注意，它們可以一起使用（也可以與傳統的SQL系統一起使用），以便從不同的技術中獲得最佳效果。

文檔導向

這種類型的數據庫不需要具有一致的數據結構，因此當您必須處理多態數據或數據結構不斷變化時，它們非常有用。這種後端可以將標準化實體（如鍵值數據集或EAV模型）轉換為簡單的文檔集。

• 目標：存儲非類型的“記錄”集，稱為“文檔”
• 示例： MongoDB，CouchDB
• 目標：異構數據，面向工作，敏捷開發

圖數據庫

我們被告知NoSQL數據庫已經刪除了關係的概念以實現更好的性能。在這種DB中，這不是真的。相反，圖形數據庫強制執行關係概念。

他們的目標是通過與其他數據的關係來定義數據。當大多數數據結構被設計為保持與實體的關係時（即，當存在大多數外鍵列時，如果有很多表），這種數據庫可能很有用。

• 目標：描述數據關係
• 示例： Neo4j，GiraffeDB。
• 目標：數據挖掘

鍵值商店

這是一種用於存儲大量鍵值對數據的DB。當數據庫用於存儲屬性，轉換或緩存目的時，這可能很有用。

• 目標：以鍵值形式存儲數據
• 示例： Redis，Cassandra，MemcacheDB
• 目標：鍵值存儲

NoSQL的優點

我們知道NoSQL DB有一些有趣的優點，它們可以解決傳統RDMS無法解決的問題。如今，他們在關鍵系統中的大量工作，如大型雲系統和一些大型SaaS產品，確認它們已經成熟且有用。但問題是，為什麼我應該轉向他們？在這種情況下，何時移動有利可圖？我們不能只根據我們的印象做出這樣的決定，並閱讀一些供應商宣傳冊，其中NoSQL非常酷是不夠的。而且，我們不能因為害怕變化而停留在不充分的平臺上。

在本節中，我將嘗試解釋為什麼這個解決方案可以很好地轉移到哪個用例使其更有利可圖。

正如我們所說，NoSQL數據庫的創建是為了響應傳統關係數據庫技術的侷限性。這意味著我們會發現一些改進，或者更好的是，傳統RDBMS中的某些功能不存在且無法添加，即使生產者會實現它們。

NoSQL的優點包括易於處理的功能：

• 大數據：使用這個術語，我們描述了包含大量數據的數據集。
• 可變數據：數據也可以是結構化的，半結構化的和非結構化的。NoSQL還可以管理數據轉換。
• 動態開發：在我們需要敏捷衝刺，快速迭代，頻繁代碼推送以及總結以響應變化的環境中，擁有一個包含動態的數據庫是非常有幫助的。
• 面向對象：易於使用且靈活的編程
• 可擴展：我們可以輕鬆實現高效，可擴展的架構，而不是昂貴的單片架構。即使在傳統的數據庫中，我們也能做到這一點，但它更難，更有限。
• 開源：大多數解決方案都是開源的，因此無需許可證

綜上所述：

NoSQL數據庫更具可擴展性並提供更好的性能，並且它們的數據模型更接近應用程序內部使用的域模型。基於NoSQL數據庫啟動項目的公司數量正在增長。NoSQL數據庫也往往是開源的，這意味著開發，實現和共享軟件的成本相對較低。

NoSQL的限制

在評估NoSQL數據庫的侷限性時，重要的是要記住NoSQL世界是一個多樣化的生態系統。並非所有NoSQL存儲產品都具有相同程度的所有缺點。這是一件好事，因為這意味著在權衡不同NoSQL解決方案的優缺點時，組織有很多選擇，以決定哪一個最適合他們的特定需求。本章總結了使用NoSQL解決方案可能會遺漏的一些功能。

通過閱讀這篇文章，你會發現本章擴展的不僅僅是優勢之一。這不是阻止使用NoSQL的方法。本章將對NoSQL技術的所有限制進行公正的描述，並且只是想讓您瞭解使用它們時可能遇到的每個問題。許多要點可能會因實施而有所不同（即，當我說支持的工具很少時，大多數工具都適合，但並非所有工具都適用），因此請將它們視為一個概述，提醒您可能存在的風險找。我期望的是，在您選擇使用NoSQL產品之後，您可以使用本章作為核對表來了解您的特定數據庫中是否存在此問題以及它是否與應用程序相關。

安全

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

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

數據一致性

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

我必須提到一些NoSQL實現，比如FoundationDB，允許類似ACID的事務保持NoSQL性能高。順便說一下，當我們繼續使用NoSQL時，數據一致性仍然是一個關鍵部分：基於您正在開發的應用程序，這可能是一個問題。

JOIN的

當您與試圖將您轉換為NoSQL技術的人交談時，您可以從中聽到的第一個好處之一是由於刪除關係而帶來的性能優勢。我們都同意一種關係可能會降低性能，但我們會失去什麼呢？

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

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

退後一步，我將從連接的起源開始。RDBMS使用該關係將數據從一個錶鏈接到另一個表，以將數據保存在一個位置而不復制它們。構造連接以允許我們在查詢中重新連接它們。當然，在表之間進行連接需要額外的計算成本，而不是直接在要查詢的表中查找數據。但是這個成本對於保持關係（沒有複製，一致性）是必要的。

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

不總是。有時我們只需要重新設計數據庫結構，可能會刪除一些關係或重組數據。是的，我們將失去一些關係，或者我們將複製日期的某些部分，但它可以接受（在NoSQL中我們將失去所有的關係）。

另一個問題是一致性。考慮類別和產品。我們可能有一個嵌套的類別樹，許多產品作為樹的葉子。在傳統的RDMS中，更改類別樹只是對類別表上的外鍵（自我關係）的更新。這些更改會自動反映所有子類別和產品。在NoSQL中，我們可以在所有類別/產品上擁有冗餘數據，並且需要對子元素進行大量更新。

棘手的交易

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

缺少供應商技術的標準

SQL是一種標準語言。可能會有許多變化帶來特定的方言，但這很複雜並不禁止抽象數據訪問。想想Hibernate，NHibernate，Doctrine，Entity Framework或其他ORM。它們證明了SQL方言之間的區別並不重要。我們可以得出結論，即使許多供應商實現了不同的數據庫技術，SQL也是一種標準語言。此外，如果您不是基於ORM層，如果您為DB生成查詢，則大多數代碼可以在其他代碼中重用。這使遷移更容易，開發人員可以快速適應不同的DB解決方案。

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

架構靈活性可能是一個麻煩

NoSQL系統的一個特點是它們不需要架構。在實踐中，程序員在保存數據時決定數據結構。因此，沒有任何地方可以寫出數據的結構以及數據的含義。即使您可以使用某種自動化工具輕鬆地從數據關係重新創建數據庫模型，這可能是傳統應用程序中缺少的。

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

而且，即使你現在知道什麼是保存的，你認為你會記得下個月的所有內容？和第二年？並非所有項目都需要持續開發，在我們需要進行一些更改之前，可能會有一個業務應用程序保持原樣多年。

在IT部門，公司通常會將項目委託給某個供應商，因此必須考慮這一部分，以確保在項目結束時輕鬆移交，可能要求準確記錄有關數據的結構以及每個字段/集合的含義。與模式靈活性相關的最後一個問題是團隊中的每個成員都無法在項目中工作，因此，對於小團隊來說，流量是至關重要的並非所有成員都對數據結構有完整的瞭解，或者沒有足夠的文檔。

Analytics（分析）

將多個嵌套數據保存在單個文檔中可能會丟失“SUM”，“COUNT”等分析功能。在第一次應用程序開發期間這可能不是問題的壞事，但有人可能會在稍後詢問某些報告，那麼在這種情況下該怎麼做？在填充數據庫之後很難改變數據結構，並且由於明確定義的數據結構的洩漏，這樣做可能具有不可預測的影響。分析對於NoSQL來說是一個難點。

此外，雖然有許多商業工具可以連接到傳統數據庫來管理分析部分，但對NoSQL系統的支持有限。

可以採取的另一個解決方案是在NoSQL DB中複製某種與非結構化數據的“關係”，可能會創建許多集合並將對象與其他集合鏈接起來。如果您計劃遵循此路徑以允許分析報告，請記住，這可能會降低性能，使其與標準SQL系統相媲美。當此DB中涉及的部分最小且記錄數量有限時，這是可以接受的。無論如何，即使根據我的經驗，構造允許加入NoSQL查詢的數據，因為背後沒有明確定義的關係，非常有限並且性能不如我們預期的那麼好（即，在撰寫本文時） ，MongoDB不支持內連接，每次只能進化到表而不創建臨時表）。

更少的工具

我們談到了NoSQL查詢語言和語法缺乏標準化。這個問題也可以反映在工具中，以及大多數平臺的年輕性。我說的是用於查詢的工具，也用於在數據庫之間遷移數據，管理備份等

。當然，大多數NoSQL項目正在增長，我們期望工具會隨之增長，所以這個問題會在某些時候自動解決。

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

性能比較

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

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

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

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

對單個實體的批量操作

該基準測試包含一組可在較短時間內插入的對象。使用越來越多的項目來複制此測試以保存以證明兩個系統中的性能規模。該基準測試以毫秒為單位測量執行時間，並堅持使用單個表/集合。

搜索

此基準測試側重於查詢功能。我們將以下模式分開：

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

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

您可以在git-hub上找到用於執行這些測試的所有代碼。

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

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

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

交易

我們知道NoSQL世界的事務大多不受支持。我們也明白放棄交易可以從表演中獲益，一個問題是：我從中獲得多少收益？我構建了這個基準來比較插入與一個與許多孩子相關的主行的事務。基準測試的重點是執行時間，以ms表示。

Analytics（分析）

該基準專注於分析。假設我們有一個分類的主 - 詳細數據模型，您希望：

• export：整個加入整體數據樹
• 報告：彙總所有類別的所有項目，即為所有客戶提供發票金額
• 關鍵績效指標：總結所有總計總計詳細小計

在內連接後的4M行的基礎上：

興趣點

革命在科技領域是不可避免的。新技術帶來了一些革命性的功能，但往往不得不打敗開發人員的先入之見。有時他們會被誤解，所以他們的弱點在他們受僱後就會出現。

關於創新，我們必須“對立”人群：

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

在現實生活中，我們必須保持中間位置，因此瞭解和了解新技術可以為我們做些什麼並準備好在項目需要之前採用新技術非常重要。“在工作中進行審判”是一種可能導致不良後果的壞習慣。

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

什麼時候我應該使用NoSQL Db？

為什麼NoSQL會比使用SQL數據庫更好？閱讀完本文後，我確信您會理解NoSQL不是SQL數據庫的替代品，而是具有不同功能的不同存儲系統，並且在某些特定領域中非常有用。所以答案不能與“它取決於”有所不同。因為它取決於項目的許多特徵。

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

• 當您的項目需要擴展時，或將來可能。
• 當你必須處理大數據時，或者你的數據在不久的將來會變得很大
• 當應用程序中的分析組件簡單或不那麼重要時
• 當您的應用程序需要適合數據庫目的時（即您在圖表和數據庫中保存數據）

在某些情況下，NoSQL可能是一個很好的選擇，但對於構​​建耐用的基礎架構並不是必不可少的。當然，如果在您的應用程序中，NoSQL系統覆蓋了99％的所有需求，則沒有理由將其與RDBMS結合使用。但是，如果您需要標準RDBMS的關係，事務和其他功能，可能最好將它們用作主存儲系統，並使用NoSQL僅覆蓋關鍵部分（可能源自數據的大小）。

在上面的情況下，表現有多好？

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

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

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

NoSQL系統在生產環境中應用是否成熟？

這主要取決於您的需求，或更好地取決於項目要求。我們可以說NoSQL肯定足夠成熟。所以，如果你需要它，你可以毫無顧慮地使用它。但並非所有應用程序都需要處理大數據或大規模擴展。大多數Saas產品確實如此，在企業環境中也有很多關鍵應用程序，但現在大多數應用程序仍然非常簡單。

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

SQL過時了嗎？

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

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

市場是否為NoSQL做好準備？

回答這個問題的關鍵點是更接近開發人員實現的經驗。大多數數據庫程序員都接受了一年的培訓，以便相關地思考數據。他們如何在這麼短的時間內改變思維方式？它並不容易，特別是當開發人員必須在許多項目中工作時，其中一些是SQL和其他NoSQL。將SQL上的相同模式複製到NoSQL系統的誘惑很難被擊敗，並且經常會導致糟糕的結果。

實際上，有更多的SQL專有技術，RDBMS上的開發人員比NoSQL更多。同時，DBA花費大部分時間專注於關係數據庫，我們不能指望在不到十年前出生的技術上找到相同的東西。在學校和大學都達到了SQL，NoSQL正在開始。

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

什麼是最好的解決方案？

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