1. 鍵值數(shù)據(jù)庫
讓客戶滿意是我們工作的目標,不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴,公司提供的服務項目有:申請域名、網(wǎng)站空間、營銷軟件、網(wǎng)站建設、振安網(wǎng)站維護、網(wǎng)站推廣。
相關產(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)
答案:A
1.文檔型數(shù)據(jù)庫
作為最受歡迎的NoSQL產(chǎn)品,文檔型數(shù)據(jù)庫MongoDB當仁不讓地占據(jù)了第一的位置,同時它也是所有NoSQL數(shù)據(jù)庫中排名最靠前的產(chǎn)品(總排行榜第七名)。Apache基金會的CouchDB排在第二,基于.Net的數(shù)據(jù)庫RavenDB排在第三,Couchbase排在第四。
2.鍵值(Key-value)數(shù)據(jù)庫
鍵值(Key-value)數(shù)據(jù)庫是NoSQL領域中應用范圍最廣的,也是涉及產(chǎn)品最多的一種模型。從最簡單的BerkeleyDB到功能豐富的分布式數(shù)據(jù)庫Riak再到Amazon托管的DynamoDB不一而足。
在鍵值數(shù)據(jù)庫流行度排行中,Redis不出意外地排名第一,它是一款由Vmware支持的內存數(shù)據(jù)庫,總體排名第十一。排在第二位的是Memcached,它在緩存系統(tǒng)中應用十分廣泛。排在之后的是Riak、BerkeleyDB、SimpleDB、DynamoDB以及甲骨文的Oracle NoSQL數(shù)據(jù)庫。值得注意的是,Oracle NoSQL數(shù)據(jù)庫上榜不久,得分已經(jīng)翻番,上升勢頭非常迅猛。
3. 列式存儲
列式存儲被視為NoSQL數(shù)據(jù)庫中非常重要的一種模式,其中Cassandra流行度最高,它已經(jīng)由Facebook轉交給到Apache進行管理,同時Cassandra在全體數(shù)據(jù)庫排名中排在第十位,緊隨MongoDB成為第二受歡迎的NoSQL數(shù)據(jù)庫?;贖adoop的Hbase排在第二位,Hypertable排在第三。而Google的BigTable并未列入排名,原因是它并未正式公開。
個人不認為nosql在少量數(shù)據(jù)存儲上有啥優(yōu)勢。nosql主要解決的是auto sharding的問題,你不需要sharding,搞啥nosql. 作者:方圓 鏈接:
即非關系型數(shù)據(jù)庫和關系型數(shù)據(jù)庫。
MySQL的優(yōu)點:事務處理—保持數(shù)據(jù)的一致性;由于以標準化為前提,數(shù)據(jù)更新的開銷很?。ㄏ嗤淖侄位旧现挥幸惶帲?;可以進行Join等復雜查詢
NoSQL的優(yōu)點:首先它是基于內存的,也就是數(shù)據(jù)放在內存中,而不是像數(shù)據(jù)庫那樣把數(shù)據(jù)放在磁盤上,而內存的讀取速度是磁盤讀取速度的幾十倍到上百倍,所以NoSQL工具的速度遠比數(shù)據(jù)庫讀取速度要快得多,滿足了高響應的要求。即使NoSQL將數(shù)據(jù)放在磁盤中,它也是一種半結構化的數(shù)據(jù) 格式,讀取到解析的復雜度遠比MySQL要簡單,這是因為MySQL存儲的是經(jīng)過結構化、多范式等有復雜規(guī)則的數(shù)據(jù),還原為內存結構的速度較慢。NoSQL在很大程度上滿足了高并發(fā)、快速讀/和響應的要求,所以它也是Java互聯(lián)網(wǎng)系統(tǒng)的利器。
簡單的擴展:典型例子是Cassandra,由于其架構是類似于經(jīng)典的P2P,所以能通過輕松地添加新的節(jié)點來擴展這個集群;
低廉的成本:這是大多數(shù)分布式數(shù)據(jù)庫共有的特點,因為主要都是開源軟件,沒有昂貴的License成本;
NoSQL的缺點:大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務,也不像 SQL Server和Oracle那樣能提供各種附加功能,比如BI和報表等; 不提供對SQL的支持
那么該如何選擇?
如果規(guī)模和性能比24小時的數(shù)據(jù)一致性更重要,那NoSQL是一個理想的選擇 (NoSQL依賴于BASE模型——基本可用、軟狀態(tài)、最終一致性)。
但如果要保證到“始終一致”,尤其是對于機密信息和財務信息,那么MySQL很可能是最優(yōu)的選擇(MySQL依賴于ACID模型——原子性、一致性、獨立性和耐久性)。
如果關系數(shù)據(jù)庫在你的應用場景中,完全能夠很好的工作,而你又是非常善于使用和維護關系數(shù)據(jù)庫的,那么我覺得你完全沒有必要遷移到NoSQL上面,除非你是個喜歡折騰的人。如果你是在金融,電信等以數(shù)據(jù)為王的關鍵領域,目前使用的是Oracle數(shù)據(jù)庫來提供高可靠性的,除非遇到特別大的瓶頸,不然也別貿(mào)然嘗試NoSQL。
然而,在WEB2.0的網(wǎng)站中,關系數(shù)據(jù)庫大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫可擴展上都花費了開發(fā)人員相當多的精力來優(yōu)化,比如做分表分庫(database sharding)、主從復制、異構復制等等,然而,這些工作需要的技術能力越來越高,也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場合,那么我覺得你應該嘗試一下NoSQL了。
具體問題具體分析
MySQL體積小、速度快、成本低、結構穩(wěn)定、便于查詢,可以保證數(shù)據(jù)的一致性,但缺乏靈活性。
NoSQL高性能、高擴展、高可用,不用局限于固定的結構,減少了時間和空間上的開銷,卻又很難保證數(shù)據(jù)一致性。
————————————————
版權聲明:本文為CSDN博主「蒟蒻熊」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權協(xié)議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:
a. SQL數(shù)據(jù)存在特定結構的表中;而NoSQL則更加靈活和可擴展,存儲方式可以省是JSON文檔、哈希表或者其他方式。
b. 在SQL中,必須定義好表和字段結構后才能添加數(shù)據(jù),例如定義表的主鍵(primary key),索引(index),觸發(fā)器(trigger),存儲過程(stored procedure)等。表結構可以在被定義之后更新,但是如果有比較大的結構變更的話就會變得比較復雜。在NoSQL中,數(shù)據(jù)可以在任何時候任何地方添加,不需要先定義表。
c. SQL中如果需要增加外部關聯(lián)數(shù)據(jù)的話,規(guī)范化做法是在原表中增加一個外鍵,關聯(lián)外部數(shù)據(jù)表。而在NoSQL中除了這種規(guī)范化的外部數(shù)據(jù)表做法以外,我們還能用如下的非規(guī)范化方式把外部數(shù)據(jù)直
接放到原數(shù)據(jù)集中,以提高查詢效率。缺點也比較明顯,更新審核人數(shù)據(jù)的時候將會比較麻煩。
d. SQL 中可以使用JOIN表鏈接方式將多個關系數(shù)據(jù)表中的數(shù)據(jù)用一條簡單的查詢語句查詢出來。NoSQL暫未提供類似JOIN的查詢方式對多個數(shù)據(jù)集中的數(shù)據(jù)做查詢。所以大部分NoSQL使用非規(guī)范化的數(shù)據(jù)存儲方式存儲數(shù)據(jù)。
e. SQL中不允許刪除已經(jīng)被使用的外部數(shù)據(jù),而NoSQL中則沒有這種強耦合的概念,可以隨時刪除任何數(shù)據(jù)。
f. SQL中如果多張表數(shù)據(jù)需要同批次被更新,即如果其中一張表更新失敗的話其他表也不能更新成功。這種場景可以通過事務來控制,可以在所有命令完成后再統(tǒng)一提交事務。而NoSQL中沒有事務這個概念,每一個數(shù)據(jù)集的操作都是原子級的。
g. 在相同水平的系統(tǒng)設計的前提下,因為NoSQL中省略了JOIN查詢的消耗,故理論上性能上是優(yōu)于SQL的。
一般將NoSQL數(shù)據(jù)庫分為四大類:鍵值(Key-Value)存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形(Graph)數(shù)據(jù)庫。它們的數(shù)據(jù)模型、優(yōu)缺點、典型應用場景。
鍵值(Key-Value)存儲數(shù)據(jù)庫Key指向Value的鍵值對,通常用hash表來實現(xiàn)查找速度快數(shù)據(jù)無結構化(通常只被當作字符串或者二進制數(shù)據(jù))內容緩存,主要用于處理大量數(shù)據(jù)的高訪問負載,也用于一些日志系統(tǒng)等。
列存儲數(shù)據(jù)庫,以列簇式存儲,將同一列數(shù)據(jù)存在一起查找速度快,可擴展性強,更容易進行分布式擴展功能相對局限分布式的文件系統(tǒng)。
文檔型數(shù)據(jù)庫,Key-Value對應的鍵值對,Value為結構化數(shù)據(jù),數(shù)據(jù)結構要求不嚴格,表結構可變(不需要像關系型數(shù)據(jù)庫一樣需預先定義表結構),查詢性能不高,而且缺乏統(tǒng)一的查詢語法,Web應用。
圖形(Graph)數(shù)據(jù)庫,圖結構,利用圖結構相關算法(如最短路徑尋址,N度關系查找等),很多時候需要對整個圖做計算才能得出需要的信息,而且這種結構不太好做分布式的集群方案,社交網(wǎng)絡,推薦系統(tǒng)等。