當(dāng)前主流nosql系列數(shù)據(jù)庫產(chǎn)品有哪些

MySQL SQLSERVER Oracle DB2 PostgreSQL 這些都是最常見的,哦,還有一些NoSQL的數(shù)據(jù)庫,就是非關(guān)系型數(shù)據(jù)庫

創(chuàng)新互聯(lián)專業(yè)提供成都移動機(jī)房托管服務(wù)，為用戶提供五星數(shù)據(jù)中心、電信、雙線接入解決方案，用戶可自行在線購買成都移動機(jī)房托管服務(wù)，并享受7*24小時金牌售后服務(wù)。

數(shù)據(jù)庫系統(tǒng)從使用和運(yùn)行方式上可以分成兩種類型，是哪兩種啊，求解

分為關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫。

1、關(guān)系型數(shù)據(jù)庫：

關(guān)系型數(shù)據(jù)庫，是指采用了關(guān)系模型來組織數(shù)據(jù)的數(shù)據(jù)庫，其以行和列的形式存儲數(shù)據(jù)，以便于用戶理解，關(guān)系型數(shù)據(jù)庫這一系列的行和列被稱為表，一組表組成了數(shù)據(jù)庫。用戶通過查詢來檢索數(shù)據(jù)庫中的數(shù)據(jù)，而查詢是一個用于限定數(shù)據(jù)庫中某些區(qū)域的執(zhí)行代碼。

2、非關(guān)系型數(shù)據(jù)庫：

泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在處理web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，出現(xiàn)了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。

擴(kuò)展資料

關(guān)系型數(shù)據(jù)庫的最大特點(diǎn)就是事務(wù)的一致性：傳統(tǒng)的關(guān)系型數(shù)據(jù)庫讀寫操作都是事務(wù)的，具有ACID的特點(diǎn)，這個特性使得關(guān)系型數(shù)據(jù)庫可以用于幾乎所有對一致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。

關(guān)系數(shù)據(jù)庫的另一個特點(diǎn)就是其具有固定的表結(jié)構(gòu)，因此，其擴(kuò)展性極差，而在SNS中，系統(tǒng)的升級，功能的增加，往往意味著數(shù)據(jù)結(jié)構(gòu)巨大變動，這一點(diǎn)關(guān)系型數(shù)據(jù)庫也難以應(yīng)付，需要新的結(jié)構(gòu)化數(shù)據(jù)存儲。

于是，非關(guān)系型數(shù)據(jù)庫應(yīng)運(yùn)而生，由于不可能用一種數(shù)據(jù)結(jié)構(gòu)化存儲應(yīng)付所有的新的需求，因此，非關(guān)系型數(shù)據(jù)庫嚴(yán)格上不是一種數(shù)據(jù)庫，應(yīng)該是一種數(shù)據(jù)結(jié)構(gòu)化存儲方法的集合。

參考資料來源：百度百科-關(guān)系型數(shù)據(jù)庫

參考資料來源：百度百科-NoSQL

NoSQL 數(shù)據(jù)庫：何時使用 NoSQL 與 SQL？

NoSQL 數(shù)據(jù)庫因其功能性、易于開發(fā)性和可擴(kuò)展性而廣受認(rèn)可，它們越來越多地用于大數(shù)據(jù)和實(shí)時 Web 應(yīng)用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。

NoSQL是一種下一代數(shù)據(jù)庫管理系統(tǒng) (DBMS)。NoSQL 數(shù)據(jù)庫具有靈活的模式，可用于構(gòu)建具有大量數(shù)據(jù)和高負(fù)載的現(xiàn)代應(yīng)用程序。

“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的，盡管自 1960 年代后期以來就已經(jīng)存在類似的數(shù)據(jù)庫。然而，NoSQL 的發(fā)展始于 2009 年初，并且發(fā)展迅速。

在處理大量數(shù)據(jù)時，任何關(guān)系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 的響應(yīng)時間都會變慢。為了解決這個問題，我們可以通過升級現(xiàn)有硬件來“擴(kuò)大”信息系統(tǒng)，這非常昂貴。但是，NoSQL 可以更好地橫向擴(kuò)展并且更具成本效益。

NoSQL 對于非結(jié)構(gòu)化或非常大的數(shù)據(jù)對象（例如聊天日志數(shù)據(jù)、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯(lián)網(wǎng)巨頭中特別受歡迎的原因。

