到現在為止,NoSQL運動給資料庫系統留下什麼寶貴的思想?

時間 2021-05-13 06:01:25

1樓:

說白了NOSQL就是僅提供原子層面的儲存(結構化及非結構化)服務至於事務及SQL相容性不是NOSQL必須該負責的內容,從而大大提公升了擴充套件性和效能,但你如果一定要做到事務(ACID)的要求,由應用/資料庫做好了,這也是為什麼很多資料庫產品公司採用SQL引擎+Nosql儲存(KV或者文件儲存)實現分布式事務資料庫的原因,從而既做到了關係型資料庫,又實現了事務和高擴充套件性、高效能

2樓:Bowen Xiao

不請自來,亂答一通。

感覺這種運動非常符合資料庫這門實踐科學的特性。

一開始直接快刀斬亂麻,BigTable就是KV抽象加GFS,結果這種架構拋棄了事務和SQL能力,解決了一些問題和帶來了新的問題,有新的問題就要解決。

NewSQL開始了,大家又喊著不提供事務和關係模型的資料庫怎麼能叫資料庫,潮流果然是乙個圓。而且也讓我們看到了資料庫模組化的趨勢:乙個資料庫提供怎樣的模型抽象能力,和它的底層儲存沒有必然關係。

Aurora在商業上證明了計算和儲存分離的可能性,TiFlash這種外掛程式式的設計也非常平滑,也許我們今後會見證更多kernel級別的元件化,比如Query Optimization, Transaction Management等等,可能網路I/O會成為新的瓶頸。

3樓:kanmars

尾聲。。。。。。

是乙個很有意思的提法。

我覺得這麼認為是正常的,畢竟當年nosql風華正茂時,曾試圖一統世界。

然後,人們給了它期望,但它沒有實現。

現在的「尾聲」等負面聲音,是存在於所有事物的「反噬」而已

4樓:朝聞道

1.半結構化/非結構化資料模型,靈活。

2.雲應用一開始普遍選擇的關係型資料庫。然而,在使用過程中卻遇到了越來越多的問題,原因就在於他們是中心化的,向上擴充套件而非水平擴充套件的。

這使得他們不適合於那些需要簡單且動態可伸縮性的應用。NoSQL資料庫從一開始就是分布式、水平擴充套件的,因此非常適合於網際網路應用分布式的特性。

5樓:網易數帆

回頭來說,資料庫終究是要滿足資料的管理和儲存的需求,NoSQL 因關係模型當初不能很好地適應海量資料儲存和管理而生,它去掉了關係型特性,支援分布式儲存,甚至自動分片,擴充套件和併發能力強,在庫表結構簡單的網際網路業務上表現很好。然而業務需求複雜之後,遵循 CAP 理論和 BASE 原則的NoSQL,對 ACID 和 SQL 支援不佳等短板讓人不能忍,它需要使用者精通資料儲存引擎,事務又是渣渣。所以 Google F1、TiDB 之類的 NewSQL 出來了,支援分布式、高容錯、基於雲的集群架構,支援關係資料模型,支援使用 SQL 語句來查詢資料。

當然,NewSQL 是很不好搞的。

其實,關係型資料庫在海量資料儲存和查詢方面做了不少的探索,業務拆分、分庫分表已經不是什麼新聞。但在一些需求簡單的場景下,關係庫效能還是不如 NoSQL。正確的廢話,就是還需要根據業務場景來選擇。

利益相關:網易雲在 RDS之外,也提供 MongoDB、Redis 等雲服務。

6樓:彭河森

個人來說,最大的經驗是:產品好固然重要,生態決定一切

這個生態包括已有系統構架運維複雜程度開發人員是否容易找文件是否豐富等多個方面。

SQL生態在上面幾個方面可以秒殺任何NoSQL生態,開發上手的容易程度都是不容置疑的。

對於NoSQL生態,這幾個方面考慮完備之後,我個人有限的知識體系裡面暫時只有Redis和Elasticsearch (後者嚴格說來都不算資料庫)可以達到上面幾個標準。其他動不動上Zookeeper的資料庫你們好意思說你們好入門,為了介紹那你們我得專門寫一章節介紹怎麼配置zookeeper,這樣很浪費知道嗎?

