1. 程式人生 > >Nosql資料庫的分類及應用場景

Nosql資料庫的分類及應用場景

nosql是not only sql的意思。是近今年新發展起來的儲存系統。當前使用最多的是key-value模型,是一種非關係型資料庫主要是解決是海量資料下的資料庫效能和擴充套件能力

最大的特點在於要求的資料量大,對事物的要求低

NoSQL 它打破了長久以來關係型資料庫與ACID理論大一統的局面。NoSQL 資料儲存不需要固定的表結構,通常也不存在連線操作。在大資料存取上具備關係型資料庫無法比擬的效能優勢。

NoSQL與關係型資料庫設計理念比較

關係型資料庫中的表都是儲存一些格式化的資料結構,每個元組欄位的組成都一樣,即使不是每個元組都需要所有的欄位,但資料庫會為每個元組分配所有的欄位,這樣的結構可以便於表與表之間進行連線等操作,但從另一個角度來說它也是關係型資料庫效能瓶頸的一個因素。而非關係型資料庫以鍵值對儲存,它的結構不固定,每一個元組可以有不一樣的欄位,每個元組可以根據需要增加一些自己的鍵值對,這樣就不會侷限於固定的結構,可以減少一些時間和空間的開銷。

傳統關係型資料庫單表支撐到千萬級基本上就達到了瓶頸,要通過分庫,分表,多副本等多種方式來解決,典型的如淘寶的生成庫,但是這需要有強大的資料庫團隊支撐,成本較高。NoSQL就為了解決在資料增長過程中面臨的效能,水平擴充套件問題。當然選用NoSQL系統在查詢複雜度等多個維度都會受到約束,選用關係型資料庫分庫分表後其實也是一樣,複雜查詢排序等能力是不能直接使用了。

1. 它們可以處理超大量的資料。

NoSQL資料庫都具有非常高的讀寫效能,尤其在大資料量下,同樣表現優秀。這得益於它的無關係性,資料庫的結構簡單。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對web2.0的互動頻繁的應用,Cache效能不高。而NoSQL的 Cache是記錄級的,是一種細粒度的Cache,所以NoSQL在這個層面上來說就要效能高很多了。

2. 它們執行在便宜的PC伺服器叢集上。

PC叢集擴充起來非常方便並且成本很低,避免了“sharding”操作的複雜性和成本。

3. 它們擊碎了效能瓶頸。

NoSQL的支持者稱,通過NoSQL架構可以省去將Web或Java應用和資料轉換成SQL友好格式的時間,執行速度變得更快。

“SQL並非適用於所有的程式程式碼,” 對於那些繁重的重複操作的資料,SQL值得花錢。但是當資料庫結構非常簡單時,SQL可能沒有太大用處。

4. 沒有過多的操作。

雖然NoSQL的支持者也承認關係資料庫提供了無可比擬的功能集合,而且在資料完整性上也發揮絕對穩定,他們同時也表示,企業的具體需求可能沒有那麼多。

5. Bootstrap支援。

因為NoSQL專案都是開源的,因此它們缺乏供應商提供的正式支援。這一點它們與大多數開源專案一樣,不得不從社群中尋求支援

NoSQL資料庫的型別

NoSQL可以大體上分為4個種類:Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。下面就一覽這些型別的特性:

一、 鍵值(Key-Value)資料庫

鍵值資料庫就像在傳統語言中使用的雜湊表。你可以通過key來新增、查詢或者刪除資料,鑑於使用主鍵訪問,所以會獲得不錯的效能及擴充套件性。

產品:Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

有誰在使用:GitHub (Riak)、BestBuy (Riak)、Twitter (Redis和Memcached)、StackOverFlow (Redis)、 Instagram (Redis)、Youtube (Memcached)、Wikipedia(Memcached)

適用的場景

儲存使用者資訊,比如會話、配置檔案、引數、購物車等等。這些資訊一般都和ID(鍵)掛鉤,這種情景下鍵值資料庫是個很好的選擇。