一些流行的 NoSQL 數(shù)據(jù)庫包括：

隨著企業(yè)更快地積累更大的數(shù)據(jù)集，結(jié)構(gòu)化數(shù)據(jù)和關(guān)系模式并不總是適合。有必要使用非結(jié)構(gòu)化數(shù)據(jù)和大型對象來更好地捕獲這些信息。

傳統(tǒng)的 RDBMS 使用 SQL（結(jié)構(gòu)化查詢語言）語法來存儲和檢索結(jié)構(gòu)化數(shù)據(jù)，相反，NoSQL 數(shù)據(jù)庫包含廣泛的功能，可以存儲和檢索結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化和多態(tài)數(shù)據(jù)。

有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強(qiáng)調(diào)它可能支持類似 SQL 的語言或與 SQL 數(shù)據(jù)庫并列。SQL 和 NoSQL DBMS 之間的一個區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫使用 JOIN 子句來組合來自兩個或多個表的行，因?yàn)?NoSQL 數(shù)據(jù)庫本質(zhì)上不是表格的，所以這個功能并不總是可行或相關(guān)的。

但是，一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數(shù)據(jù)庫傾向于以不同的方式解決類似的問題。

一般來說，在以下情況下，NoSQL 比 SQL 更可?。?/p>

許多行業(yè)都在采用 NoSQL，取代關(guān)系數(shù)據(jù)庫，從而為某些業(yè)務(wù)應(yīng)用程序提供更高的靈活性和可擴(kuò)展性，下面給出了 NoSQL 數(shù)據(jù)庫的一些企業(yè)用例。

內(nèi)容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數(shù)據(jù)庫可以通過其靈活和開放的數(shù)據(jù)模型為存儲多媒體內(nèi)容提供更好的選擇。

例如，福布斯在短短幾個月內(nèi)就構(gòu)建了一個基于 MongoDB 的定制內(nèi)容管理系統(tǒng)，以更低的成本為他們提供了更大的敏捷性。

大數(shù)據(jù)是指太大而無法通過傳統(tǒng)處理系統(tǒng)處理的數(shù)據(jù)集，實(shí)時存儲和檢索大數(shù)據(jù)的系統(tǒng)在分析 歷史 數(shù)據(jù)的同時使用流處理來攝取新數(shù)據(jù)，這是一系列非常適合 NoSQL 數(shù)據(jù)庫的功能。

Zoom使用 DynamoDB（按需模式）使其數(shù)據(jù)能夠在沒有性能問題的情況下進(jìn)行擴(kuò)展，即使該服務(wù)在 COVID-19 大流行的早期使用量激增。

物聯(lián)網(wǎng)設(shè)備具有連接到互聯(lián)網(wǎng)或通信網(wǎng)絡(luò)的嵌入式軟件和傳感器，能夠在無需人工干預(yù)的情況下收集和共享數(shù)據(jù)。隨著數(shù)十億臺設(shè)備生成數(shù)不清的數(shù)據(jù)，IoT NoSQL 數(shù)據(jù)庫為 IoT 服務(wù)提供商提供了可擴(kuò)展性和更靈活的架構(gòu)。

Freshub就是這樣的一項(xiàng)服務(wù)，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態(tài)、非統(tǒng)一的數(shù)據(jù)集。

擁有數(shù)十億智能手機(jī)用戶，可擴(kuò)展性正成為在移動設(shè)備上提供服務(wù)的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數(shù)據(jù)模型的 NoSQL DBMS 通常是完美的解決方案。

例如，The Weather Channel使用 MongoDB 數(shù)據(jù)庫每分鐘處理數(shù)百萬個請求，同時還處理用戶數(shù)據(jù)并提供天氣更新。

NoSQL會取代完全取代關(guān)系型數(shù)據(jù)庫嗎？

