我錄制了一段視頻，講述了NoSQL數(shù)據(jù)庫的優(yōu)勢。 回應很有趣，但是我給人的印象是，并不是每個人都看到硬幣的兩面。 事實是它們會給我們帶來很多問題。

[[349639]]

Schema管理

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

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

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

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

較低的誤差范圍

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

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

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

不支持ACID

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

不支持SQL

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

分析有限和/或沒有Join

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

概要

那么值得使用NoSQL嗎? 當然是這樣。 我們必須記住，創(chuàng)建每個數(shù)據(jù)庫都是為了解決一類問題。 歪曲"命運"是可能的，但會帶來后果。 螺絲刀更容易用螺絲刀擰入，用錘子敲釘子和用棍子使墻壁疼痛。

一個有趣的替代方法是NewSQL數(shù)據(jù)庫。 這樣的一個例子是CockroachDb和Spanner。 他們解決了傳統(tǒng)關系數(shù)據(jù)庫的問題(主要是擴展問題)，同時保持了ACID屬性。