不適用場景

1. 取代通過鍵查詢,而是通過值來查詢。Key-Value資料庫中根本沒有通過值查詢的途徑。

2. 需要儲存資料之間的關係。在Key-Value資料庫中不能通過兩個或以上的鍵來關聯資料。

3. 事務的支援。在Key-Value資料庫中故障產生時不可以進行回滾。

二、 面向文件(Document-Oriented)資料庫

面向文件資料庫會將資料以文件的形式儲存。每個文件都是自包含的資料單元,是一系列資料項的集合。每個資料項都有一個名稱與對應的值,值既可以是簡單的資料型別,如字串、數字和日期等;也可以是複雜的型別,如有序列表和關聯物件。資料儲存的最小單位是文件,同一個表中儲存的文件屬性可以是不同的,資料可以使用XML、JSON或者JSONB等多種形式儲存。

產品:MongoDB、CouchDB、RavenDB

有誰在使用:SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)

適用的場景

1. 日誌。企業環境下,每個應用程式都有不同的日誌資訊。Document-Oriented資料庫並沒有固定的模式,所以我們可以使用它儲存不同的資訊。

2. 分析。鑑於它的弱模式結構,不改變模式下就可以儲存不同的度量方法及新增新的度量。

不適用場景

在不同的文件上新增事務。Document-Oriented資料庫並不支援文件間的事務,如果對這方面有需求則不應該選用這個解決方案。

三、 列儲存(Wide Column Store/Column-Family)資料庫

列儲存資料庫將資料儲存在列族(column family)中,一個列族儲存經常被一起查詢的相關資料。舉個例子,如果我們有一個Person類,我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下,姓名和年齡就會被放入一個列族中,而薪資則在另一個列族中。

產品:Cassandra、HBase

有誰在使用:Ebay (Cassandra)、Instagram (Cassandra)、NASA (Cassandra)、Twitter (Cassandra and HBase)、Facebook (HBase)、Yahoo!(HBase)

適用的場景

1. 日誌。因為我們可以將資料儲存在不同的列中,每個應用程式可以將資訊寫入自己的列族中。

2. 部落格平臺。我們儲存每個資訊到不同的列族中。舉個例子,標籤可以儲存在一個,類別可以在一個,而文章則在另一個。

不適用場景

1. 如果我們需要ACID事務。Vassandra就不支援事務。

2. 原型設計。如果我們分析Cassandra的資料結構,我們就會發現結構是基於我們期望的資料查詢方式而定。在模型設計之初,我們根本不可能去預測它的查詢方式,而一旦查詢方式改變,我們就必須重新設計列族。

四、 圖(Graph-Oriented)資料庫

圖資料庫允許我們將資料以圖的方式儲存。實體會被作為頂點,而實體之間的關係則會被作為邊。比如我們有三個實體,Steve Jobs、Apple和Next,則會有兩個“Founded by”的邊將Apple和Next連線到Steve Jobs。

產品:Neo4J、Infinite Graph、OrientDB

有誰在使用:Adobe (Neo4J)、Cisco (Neo4J)、T-Mobile (Neo4J)

適用的場景

1. 在一些關係性強的資料中

2. 推薦引擎。如果我們將資料以圖的形式表現,那麼將會非常有益於推薦的制定

不適用場景

不適合的資料模型。圖資料庫的適用範圍很小,因為很少有操作涉及到整個圖。

問題:

NoSQL與Hadoop的區別?

NoSQL,是not only sql,是非關係資料庫,不同於oracle等關係資料庫,Hadoop框架中的HBase即為NoSQL資料庫。

hadoop是分散式解決方案,即為Mapreduce(計算的)和HDFS(檔案系統),使用Hadoop和NoSQL可以構造海量資料解決方案。有很多子模組,包含HDFS、MapReduce以及HBase

現在招聘要求比較多的是redis及mongodb這兩種。