對此，前Google工程師，Milo（本地商店搜索引擎）創(chuàng)始人Ted Dziuba最近發(fā)表標(biāo)題驚人的博客“I Can't Wait for NoSQL to Die”，對NoSQL的適用范圍進(jìn)行了分析。他認(rèn)為， NoSQL也會帶來一連串的新問題，并不會成為主流，無法取代關(guān)系型數(shù)據(jù)庫。 他的理由是：Cassandra等NoSQL數(shù)據(jù)庫在使用上并不方便，比如，修改column family定義時就需要重啟。而且NoSQL更適合Google那樣的規(guī)模，而一般的互聯(lián)網(wǎng)公司都不是Google，早早地去考慮Google那樣的規(guī)模的可擴(kuò)展性，純粹是浪費(fèi)時間，存在巨大的商業(yè)風(fēng)險(xiǎn)。 他還透露，即使在Google，AdWords這樣的關(guān)鍵產(chǎn)品也是基于MySQL實(shí)現(xiàn)的。 他在文中最后表示，NoSQL當(dāng)然死不了，但是 它最終會被邊緣化，就像Rails被NoSQL邊緣化一樣 Dziuba的文章因?yàn)檠赞o激烈，在社區(qū)里引起了強(qiáng)烈反應(yīng)。 SQL數(shù)據(jù)庫陣營贊同者大有人在。craigslist工程師、著名的MySQL專家Jeremy Zawodny表示，在讀此文的時候，不時會心一笑。他說， NoSQL運(yùn)動只是軟件不斷進(jìn)化進(jìn)程中的正?，F(xiàn)象 。關(guān)系型數(shù)據(jù)庫也會繼續(xù)發(fā)展，MySQL社區(qū)不斷推出的XtraDB或InnoDB插件, PBXT, Drizzle都是證據(jù)。各種技術(shù)競爭的結(jié)果是，我們獲得了更多解決問題的選擇。 drizzle項(xiàng)目開發(fā)者Eric Day也表示，NoSQL有很多值得學(xué)習(xí)的，但是目前大部分實(shí)際項(xiàng)目的最佳選擇還是關(guān)系型數(shù)據(jù)庫。 NoSQL陣營當(dāng)然不會坐視不理，Cassandra項(xiàng)目組的Eric Evans表示，Dziuba提到Cassandra修改column family定義的問題其實(shí)很容易解決。而且，NoSQL并不是要取代MySQL，事實(shí)上Twitter仍然在用MySQL。如果關(guān)系型數(shù)據(jù)庫能夠承擔(dān)負(fù)荷，那就用好了；如果不行，請考慮NoSQL。 而德國知名博客Code Monkeyism則嘲笑Dziuba看起來并沒有用MySQL做過真實(shí)項(xiàng)目，因?yàn)镸ySQL如果沒有memcache，基本上無法應(yīng)付網(wǎng)站項(xiàng)目。他認(rèn)為，NoSQL將使SQL數(shù)據(jù)庫邊緣化，而且一個重要理由恰恰是可以節(jié)省DBA的開銷。 digg的前任首席架構(gòu)師現(xiàn)在也在創(chuàng)業(yè)的Joe Stump說，自己現(xiàn)在的創(chuàng)業(yè)項(xiàng)目就是用NoSQL，而且列舉了一系列問題挑戰(zhàn)SQL陣營。

為什么大部分NoSQL不提供分布式事務(wù)

像MongoDB, Cassandra, HBase, DynamoDB, 和

Riak這些NoSQL缺乏傳統(tǒng)的原子事務(wù)機(jī)制，所謂原子事務(wù)機(jī)制是可以保證一系列寫操作要么全部完成，要么全部不會完成，不會發(fā)生只完成一系列中一兩個

寫操作;因?yàn)閿?shù)據(jù)庫不提供這種事務(wù)機(jī)制支持，開發(fā)者需要自己編寫代碼來確保一系列寫操作的事務(wù)機(jī)制，比較復(fù)雜和測試。

這些NoSQL數(shù)據(jù)庫不提供事務(wù)機(jī)制原因在于其分布式特點(diǎn)，一系列寫操作中訪問的數(shù)據(jù)可能位于不同的分區(qū)服務(wù)器，這樣的事務(wù)就變成分布式事務(wù)，在分

布式事務(wù)中實(shí)現(xiàn)原子性需要彼此協(xié)調(diào)，而協(xié)調(diào)是耗費(fèi)時間的，每臺機(jī)器在一個大事務(wù)過程中必須依次確認(rèn)，這就需要一種協(xié)議確保一個事務(wù)中沒有任何一臺機(jī)器寫操

作失敗。

