一般將NoSQL數(shù)據(jù)庫分為四大類:鍵值(Key-Value)存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形(Graph)數(shù)據(jù)庫。它們的數(shù)據(jù)模型、優(yōu)缺點、典型應用場景。
讓客戶滿意是我們工作的目標,不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴,公司提供的服務項目有:主機域名、雅安服務器托管、營銷軟件、網(wǎng)站建設、銅仁網(wǎng)站維護、網(wǎng)站推廣。
鍵值(Key-Value)存儲數(shù)據(jù)庫Key指向Value的鍵值對,通常用hash表來實現(xiàn)查找速度快數(shù)據(jù)無結(jié)構(gòu)化(通常只被當作字符串或者二進制數(shù)據(jù))內(nèi)容緩存,主要用于處理大量數(shù)據(jù)的高訪問負載,也用于一些日志系統(tǒng)等。
列存儲數(shù)據(jù)庫,以列簇式存儲,將同一列數(shù)據(jù)存在一起查找速度快,可擴展性強,更容易進行分布式擴展功能相對局限分布式的文件系統(tǒng)。
文檔型數(shù)據(jù)庫,Key-Value對應的鍵值對,Value為結(jié)構(gòu)化數(shù)據(jù),數(shù)據(jù)結(jié)構(gòu)要求不嚴格,表結(jié)構(gòu)可變(不需要像關系型數(shù)據(jù)庫一樣需預先定義表結(jié)構(gòu)),查詢性能不高,而且缺乏統(tǒng)一的查詢語法,Web應用。
圖形(Graph)數(shù)據(jù)庫,圖結(jié)構(gòu),利用圖結(jié)構(gòu)相關算法(如最短路徑尋址,N度關系查找等),很多時候需要對整個圖做計算才能得出需要的信息,而且這種結(jié)構(gòu)不太好做分布式的集群方案,社交網(wǎng)絡,推薦系統(tǒng)等。
Web1.0的時代,數(shù)據(jù)訪問量很有限,用一夫當關的高性能的單點服務器可以解決大部分問題。
隨著Web2.0的時代的到來,用戶訪問量大幅度提升,同時產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來的智能移動設備的普及,所有的互聯(lián)網(wǎng)平臺都面臨了巨大的性能挑戰(zhàn)。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,泛指非關系型的數(shù)據(jù)庫。
NoSQL 不依賴業(yè)務邏輯方式存儲,而以簡單的key-value模式存儲。因此大大的增加了數(shù)據(jù)庫的擴展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫 列式數(shù)據(jù)庫 Hbase Hbase
HBase是Hadoop項目中的數(shù)據(jù)庫。它用于需要對大量的數(shù)據(jù)進行隨機、實時的讀寫操作的場景中。
HBase的目標就是處理數(shù)據(jù)量非常龐大的表,可以用普通的計算機處理超過10億行數(shù)據(jù),還可處理有數(shù)百萬列元素的數(shù)據(jù)表。
Cassandra Cassandra
Apache Cassandra是一款免費的開源NoSQL數(shù)據(jù)庫,其設計目的在于管理由大量商用服務器構(gòu)建起來的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達到PB級別)。在眾多顯著特性當中,Cassandra最為卓越的長處是對寫入及讀取操作進行規(guī)模調(diào)整,而且其不強調(diào)主集群的設計思路能夠以相對直觀的方式簡化各集群的創(chuàng)建與擴展流程。
主要應用:社會關系,公共交通網(wǎng)絡,地圖及網(wǎng)絡拓譜(n*(n-1)/2)
“NoSQL,指的是非關系型的數(shù)據(jù)庫。NoSQL有時也稱作Not Only SQL的縮寫,是對不同于傳統(tǒng)的關系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)的統(tǒng)稱。NoSQL用于超大規(guī)模數(shù)據(jù)的存儲。這些類型的數(shù)據(jù)存儲不需要固定的模式,無需多余操作就可以橫向擴展?!?/p>
如何玩轉(zhuǎn) NoSQL數(shù)據(jù)庫?作者:IT專家網(wǎng)
Weather公司CIO Bryson Koehler整理出了MongoDB,Riak和Cassandra等NoSQL數(shù)據(jù)庫的特性。他指出這其中最重要的特性是“NoSQL不會限制住你”。
Weather公司,致力于天氣報告和天氣預報業(yè)務,其并不缺乏數(shù)據(jù),當然也不缺乏數(shù)據(jù)管理工具。但它為什么需要三種不同的NoSQL數(shù)據(jù)庫?
最近,我向Weather 公司的CIO Bryson Koehler提出了這個疑問,除了公司的CIO,Bryson Koehler還是其他很多業(yè)務單元的孵化者,包括Weather Channel,WeatherFX,Weather Underground,和Intellicast等。Weather公司每天獲取和處理著約20萬億字節(jié)數(shù)據(jù),對外提供當前全球天氣狀況,并為航空公司,緊急服務,貨運商,公用事業(yè),保險,以及在線天氣網(wǎng)站和天氣應用程序的用戶提供天氣預報服務。每天需求增加了數(shù)十億的天氣數(shù)據(jù)請求,并且預期響應時間要在10毫秒左右。
Riak是Weather 公司的后臺NoSQL數(shù)據(jù)庫,服務于公司的事務性存儲公用網(wǎng)絡(SUN)數(shù)據(jù)獲取平臺,它運行在多個亞馬遜網(wǎng)絡服務(AWS)的可用區(qū)域上,并以每小時15次的頻率捕獲超過20億氣象數(shù)據(jù)信息,。所以,Riak具有明確的處理規(guī)模,但該公司也使用Cassandra以及新近添加的MongoDB數(shù)據(jù)庫,為Weather.com 上IOS和Android移動應用程序服務。
Weather 公司使用了不同的產(chǎn)品,Koehler解釋說,因為“不同的工具有不同的優(yōu)勢。
Cassandra,它服務于Weather 公司以及全球消費者使用的第三方天氣應用的API數(shù)據(jù):“我們的數(shù)據(jù)分發(fā)平臺每秒處理數(shù)十萬的事務,我們發(fā)現(xiàn)Cassandra在用于全球分發(fā)數(shù)據(jù)上是一個很棒的解決方案,并且在[數(shù)據(jù)庫]讀取方面體現(xiàn)出很高的可用性 “。它本質(zhì)上為全球各地消費者所使用的數(shù)據(jù)服務,包括Weather 公司和第三方的天氣應用程序。
MongoDB,它提供了Weather.com網(wǎng)站和移動應用程序的中間層緩存功能:“離開我們的核心API,我們還沒有全部Weather.com內(nèi)容,所以MongoDB是容器和分發(fā)站,為Weather.com以及Android和iOS上的移動應用程序服務。Mongo有很多好處,這些好處基于其內(nèi)建的JSON格式以及靈活性上?!?/p>
Riak,用于消費氣象數(shù)據(jù)和觀測,包括來自世界各地的圖片和視頻等:“我們喜愛Riak因其優(yōu)秀的數(shù)據(jù)攝取能力,而且是以一種全球分布式的方式來實現(xiàn)。這對于從全球分布式平臺上獲取數(shù)據(jù)的入站式數(shù)據(jù)庫是一個真正可靠的選擇。
我曾聽說Datastax,Basho和Couchbase的高管貶低MongoDB的可擴展性,但MongoDB指向大規(guī)模部署,在Facebook對超過200萬臺移動設備上應用程序提供支持,在eHarmony公司,MongDB每天處理著數(shù)十億的潛在比賽預約。據(jù)Koehle所述,MongoDB為Weather.com和Weather.com移動應用程序處理著“每天十億交易”,“毫無疑問,你可以通過配置和部署Mongo來處理大批量的交易數(shù)據(jù)?!?/p>
盡管如此,Koehler承認,他將“很樂于看到MongoDB繼續(xù)使全球集群和多位置[功能]更加無縫化且易于使用?!?這些屬于全球性的分布式集群,復制和負載平衡是Cassandra和Riak眾所周知的功能。
從規(guī)模討論的角度來看,很少有公司達到Weather公司的經(jīng)營規(guī)模。易于開發(fā),架構(gòu)靈活性和JSON數(shù)據(jù)處理使得MongoDB的成為世界上最流行的NoSQL數(shù)據(jù)庫。這就是為什么微軟和IBM都進行了MongoDB的模仿,如微軟的Azure DocumentDB和IBM的 Cloudant,而不是Cassandra和Riak。
Weather公司可以從三個NoSQL標準降低至兩個的過程中得到鞏固,Koehler說,但公司沒有準備好這么做。
“由于我們構(gòu)造了由許多不同的數(shù)據(jù)解決方案組成的網(wǎng)狀結(jié)構(gòu),我們目前的環(huán)境已過于復雜,”他說?!拔覀兿Mo團隊一些自由的空間,讓我們可以了解所有選擇的利弊,但你將會看到一些整合?!?/p>
到了那個時候,遷移將不在是一件難事,因為“關于NoSQL數(shù)據(jù)庫最重要的事情是,你不會被困在其中,” Koehler說。“如果你的架構(gòu)和編碼正確,從一個數(shù)據(jù)庫遷移到另一個并不難。隨著模式的自由以及數(shù)據(jù)轉(zhuǎn)存技術的發(fā)展,無論前者是一個key-value存儲或其他什么形式,轉(zhuǎn)儲數(shù)據(jù)都將十分容易。“
對特定產(chǎn)品進程自定義編碼的復雜的存儲過程已經(jīng)一去不復返了,Koehler說,但關于“結(jié)構(gòu)化和編碼正確”還有很多需要考慮的地方?這樣做是為了避免特殊供應商提供的工具和功能可能讓你身陷其中。他舉了亞馬遜網(wǎng)絡服務“(AWS)的消息服務為例。
“你不必讓服務在云中運行,”他解釋說?!澳憧梢灾徊渴鹱约旱腞abbitMQ的環(huán)境,而不是陷于其中,所以你可以將一個原先部署在AWS 上的應用程序轉(zhuǎn)而部署在谷歌計算云服務上。無論它是數(shù)據(jù)平臺,存儲環(huán)境,或云計算環(huán)境,都要小心別讓自己局限在一個僅由一個供應商提供的小范圍空間內(nèi)“。
轉(zhuǎn)載