看過太多的實戰例子,開始急吼吼的上NoSQL,後來發現原來只需要做一下secondary indexing或者sharding,以前的SQL資料庫能繼續跑的風生水起。有些非谷歌搜尋引擎公司內部乙個功能部門就有5個以上的自主開發的特殊應用場景專用鍵值資料庫,人家有錢知道嗎?畢竟,大資料是有錢人的遊戲,有錢可以用月球當硬碟,沒錢就好好調引數啦

7樓:九九六

題主提到的NoSQL運動這個名詞最早出現在2023年CSDN上的兩篇文章

NOSQL運動:一場技術多元化的演進-CSDN.NET

CouchDB退出,NoSQL運動開始分崩離析?-CSDN.NET

這種叫法實際上更多的是帶有一些調侃的韻味,並不正宗。任何一種資料庫的作用都要放到業務場景下去談才有意義。

比如redis,現在很多系統中都會用來做資料快取,減少業務主庫的查詢量,防止業務庫被穿透。

mongodb可以用在關係性不強,但是字段層級較多的業務場景。比如:

},"b":3

}下面這個層層巢狀的json結構如果儲存在mysql中就比較麻煩,而儲存在mongodb中無論是查詢還是插入都簡單了很多。

但是nosql也有他的侷限,在這裡我舉兩個不適合nosql資料庫的場景:

1.對事務要求較高的場景。

2.多表關聯查詢大資料量統計。

8樓:

最寶貴的思想就是慎用縮寫。

中國起碼有一半嘴上天天掛著NoSQL的人,腦子裡,說起來都是 No SQL。

其實他是 Not Only SQL 的縮寫。

9樓:bigdata

nosql為了擴充套件性作了優化的限制, 不提供join,sort,conut等操作,提供基於分割槽分布,最終一致的全域性二級索引,這些在大資料量下本來就需要從新設計的,db搞不定。但對於介面形式以及單分割槽下的事務,nosql應吸拿sql的優式,所以有了newsql。

10樓:Y.B

NoSQL 並沒有像標題所 imply 的一樣死掉了,它不是留下了什麼,而是正在改變我們對資料儲存和業務建模的觀念。但這個程序顯得不快,主要是兩方面的原因,一是多年來大量開發者對於關係資料的理解和使用造成大家對於採用 NoSQL 順利而流暢的進行建模還顯得很陌生;二是 NoSQL 社群本身的問題,主要集中在資料一致性問題上。就我們公司本身的經驗來說,採用的是我們自研的 NoSQL 資料庫,極大提高了系統吞吐效能,建模方面也顯得非常的直接簡潔。

我們公司已經全面採用 NoSQL 而不會再在關聯式資料庫上下功夫。

為何到現在為止,the Grand Tour無法還原TopGear的精彩?

Lingz 誰看tgt是看正經的,觀眾們看的只是他仨而已。這也是為什麼他們決定只搞特輯了,我覺得harris評車實力加上BBC的硬後台不怕官司,絕對世界第一評車人。三賤是嘴炮,但是現在也沒那麼大膽了 愚蠢 其實沒什麼不好的啊,除了少了stig,覺得現在的the American沒了面罩頭盔沒那麼fu...

韓綜《Running Man》到現在為止,最爆笑的是哪幾期?

錦瑟 我用了近兩年的業餘時間把RM,從第一期看到現在最新的一期,本來搜這個問題是因為沒有Rm的閒暇時光太難熬了,於是想回頭看看比較精彩的幾期。但是一條條回答看下來熟悉的節目名稱,爆出梗時的回憶,回想到當初第一次看時,笑得在床上打滾。太多太多了,對他們來說十年了,對我來說只有兩年。我決定不等每一期的更...

到現在為止 韓圈top是哪家?

我見過最好笑的回答是 top是一年一年算的 粉墨沒拿獎是因為防彈壓著 blink真有你們的,出來說話能不能過一下腦子?看看可愛的blink是怎麼說的吧,說不過就罵人舉報也真是高素質的blink呢 武林秘籍 看到有人在扯為什麼分開男女團來比 扯為什麼給防彈戴高帽 我把話放這了好吧 男團防彈top 男女...