在設計系統(tǒng)時，很難在關系(RDBS)和非關系數(shù)據(jù)庫(NoSQL)之間進行選擇。 正確理解這兩個局限性將使決策變得更加容易。

在深入研究NoSQL數(shù)據(jù)庫之前，了解關系數(shù)據(jù)庫的局限性很重要。 關系數(shù)據(jù)庫已經存在了近40年，并且運行良好。 數(shù)據(jù)結構合理，記錄保存在表中。 表由行，主鍵，唯一鍵組成，并且表可以相互連接。 它支持的另一個重要功能是事務，它的屬性稱為ACID。 ACID屬性包含4個不同的屬性，如下所述：

• 原子性：它保證了如果發(fā)生多步驟交易，則需要完成所有步驟才能使交易成功。
• 一致性：它確保數(shù)據(jù)庫在任何事務之前和之后均應保持一致。
• 隔離：它保證可以同時發(fā)生多個事務，而不會互相干擾。
• 耐用性：即使服務器崩潰或斷電，它也可以確保持久存儲數(shù)據(jù)，而無需擔心數(shù)據(jù)。

但是，隨著大數(shù)據(jù)技術的發(fā)展，傳統(tǒng)的基于SQL的數(shù)據(jù)庫已不足以管理快速增長的數(shù)據(jù)量以及日益復雜的數(shù)據(jù)結構。 關系數(shù)據(jù)庫的一些缺點如下：

• 模式：關系數(shù)據(jù)庫的模式是固定的，您必須事先設計它。 對于快速增長的應用程序，很難假設數(shù)據(jù)的復雜性然后進行設計。
• 數(shù)據(jù)結構：由于關系數(shù)據(jù)庫支持的數(shù)據(jù)結構有限，我們需要做更多的連接才能獲得所需的數(shù)據(jù)，并且連接總是很昂貴的。
• 擴展：由于數(shù)據(jù)增長非常迅速，因此很難擴展關系數(shù)據(jù)庫。

我們對此有任何解決方法嗎?

幸運的是! 我們有。

非規(guī)范化就是其中之一。 展開單個表并向其中添加更多列，以便在獲取結果時避免連接。 這樣可以提高讀取性能，但會導致數(shù)據(jù)異常。

另一種技術是分片。 在這種技術中，可以對數(shù)據(jù)庫進行分割，并將其存儲在不同的服務器中。 這樣可以提高讀寫性能，但是很難管理。

因此，總結一下。 關系數(shù)據(jù)庫具有很多優(yōu)點和缺點，我們可以解決它們，但是也帶來了其他挑戰(zhàn)。

NoSQL數(shù)據(jù)庫自然允許對數(shù)據(jù)進行非規(guī)范化，可伸縮性和靈活的架構。 這些東西是免費提供的嗎? 沒有! 在這個世界上，沒有什么是免費的。 放寬ACID限制。 盡管ACID對于某些應用程序是一個重要的約束，但對于所有應用程序卻不是。 最后但并非最不重要的一點是，NoSQL數(shù)據(jù)庫提供了一種查詢大型和更復雜的數(shù)據(jù)結構的新方法，這在關系數(shù)據(jù)庫中是不可能的。 這是使用NoSQL進行數(shù)據(jù)科學的關鍵因素之一。

NoSQL數(shù)據(jù)庫的優(yōu)點：

• 靈活模式：通常提供非常靈活的模式。 根據(jù)需求可以很容易地更改架構。
• 水平擴展：允許在需要時添加更便宜的商品服務器。 SQL數(shù)據(jù)庫在超出容量時需要垂直擴展(遷移到更大的服務器)。
• 更快的查詢：NoSQL數(shù)據(jù)庫的一項主要原則是"應將一起訪問的數(shù)據(jù)存儲在一起"。 因此，查詢通常無需連接即可工作，這使查詢速度更快。

NoSQL數(shù)據(jù)庫的一些示例是Redis，Dynamo，CouchDB，MongoDB，Cassandra，HBase和Neo4J。 很多人在關系數(shù)據(jù)庫中遇到許多不同的問題，這最終不足為奇，他們最終設計了不同類型的NoSQL數(shù)據(jù)庫。

• 鍵值存儲：就像字典一樣，您可以在其中了解鍵并可以檢索其值。 它是NoSQL數(shù)據(jù)庫的最簡單類型之一。 這種數(shù)據(jù)庫對于緩存確實很有用。 示例：Redis和Dynamo。
• 文檔數(shù)據(jù)庫：數(shù)據(jù)存儲在文檔中，而不是行和列。 文檔被分組以形成一個集合。 這種數(shù)據(jù)庫的優(yōu)點之一是每個文檔可以具有不同的結構。 這種數(shù)據(jù)庫對于內容管理和存儲用戶個人資料非常有用。 示例：CouchDB和MongoDB。
• 寬列數(shù)據(jù)庫：寬列數(shù)據(jù)庫中的列和表的概念與關系數(shù)據(jù)庫中的概念不同。 例如，在寬列數(shù)據(jù)庫中，數(shù)據(jù)被非規(guī)范化，列根本沒有固定，它們可以隨時更改。 例如，我們可以在應用程序中動態(tài)添加列，甚至同一表中的行可以具有不同的列的情況也是如此。 與文檔數(shù)據(jù)庫一樣，此處的值可以是復雜的結構，例如數(shù)組和列表。 這種數(shù)據(jù)庫對于時間序列數(shù)據(jù)，日志記錄和其他大量寫入應用程序非常有用。 示例：Cassandra和HBase。
• 圖形數(shù)據(jù)庫：在圖形中可以更好地表示關系的應用程序，這些數(shù)據(jù)庫在那里非常有用。 這些類型的數(shù)據(jù)庫主要用于社交網絡，知識圖等。例如：Neo4J。

關系數(shù)據(jù)庫和NoSQL這兩個數(shù)據(jù)庫在數(shù)據(jù)管理方面都很棒。 沒有簡單的答案哪個更好。 這完全取決于幫助人們根據(jù)上述參數(shù)及其權衡選擇的要求。