綜上所述：

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

NoSQL的限制

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

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

安全

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

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

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

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

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

JOIN的

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

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

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

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

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

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

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

棘手的交易

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

缺少供應(yīng)商技術(shù)的標(biāo)準(zhǔn)

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

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

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

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

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

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

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

Analytics（分析）

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

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

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

更少的工具

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

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

性能比較

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

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

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

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

對單個(gè)實(shí)體的批量操作

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

搜索

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

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

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

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

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

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

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

交易

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

Analytics（分析）

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

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

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

興趣點(diǎn)

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

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

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

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

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

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

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

說實(shí)話，謹(jǐn)慎，當(dāng)以下所有陳述都成立時(shí)，NoSQL是最佳解決方案：

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

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

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

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

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

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

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

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

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

SQL過時(shí)了嗎？

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

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

市場是否為NoSQL做好準(zhǔn)備？

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

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

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

什么是最好的解決方案？

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