NoSQL數(shù)據(jù)庫(kù)的陷阱有哪些

本篇內(nèi)容介紹了“NoSQL數(shù)據(jù)庫(kù)的陷阱有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

Schema管理

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

NoSQL數(shù)據(jù)庫(kù)在架構(gòu)方面為我們提供了更多自由。 在MongoDB中，我們可以添加兩個(gè)具有相同字段名稱但類型不同的不同文檔。 這有意義嗎? 而不是。  這會(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ù)。 這種類型最流行的數(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ù)宣稱自己是一致的，并且僅在一定程度上確保了一致性。  例如，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ì)提供此類功能。  由于數(shù)據(jù)庫(kù)的性質(zhì)，聚合和合并可能非常有限(如果可能)。 對(duì)于Apache Cassandra，分析功能通常是通過(guò)將Apache  Spark集群組合在一起來(lái)實(shí)現(xiàn)的。 您將通過(guò)我的故事學(xué)習(xí)如何將彼此聯(lián)系起來(lái)。

“NoSQL數(shù)據(jù)庫(kù)的陷阱有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！