當(dāng)前位置：首頁 > 時尚生活

nosql數(shù)據(jù)庫有哪些 4種不適合用NoSQL數(shù)據(jù)庫的場景

2021-04-25 05:04:21 時尚生活 nosql數(shù)據(jù)庫有哪些,可用性,數(shù)據(jù)庫,應(yīng)用程序,都是

在最近的一篇文章中，我們討論了NoSQL和新聞生活的基本區(qū)別?，F(xiàn)在讓我們通過觀察開發(fā)人員真正關(guān)心的東西來分析差異:

我們可以用NoSQL解決什么問題？

同樣重要的是，NoSQL在哪些方面不適合使用？

不同的方法(NoSQL和NewSQL)可以在哪些方面顯示出它們的優(yōu)勢？

讓我們回顧一下NoSQL和NewSQL之間的四個明顯區(qū)別，并回顧一些使用NoSQL技術(shù)但可能不是最佳選擇的用例。

NoSQL數(shù)據(jù)庫的四個缺點

別誤會，NoSQL數(shù)據(jù)庫對于許多工作負載和應(yīng)用程序非常有利，但它的缺點在四個方面很明顯。

擴展性

當(dāng)實施NoSQL產(chǎn)品以滿足谷歌、臉書和推特等互聯(lián)網(wǎng)公司的可擴展性要求時，它們開始吸引注意力。這些公司不得不處理來自無數(shù)來源的大量非結(jié)構(gòu)化數(shù)據(jù):網(wǎng)絡(luò)搜索、移動設(shè)備、用戶狀態(tài)更新、評論流等等。

在這些用例中，最重要的考慮是可伸縮性:數(shù)據(jù)庫必須大規(guī)模擴展。SQL數(shù)據(jù)庫的僵化模式和交互性被視為桎梏，在傳統(tǒng)RDBMS上擴展的成本也被認為是不可行的。

向外擴展廉價硬件產(chǎn)品的能力至關(guān)重要。如果您的用例需要擴展無限的數(shù)據(jù)源，NoSQL可能是正確的選擇——除非您想要實時操作數(shù)據(jù)。

盡管傳統(tǒng)的關(guān)系數(shù)據(jù)庫系統(tǒng)提供了擴展選項，但成本非常高，許多NewSQL系統(tǒng)都是為了解決可伸縮性挑戰(zhàn)而設(shè)計的，這些挑戰(zhàn)首先通過使用NoSQL來解決，同時保留了傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的事務(wù)性和交互性。

一個很好的替代方案是內(nèi)存中的大規(guī)模并行SQL關(guān)系數(shù)據(jù)庫，它在廉價的硬件產(chǎn)品上線性擴展。數(shù)據(jù)庫應(yīng)該是云友好的，并且可以擴展以滿足云操作的需要。它應(yīng)該設(shè)計為高性能、低延遲、無共享、本地集群和云友好的架構(gòu)，以實現(xiàn)高可用性、冗余性和容錯性。

可用

大多數(shù)NoSQL系統(tǒng)都是為可用性而設(shè)計的。

Apache Cassandra做出的這一著名設(shè)計決策是基于這樣一種觀點，即數(shù)據(jù)始終可訪問比數(shù)據(jù)立即正確更重要。畢竟原因是，誰真的在乎一條Tweet是不是按照發(fā)布的順序?qū)崟r顯示？最終，它會以正確的順序顯示，但不必立即顯示。

在一些用例中，最終的一致性是可以接受的。但是在很多情況下，比如你需要馬上做決定的時候…

讓移動用戶的訪問通過。

分配有限和稀缺的資源。

處理財務(wù)。

……歐共體(和NoSQL)不是一個好的選擇。

一些NewSQL系統(tǒng)允許用戶降低一致性級別。例如，MemSQL支持弱隔離(ACID中的“I”)來提高查詢延遲。為了可用性而犧牲正確答案對于分析型(OLAP)工作負載可能是有意義的，但是對于事務(wù)型(OLTP)工作負載就變得無關(guān)緊要了。

一致性(例如，與ACID兼容的事務(wù)、正確答案)

NoSQL系統(tǒng)是為可用性而設(shè)計的(見上文)。這個選擇意味著他們不能提供CAP定理>:

因此，NoSQL系統(tǒng)選擇應(yīng)用程序——它們是可用性和分區(qū)容錯。這使得NoSQL不適合要求高度一致性的應(yīng)用程序或用例: