NoSQL數據庫的陷阱有哪些

本篇內容介紹了“NoSQL數據庫的陷阱有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Schema管理

每個NoSQL數據庫都以其自己的方式處理該模式。  在某些情況下沒有Schema(MongoDB)，在某些情況下它是動態的(Elasticsearch)，在某些情況下它類似于關系數據庫中的Schema(Cassandra)。  在概念模型中，數據始終具有Schema。 實體，字段，名稱，類型，關系。 不管基礎類型如何，物理模型都是概念模型的表示。

NoSQL數據庫在架構方面為我們提供了更多自由。 在MongoDB中，我們可以添加兩個具有相同字段名稱但類型不同的不同文檔。 這有意義嗎? 而不是。  這會發生嗎? 當然可以。 一個簡單的人為錯誤可能會破壞我們的應用程序。

另一個問題與實體之間的關系有關。 即使數據庫中沒有關系，我們也必須記錄數據之間的關系。 從關系數據庫中，我們可以生成ERD圖。  如果是NoSQL數據庫，則可能無法使用。

使用NoSQL數據庫時，我們必須記住有關模式管理和數據驗證的問題。 沒有它，數據可能會"爆炸"。  有趣的事實：一些公司用PostgreSQL替換了MongoDB。

較低的誤差范圍

NoSQL數據庫的性能是適當的數據建模，索引和分區的結果。  在關系數據庫中，我們可以添加列，轉換表，將數據從一個表翻轉到另一個表，以及如果我們之前忘記了索引，則可以添加索引。  對于NoSQL數據庫，并非在所有情況下都可行。 我們可能需要使用一些外部工具，例如Apache Spark，甚至刪除并重新創建我們的數據模型。

在Elasticsearch中，如果我們無法獲取索引的架構/映射，則必須使用例如 重新索引API，這意味著我們必須將數據重新索引到另一個索引。

在Cassandra中，我們只能按分區鍵和群集鍵進行過濾。 如果我們忘記在鍵中添加一列，則有可能添加索引，但是如果集合的基數很大，則會降低性能。

不支持ACID

ACID屬性簡化了代碼編寫。 我們不需要處理與以下事實有關的錯誤：X表中的數據已經存在，而Y表中的數據尚未存在(如果有的話)。  根據CAP定理，我們知道存在一致的數據庫和最終一致的數據庫。 這種類型最流行的數據庫是Apache Cassandra。  最終的一致性要求對數據建模和應用程序邏輯采用不同的方法。 應該以一種更具防御性的方式編寫代碼，因為不確定您剛剛更改的記錄是否可以從應用程序的另一部分獲得。  HBase是一致性數據庫的一個示例，但是即使Cloudera相信它也不會替代關系數據庫。 一些數據庫宣稱自己是一致的，并且僅在一定程度上確保了一致性。  例如，MongoDB提供事務，但是多文檔事務僅自版本4.0起可用。

不支持SQL

NoSQL的缺點是缺少SQL。 我們可能喜歡不喜歡，但SQL是數據的基礎。 許多分析師每天都在使用SQL，學習其他語言可能會阻止他們使用數據庫。  創建Spark SQL或Beam SQL的原因是有原因的。

分析有限和/或沒有Join

這只是關于OLTP和OLAP系統之間差異的討論。 我們習慣于使用GROUP BY和JOIN子句，但并非每個數據庫都會提供此類功能。  由于數據庫的性質，聚合和合并可能非常有限(如果可能)。 對于Apache Cassandra，分析功能通常是通過將Apache  Spark集群組合在一起來實現的。 您將通過我的故事學習如何將彼此聯系起來。

“NoSQL數據庫的陷阱有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！