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

[[349639]]

Schema管理

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

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

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

使用NoSQL數(shù)據(jù)庫(kù)時(shí)，我們必須記住有關(guān)模式管理和數(shù)據(jù)驗(yàn)證的問(wèn)題。 沒(méi)有它，數(shù)據(jù)可能會(huì)"爆炸"。 有趣的事實(shí)：一些公司用PostgreSQL替換了MongoDB。

較低的誤差范圍

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

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

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

不支持ACID

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

不支持SQL

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

分析有限和/或沒(méi)有Join

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

概要

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

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