這種協(xié)調(diào)是昂貴的，會增加延遲時間，關(guān)鍵問題是，當(dāng)協(xié)調(diào)沒有完成時，其他操作是不能讀取事務(wù)中寫操作結(jié)果的，這是因?yàn)槭聞?wù)的all-or-

nothing原理導(dǎo)致，萬一協(xié)調(diào)過程發(fā)現(xiàn)某個寫操作不能完成，那么需要將其他寫操作成功的進(jìn)行回滾。針對分布式事務(wù)的分布式協(xié)調(diào)對整體數(shù)據(jù)庫性能有嚴(yán)重

影響，不只是吞吐量還包括延遲時間，這樣大部分NoSQL數(shù)據(jù)庫因?yàn)樾阅軉栴}就選擇不提供分布式事務(wù)。

MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務(wù)，這是因?yàn)樗行畔⒍己鸵粋€鍵key有關(guān)，這個鍵是存儲在單個服務(wù)器上，這樣基于單鍵的事務(wù)不會帶來復(fù)雜的分布式協(xié)調(diào)。

那么看來擴(kuò)展性性能和分布式事務(wù)是一對矛盾，總要有取舍?實(shí)際上是不完全是，現(xiàn)在完全有可能提供高擴(kuò)展的性能同時提供分布式原子事務(wù)。

FIT是這樣一個在分布式系統(tǒng)提供原子事務(wù)的策略，在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權(quán)衡。

一個支持分布式事務(wù)的可伸縮分布式系統(tǒng)能夠完成這三個屬性中兩個，公平是事務(wù)之間不會相互影響造成延遲;隔離性提供一種幻覺好像整個數(shù)據(jù)庫只有它自

己一個事務(wù)，隔離性保證當(dāng)任何同時發(fā)生的事務(wù)發(fā)生沖突時，能夠保證彼此能看到彼此的寫操作結(jié)果，因此減輕了程序員為避免事務(wù)讀寫沖突的強(qiáng)邏輯推理要求;吞

吐量是指每單元時間數(shù)據(jù)庫能夠并發(fā)處理多少事務(wù)。

FIT是如下進(jìn)行權(quán)衡：

保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量

保證公平性fairness和吞吐量, 犧牲隔離性isolation

保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.

犧牲公平性：放棄公平性，數(shù)據(jù)庫能有更多機(jī)會降低分布式事務(wù)的成本，主要成本是分布式協(xié)調(diào)帶來的，也就是說，不需要在每個事務(wù)過程內(nèi)對每個機(jī)器都依

次確認(rèn)事務(wù)完成，這樣排隊(duì)式的確認(rèn)commit事務(wù)是很浪費(fèi)時間的，放棄公平性，意味著可以在事務(wù)外面進(jìn)行協(xié)調(diào)，這樣就只是增加了協(xié)調(diào)時間，不會增加互相

沖突事務(wù)因?yàn)楸舜藳_突而不能運(yùn)行所耽擱的時間，當(dāng)系統(tǒng)不需要公平性時，需要根據(jù)事務(wù)的優(yōu)先級或延遲等標(biāo)準(zhǔn)進(jìn)行指定先后執(zhí)行順序，這樣就能夠獲得很好的吞吐

量。

G-Store是一種放棄公平性的 Isolation-Throughput

的分布式key-value存儲，支持多鍵事務(wù)(multi-key transactions)，MongoDB 和

HBase在鍵key在同樣分區(qū)上也支持多鍵事務(wù)，但是不支持跨分區(qū)的事務(wù)。

總之：傳統(tǒng)分布式事務(wù)性能不佳的原因是確保原子性(分布式協(xié)調(diào))和隔離性同時重疊，創(chuàng)建一個高吞吐量分布式事務(wù)的關(guān)鍵是分離這兩種關(guān)注，這種分離原

子性和隔離性的視角將導(dǎo)致兩種類型的系統(tǒng)，第一種選擇是弱隔離性能讓沖突事務(wù)并行執(zhí)行和確認(rèn)提交;第二個選擇重新排序原子性和隔離性機(jī)制保證它們不會某個

時間重疊，這是一種放棄公平的事務(wù)執(zhí)行，所謂放棄公平就是不再同時照顧原子性和隔離性了，有所傾斜，放棄高標(biāo)準(zhǔn)道德要求就會帶來高自由高效率。