什么是NoSQL數(shù)據(jù)庫？

NoSQL，是not only sql，是非關系數(shù)據(jù)庫，不同于oracle等關系數(shù)據(jù)庫。hadoop,是分布式解決方案，即為Mapreduce（計算的）和HDFS（文件系統(tǒng)）,使用Hadoop和NoSQL可以構造海量數(shù)據(jù)解決方案。

創(chuàng)新互聯(lián)為客戶提供專業(yè)的網(wǎng)站設計制作、成都網(wǎng)站設計、程序、域名、空間一條龍服務，提供基于WEB的系統(tǒng)開發(fā). 服務項目涵蓋了網(wǎng)頁設計、網(wǎng)站程序開發(fā)、WEB系統(tǒng)開發(fā)、微信二次開發(fā)、成都做手機網(wǎng)站等網(wǎng)站方面業(yè)務。

nosql數(shù)據(jù)庫的幾大類型

1. 鍵值數(shù)據(jù)庫

相關產(chǎn)品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached

應用：內容緩存

優(yōu)點：擴展性好、靈活性好、大量寫操作時性能高

缺點：無法存儲結構化信息、條件查詢效率較低

使用者：百度云（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Ridis和Memcached）

2. 列族數(shù)據(jù)庫

相關產(chǎn)品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS

應用：分布式數(shù)據(jù)存儲與管理

優(yōu)點：查找速度快、可擴展性強、容易進行分布式擴展、復雜性低

使用者：Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Facebook（HBase）

3. 文檔數(shù)據(jù)庫

相關產(chǎn)品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit

應用：存儲、索引并管理面向文檔的數(shù)據(jù)或者類似的半結構化數(shù)據(jù)

優(yōu)點：性能好、靈活性高、復雜性低、數(shù)據(jù)結構靈活

缺點：缺乏統(tǒng)一的查詢語言

使用者：百度云數(shù)據(jù)庫（MongoDB）、SAP（MongoDB）

4. 圖形數(shù)據(jù)庫

圖形數(shù)據(jù)庫-使用圖作為數(shù)據(jù)模型來存儲數(shù)據(jù)。

相關產(chǎn)品：Neo4J、OrientDB、InfoGrid、GraphDB

應用：大量復雜、互連接、低結構化的圖結構場合，如社交網(wǎng)絡、推薦系統(tǒng)等

優(yōu)點：靈活性高、支持復雜的圖形算法、可用于構建復雜的關系圖譜

缺點：復雜性高、只能支持一定的數(shù)據(jù)規(guī)模

使用者：Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）

分布式數(shù)據(jù)庫和nosql區(qū)別嗎

互聯(lián)網(wǎng)公司常用的基本集中在以下幾種，每種只舉一個比較常見或者應用比較成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同時提供了更加豐富的數(shù)據(jù)結構和運算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機恢復，同時支持replication提供讀可擴展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盤的key-value storage, 模型單一簡單，數(shù)據(jù)量不受限于內存大小，數(shù)據(jù)落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序寫盤的方式對于新硬件ssd再適合不過了，不足是僅提供了一個庫，需要自己封裝server端。

3. Document Store: Mongodb

分布式nosql，具備了區(qū)別mysql的最大亮點：可擴展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對于數(shù)據(jù)量遠超內存限制的場景來說，還需要慎重。

4. Column Table Store: HBase

這個富二代似乎不用贅述了，最大的優(yōu)勢是開源，對于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴展性方面是最強的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產(chǎn)品不少，來解決諸如join、聚集運算等復雜查詢。

什么是NoSQL數(shù)據(jù)庫

什么是NoSQL數(shù)據(jù)庫？從名稱“非SQL”或“非關系型”衍生而來，這些數(shù)據(jù)庫不使用類似SQL的查詢語言，通常稱為結構化存儲。這些數(shù)據(jù)庫自1960年就已經(jīng)存在，但是直到現(xiàn)在一些大公司（例如Google和Facebook）開始使用它們時，這些數(shù)據(jù)庫才流行起來。該數(shù)據(jù)庫最明顯的優(yōu)勢是擺脫了一組固定的列、連接和類似SQL的查詢語言的限制。有時，NoSQL這個名稱也可能表示“不僅僅SQL”，來確保它們可能支持SQL。 NoSQL數(shù)據(jù)庫使用諸如鍵值、寬列、圖形或文檔之類的數(shù)據(jù)結構，并且可以如JSON之類的不同格式存儲。

為什么大部分NoSQL不提供分布式事務

像MongoDB, Cassandra, HBase, DynamoDB, 和

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

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

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

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

作失敗。

這種協(xié)調是昂貴的，會增加延遲時間，關鍵問題是，當協(xié)調沒有完成時，其他操作是不能讀取事務中寫操作結果的，這是因為事務的all-or-

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

影響，不只是吞吐量還包括延遲時間，這樣大部分NoSQL數(shù)據(jù)庫因為性能問題就選擇不提供分布式事務。

MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務，這是因為所有信息都和一個鍵key有關，這個鍵是存儲在單個服務器上，這樣基于單鍵的事務不會帶來復雜的分布式協(xié)調。

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

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

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

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

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

FIT是如下進行權衡：

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

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

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

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

次確認事務完成，這樣排隊式的確認commit事務是很浪費時間的，放棄公平性，意味著可以在事務外面進行協(xié)調，這樣就只是增加了協(xié)調時間，不會增加互相

沖突事務因為彼此沖突而不能運行所耽擱的時間，當系統(tǒng)不需要公平性時，需要根據(jù)事務的優(yōu)先級或延遲等標準進行指定先后執(zhí)行順序，這樣就能夠獲得很好的吞吐

量。

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

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

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

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

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

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

新聞名稱：nosql分布式,分布式數(shù)據(jù)庫和nosql
標題來源：http://chinadenli.net/article7/dsejsoj.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、關鍵詞優(yōu)化、響應式網(wǎng)站、Google

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)