NoSQL數據庫的5個陷阱
我錄制了一段視頻，講述了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嗎? 當然是這樣。 我們必須記住，創建每個數據庫都是為了解決一類問題。 歪曲"命運"是可能的，但會帶來后果。 螺絲刀更容易用螺絲刀擰入，用錘子敲釘子和用棍子使墻壁疼痛。
一個有趣的替代方法是NewSQL數據庫。 這樣的一個例子是CockroachDb和Spanner。 他們解決了傳統關系數據庫的問題(主要是擴展問題)，同時保持了ACID屬性。
