nosql数据库学习总结
生活随笔
收集整理的這篇文章主要介紹了
nosql数据库学习总结
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
大數(shù)據(jù)時代的數(shù)據(jù)庫選擇:SQL還是NoSQL?
執(zhí)行大數(shù)據(jù)項目的企業(yè)面對的關鍵決策之一是使用哪個數(shù)據(jù)庫,SQL還是NoSQL?SQL有著驕人的業(yè)績,龐
大的安裝基礎;而NoSQL正在獲得可觀的收益,且有很多支持者。我們來看看兩位專家對這個問題的看法
一、專家簡介
VoltDB公司首席技術官Ryan Betts表示,SQL已經(jīng)贏得了大型企業(yè)的廣泛部署,大數(shù)據(jù)是它可以支持的另
一個領域。
Couchbase公司首席執(zhí)行官Bob Wiederhold表示,NoSQL是可行的選擇,并且從很多方面來看,它是大數(shù)
據(jù)的最佳選擇,特別是涉及到可擴展性時。
二、SQL經(jīng)歷時間的考驗,并仍然在蓬勃發(fā)展
結構化查詢語言(SQL)是經(jīng)過時間考驗的勝利者,它已經(jīng)主宰了幾十年,目前大數(shù)據(jù)公司和組織(例如谷
歌、Facebook、Cloudera和Apache)正在積極投資于SQL。
在成為主導技術(例如SQL)后,有時候我們很容易忘記其優(yōu)越性。SQL的獨特優(yōu)勢包括:
1. SQL能夠加強與數(shù)據(jù)的交互,并允許對單個數(shù)據(jù)庫設計提出問題。這是很關鍵的特征,因為無法交互
的數(shù)據(jù)基本上是沒用的,并且,增強的交互性能夠帶來新的見解、新的問題和更有意義的未來交互。
2. SQL是標準化的,使用戶能夠跨系統(tǒng)運用他們的知識,并對第三方附件和工具提供支持。
3. SQL能夠擴展,并且是多功能和經(jīng)過時間驗證的,這能夠解決從快寫為主導的傳輸?shù)綊呙杳芗蜕钊?
分析等問題。
4. SQL對數(shù)據(jù)呈現(xiàn)和存儲采用正交形式,一些SQL系統(tǒng)支持JSON和其他結構化對象格式,比NoSQL具有更
好的性能和更多功能。
雖然NoSQL的出現(xiàn)帶來了一些影響,但SQL仍然主導著市場,并在大數(shù)據(jù)領域贏得了很多投資和廣泛部署
。
NoSQL的說法很含糊,對于本次討論,我借用Rick Cattell對NoSQL的定義,即提供簡單操作(例如密鑰/
數(shù)值存儲)或簡單記錄和索引,并專注于這些簡單操作的橫向可擴展性的系統(tǒng)。
很顯然,現(xiàn)在很多新的數(shù)據(jù)庫并不是都一樣,認識每種數(shù)據(jù)庫背后的原理以及潛在問題是成功的關鍵。
NoSQL的主要特點使其更適合于特定的問題。例如,圖形數(shù)據(jù)庫更適合于數(shù)據(jù)通過關系組織的情況,而專
門的文本搜索系統(tǒng)更適合于需要實時搜索的情況。
在這里,讓我們看看SQL系統(tǒng)的主要優(yōu)勢和差異化功能:
* SQL可實現(xiàn)交互性。 SQL是一種聲明性查詢語言。用戶說出他們想要什么(例如,顯示過去五年三月份
期間頂級客戶的地理位置),數(shù)據(jù)庫內(nèi)部就會構件算法并提取請求的結果。相比之下,NoSQL編程創(chuàng)新
MapReduce是一種程序性查詢技術。在用戶提出請求時,MapReduce要求用戶不僅說出自己想要什么,而
且要求他們陳述如何產(chǎn)生答案。
這聽起來像一個無趣的技術差異,但這很關鍵,原因在于:首先,聲明性SQL查詢更容易通過圖形化工具
以及點擊報告構建器來構建。這讓分析師、操作員、管理者和其他不具備軟件編程能力的員工進行數(shù)據(jù)
庫查詢;其次,數(shù)據(jù)庫引擎可以利用內(nèi)部信息來選擇最有效的算法。改變數(shù)據(jù)庫的物理布局或數(shù)據(jù)庫,最
佳算法仍然能夠計算出來。而在程序性系統(tǒng)中,編程人員需要重新訪問和重新編程算法,這是非常昂貴
且容易出錯的過程。
市場理解這個關鍵區(qū)別。在2010年,谷歌宣布部署SQL來補充MapReduce,主要受內(nèi)部用戶需求所驅動。
最近,Facebook發(fā)布了Presto(一種SQL部署)來查詢其PB級HDFS集群。根據(jù)Facebook表示:“隨著我們的
倉庫增長到PB級,以及我們的需求變化,我們清楚地意識到,我們需要一個提供低延時查詢的互動系統(tǒng)
。”此外,Cloudera也正在構建Impala—另一個基于HDFS的SQL部署。
* SQL是標準化的。 雖然供應商有時候會添加自己的語言到SQL界面,但SQL的核心是標準化的,還有其
他規(guī)格(例如ODBC和JDBC)提供廣泛可用的穩(wěn)定界面到SQL存儲。這帶來了一個管理和操作工具生態(tài)系統(tǒng),
可以在SQL系統(tǒng)之上設計、監(jiān)控、檢查、探索和構建應用程序。
SQL用戶和程序員可用跨多個后端系統(tǒng)重復使用其API和UI知識,減少了應用程序的開發(fā)時間。標準化還
允許聲明性第三方提取、轉換、加載(ETL)工具,使企業(yè)可以在數(shù)據(jù)庫之間以及跨系統(tǒng)傳輸數(shù)據(jù)。
* SQL可擴展。 認為SQL必須犧牲以獲得可擴展性的看法,完全是錯誤的。如前所述,Facebook創(chuàng)建了一
個SQL界面來查詢PB級數(shù)據(jù)。SQL能夠非常有效地運行極快的ACID傳輸。SQL對數(shù)據(jù)存儲和索引提供的抽象
[注]化允許跨各種問題和數(shù)據(jù)集大小的一致使用,讓SQL可以跨集群復制數(shù)據(jù)存儲有效地運行。使用SQL
作為界面獨立于構建云、規(guī)模或HA系統(tǒng),SQL中并沒有什么在阻止和限制容錯、高可用性和復制。事實上
,所有現(xiàn)代SQL系統(tǒng)支持云友好型橫向可擴展性、復制和容錯性。
* SQL支持JSON。 幾年前,很多SQL系統(tǒng)增加了XML文檔支持。現(xiàn)在,隨著JSON成為一種流行的數(shù)據(jù)交換
格式,SQL供應商也紛紛加入了JSON型的支持。基于現(xiàn)在靈活的編程過程和web基礎設施的正常運行時間
要求,我們很需要結構化數(shù)據(jù)類型的支持。Oracle 12c、PostgreSQL 9.2、VoltDB和其他支持JSON的數(shù)
據(jù)庫,通常具有優(yōu)于“原生”JSON的性能。
SQL將繼續(xù)贏得市場份額,并會繼續(xù)看到新的投資和部署。NoSQL數(shù)據(jù)庫提供專有查詢語言或簡單的鍵值
語義,而沒有更深層次的技術差異化。現(xiàn)代SQL系統(tǒng)提供可擴展性的同時,還支持更豐富的查詢語義,并
有龐大的用戶安裝基礎,廣泛的生態(tài)系統(tǒng)整合和深度企業(yè)部署。
三、NoSQL更適合大數(shù)據(jù)應用程序
NoSQL越來越多地被認為是關系型數(shù)據(jù)庫的可行替代品,特別是對于大數(shù)據(jù)應用程序。此外,無模式數(shù)據(jù)
模型通常更適合于現(xiàn)在捕捉和處理的數(shù)據(jù)種類和類型。
當我們談論NoSQL領域的大數(shù)據(jù)時,我們指的是從操作數(shù)據(jù)庫讀取和寫入。不要將操作數(shù)據(jù)庫與分析數(shù)據(jù)
庫混淆,這通常會查看大量數(shù)據(jù),并從這些數(shù)據(jù)獲取可視性。
雖然操作數(shù)據(jù)庫的大數(shù)據(jù)看起來不具有可分析性,但操作數(shù)據(jù)庫通常會存儲超大量用戶的大型數(shù)據(jù)集,
這些用戶經(jīng)常需要訪問數(shù)據(jù)來實時執(zhí)行交易。這種數(shù)據(jù)庫的操作規(guī)模也解釋了NoSQL的關鍵特性,也就是
為什么NoSQL是大數(shù)據(jù)應用程序的關鍵的原因。
四、NoSQL是可擴展性的關鍵
每次技術行業(yè)經(jīng)歷硬件發(fā)展的根本性轉變時,都會出現(xiàn)一個拐點。在數(shù)據(jù)庫領域,從縱向擴展到橫向擴
展的轉變推動了NoSQL的發(fā)展。關系型數(shù)據(jù)庫(包括來自甲骨文和IBM的數(shù)據(jù)庫)是縱向擴展。也就是說,
它們是集中式、共享一切的技術,只能通過增加更多昂貴的硬件來擴展。
而NoSQL數(shù)據(jù)庫是分布式橫向擴展技術。它們使用了分布式節(jié)點集(稱為集群)來提供高度彈性擴展功能,
讓用戶可以添加節(jié)點來動態(tài)處理負載。
分布式橫向擴展的做法通常要比縱向做法更加便宜。商業(yè)關系型數(shù)據(jù)庫的授權費用也讓人望而卻步,因
為他們的價格是按每臺服務器來計算。另一方面,NoSQL數(shù)據(jù)庫通常是開源技術,按照運行的服務器集群
收費,而且價格相對便宜。
五、NoSQL是靈活性的關鍵
關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)模型有很大的不同。關系型模式獲取數(shù)據(jù),并將數(shù)據(jù)分配到很多相互關聯(lián)的表
中,這些表通過外鍵相互應用。
當用戶需要對數(shù)據(jù)集運行查詢時,所需信息需要從多個表中收集(通常涉及數(shù)百個企業(yè)應用程序),并結
合這些信息,再提供給應用程序。同樣地,當寫入數(shù)據(jù)時,需要在多個表協(xié)調(diào)和執(zhí)行寫入。當數(shù)據(jù)相對
較少,并且,數(shù)據(jù)以較慢速度流入數(shù)據(jù)庫時,關系型數(shù)據(jù)庫通常能夠捕捉和存儲信息。然而,現(xiàn)在的應
用程序通常需要快速寫入(和讀取)海量數(shù)據(jù)。
NoSQL數(shù)據(jù)庫采用非常不同的模式。在其核心,NoSQL數(shù)據(jù)庫其實是“NoREL”,或者說非關系型,這意味
著它們沒有依賴于表以及表之間的聯(lián)系,以存儲和組織信息。例如,以文檔為導向的NoSQL數(shù)據(jù)庫獲取你
想要存儲的數(shù)據(jù),并采用JSON格式整合到文檔中。每個JSON文檔可以被你的應用程序視為一個對象。
JSON文檔可能會提取跨越25個表的數(shù)據(jù),將數(shù)據(jù)集成到一個文檔中。
聚合這些信息可能會導致信息重復,但由于存儲已不再是一個成本問題,數(shù)據(jù)模型靈活性、發(fā)布所產(chǎn)生
文檔的簡便性以及讀取和寫入性能提高,讓這成為不錯的選擇。
六、NoSQL是大數(shù)據(jù)應用程序的關鍵
通過第三方(包括社交媒體網(wǎng)站),數(shù)據(jù)正變得越來越容易捕捉和訪問。這些數(shù)據(jù)包括:個人用戶信息、
地理位置數(shù)據(jù)、用戶生產(chǎn)的內(nèi)容、機器記錄數(shù)據(jù)和傳感器產(chǎn)生的數(shù)據(jù)。企業(yè)還可以依賴于大數(shù)據(jù)來推動
其關鍵任務型應用程序。同時,企業(yè)正在轉向到NoSQL數(shù)據(jù)庫,因為這種數(shù)據(jù)庫非常適合現(xiàn)在新型的數(shù)據(jù)
類型。
開發(fā)人員想要一個靈活的數(shù)據(jù)庫,可以很容易適應新的數(shù)據(jù)類型,并且,不會受第三方數(shù)據(jù)供應商的內(nèi)
容結構變化的影響。大多數(shù)新數(shù)據(jù)是非結構化和半結構化,因此,開發(fā)人員也需要能夠有效存儲這些數(shù)
據(jù)的數(shù)據(jù)庫。然而,關系型數(shù)據(jù)庫采用的嚴格定義的基于模式的做法讓其不可能快速整合新數(shù)據(jù)類型,
并且很不適合于非結構化和半結構化數(shù)據(jù)。
總體來說,隨著web和移動應用程序的增加、新的趨勢、網(wǎng)上消費者行為的轉變以及新的數(shù)據(jù)類型的出現(xiàn)
,行業(yè)需要能夠提供可擴展的靈活的數(shù)據(jù)庫技術來管理和訪問數(shù)據(jù)。NoSQL技術是有效滿足這些需求的唯
一可行解決方案。
========
初識NoSQL NoSql數(shù)據(jù)庫入門 NoSql數(shù)據(jù)庫基礎知識
大家有沒有聽說過“NoSQL”呢?大家可能會誤以為是“No!SQL”的縮寫,但實際上,它是“Not Only?
SQL”的縮寫。它的意義是:適用關系型數(shù)據(jù)庫的時候就使用關系型數(shù)據(jù)庫,不適用的時候也沒有必要非
使用關系型數(shù)據(jù)庫不可,可以考慮使用更加合適的數(shù)據(jù)存儲。
..做了一年的大一年度項目了,對于關系型數(shù)據(jù)庫結構還是有些了解了,有的時候還是覺得這種二維表
不是很順手。在看過一篇文章之后,對NoSQL有了初步的了解,
(https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data)。
這篇文章寫的很好,確實寫出來了在實際情況下NoSQL的“用武之地”,而且用了MineCraft作分析,但
是也許不夠全面。比如文章中只是提到了,entity數(shù)據(jù)用關系型怎么存,event數(shù)據(jù)用NoSQL怎么存,我
想借我這篇文章,來分析一下event類型的數(shù)據(jù)原始的關系型數(shù)據(jù)庫是怎樣存數(shù)據(jù)的,然后再對這兩種儲
存方式做一種對比,算是對原文都一種補充吧。
對于這種死亡事件,有這樣的兩條數(shù)據(jù),一個是關于creeper的爆炸,一種是掉進巖漿。如果必須用關系
型二維表數(shù)據(jù)庫,我會這樣存儲。(如果您還不知道是什么樣的數(shù)據(jù),可以先看之后的NoSQL儲存方法,
那樣看起來更清楚。)
這種情況的數(shù)據(jù)可以說是數(shù)據(jù)庫設計中比較復雜的一種情況了,因為它包含兩種情況(當然不止這兩種
情況,那么就會產(chǎn)生更多的結構),不同情況的數(shù)據(jù)表結構是不同的,這非常麻煩。我們一般的解決方
案是設計四個表格,利用關系型數(shù)據(jù)庫的關系性。設計如下四張表格。(在這里我就簡寫了)
第一張表
?123456 id #首先用于關聯(lián),主表需要有個id,這個倒不是什么區(qū)別,因為NoSQL一般也會有個_id的預
設 ? timestamp #所有共同部分就可以存在一張表中。 ? cause ? player_UID ? player_experience ??
player_age ? ?#對于player_inveneory_id 因為這是一個可以任意長度的數(shù)組,又只能保存在另一個表
中了?
第二張表(用于保存creeper死亡方式的死亡事件的)
?123456 id #這是這張表的id以后可以跟別的表格關聯(lián) ? mid #用于關聯(lián)主表 ? enemy_type ??
enemy_power ? enemy_distance ? enemy_age?
第三張表(用于保存lava死亡方式的死亡事件的)
?12345 id #這是這張表的id以后可以跟別的表格關聯(lián) mid #用于關聯(lián)主表 place_x place_y place_z?
第四張表(用于保存player_inveneory)
?123 id #這是這張表的id以后可以跟別的表格關聯(lián) mid #用于關聯(lián)主表 inveneory?
至此關系性數(shù)據(jù)庫就將這種有不同結構的事件存放方式規(guī)定好了,接下來存放如下(我就不畫表格了)
?123456789101112131415161718 1. ? id ?timestamp ? ? ? ? ?cause ? ?player_UID ? ?
player_experience ?player_age ? 1 ? "2013-05-23T1:50:00-0600" ?"creeper" ?"99234890823" ??
8873729 ? ? ? ?228 ? ? ? 2 ? "2013-05-24T23:25:00-0600" ?"lava" ? "99234890823" ? 88737 ? ??
? ? 22 ? 2. ? id ?mid ? enemy_type ?enemy_power ?enemy_distance ?enemy_age ? 1 ? 1 ? ?
"creeper" ? .887 ? ? ?3.34 ? ? ? .6677 ? 3. ? id ?mid ?place_x ?place_y ?place_z ? 1 ? 2 ??
45.366 ? -13.333 ?-39.288 ? 4. ? id ?mid ?inveneory ? 1 ? 1 ? "diamend sword" ? 2 ? 1 ??
"torches" ? 3 ? 2 ? "stone"?
至此,我們就用關系性數(shù)據(jù)庫將這兩個事件數(shù)據(jù)存下了。(好麻煩是吧!)
我們再看NoSQL的儲存方法,因為每條數(shù)據(jù)并不受字段(列名)限制,完全可以直接保存,不用分表。(
比如JSON格式)
?123456789101112131415161718192021222324252627282930313233 #第一條數(shù)據(jù) { ? "timestamp":?
"2013-05-23T1:50:00-0600", ? "cause":"creeper", ? "enemy":{ ? ? "type":"creeper" ? ?
"power": .887 ? ? "distance_from_player":3.34 ? ? "age":.6677 ? }, ? "player": { ? ??
"UID":"99234890823", ? ? "experience": 8873729, ? ? "age": 228, ? ? "inveneory":["diamend?
sword","torches"] ? } } #第二條數(shù)據(jù) { ? "timestamp": "2013-05-24T23:25:00-0600", ??
"cause":"lava", ? "place":{ ? ? x:45.366 ? ? y:-13.333 ? ? z:-39.288 ? } ? "player": { ? ??
"UID":"99234890823", ? ? "experience": 88737, ? ? "age": 22, ? ? "inveneory":["stone"] ? }?
}?
下面我們分析NoSQL對這種數(shù)據(jù)存放方式的好處
1.首先是把分散的表結構整合了,讓應該在一起的數(shù)據(jù)在一起了。
這就像C語言中開多個數(shù)組儲存還是用一個結構體數(shù)組的區(qū)別,將一些有關系的數(shù)據(jù)放在一起是人類一種
自然的想法,當然會讓人更加舒服,而且可以提高關聯(lián)性和升級擴展的簡易程度。
2.存放變得方便
讓我們來考慮有數(shù)據(jù)來了我們怎么儲存。
對于二維表數(shù)據(jù)庫:
? ? 1.分析數(shù)據(jù)是那種類型的
? ? 2.存放主表數(shù)據(jù),并獲得返回id
? ? 3.分支,加上主表id在不同情況下向lava或creeper表中存放數(shù)據(jù)
? ? 4.開循環(huán),向inveneory表中插入多條記錄
? ? 這還只是一個簡述,還要考慮到對多個表格操作時的數(shù)據(jù)回滾問題,實際寫起來30行左右,那么出
錯的可能就大大提高了。
對于NoSQL類型
? ? 一句話:
?insert(data);#偽碼
其實想想便知道,取數(shù)據(jù)時原來的關系性數(shù)據(jù)庫也會同樣麻煩。
3.NoSQL更利于動態(tài)生成存放方式,靈活性高了很多,至少我們可以在存放數(shù)據(jù)的時候再設計數(shù)據(jù)庫了(
雖然可能預先設計會好一些)
當然,如果存儲的不是事件性或者類似此類數(shù)據(jù)那么就另當別論了,二維表還是有很多它本身的優(yōu)勢的
。以上是我的一些個人的分析,當然還有很多普遍認同的觀點,以下是一些普遍認同的關于兩種數(shù)據(jù)庫
模式的優(yōu)缺點分析,我也基本同意。?
關系性優(yōu)勢:
? ? 1.事務處理---保持數(shù)據(jù)的一致性;
? ? 2.由于以標準化為前提,數(shù)據(jù)更新的開銷很小(相同的字段基本上只有一處);
? ? 3.可以進行Join等復雜查詢。
關系型缺點:
? ? 1. 擴展困難:由于存在類似Join這樣多表查詢機制,使得數(shù)據(jù)庫在擴展方面很艱難;?
? ? 2. 讀寫慢:這種情況主要發(fā)生在數(shù)據(jù)量達到一定規(guī)模時由于關系型數(shù)據(jù)庫的系統(tǒng)邏輯非常復雜,使
得其非常容易發(fā)生死鎖等的并發(fā)問題,所以導致其讀寫速度下滑非常嚴重;?
? ? 3. 成本高:企業(yè)級數(shù)據(jù)庫的License價格很驚人,并且隨著系統(tǒng)的規(guī)模,而不斷上升;?
? ? 4. 有限的支撐容量:現(xiàn)有關系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲;?
NoSQL優(yōu)勢,主要體現(xiàn)在下面幾點:?
? ? 1. 簡單的擴展:典型例子是Cassandra,由于其架構是類似于經(jīng)典的P2P,所以能通過輕松地添加新
的節(jié)點來擴展這個集群;?
? ? 2. 快速的讀寫:主要例子有Redis,由于其邏輯簡單,而且純內(nèi)存操作,使得其性能非常出色,單
節(jié)點每秒可以處理超過10萬次讀寫操作;?
? ? 3. 低廉的成本:這是大多數(shù)分布式數(shù)據(jù)庫共有的特點,因為主要都是開源軟件,沒有昂貴的
License成本;?
NoSQL數(shù)據(jù)庫還存在著很多的不足,常見主要有下面這幾個:?
? ? 1. 不提供對SQL的支持:如果不支持SQL這樣的工業(yè)標準,將會對用戶產(chǎn)生一定的學習和應用遷移成
本;?
? ? 2. 支持的特性不夠豐富:現(xiàn)有產(chǎn)品所提供的功能都比較有限,大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務,
也不像MS SQL Server和Oracle那樣能提供各種附加功能,比如BI和報表等;?
? ? 3. 現(xiàn)有產(chǎn)品的不夠成熟:大多數(shù)產(chǎn)品都還處于初創(chuàng)期,和關系型數(shù)據(jù)庫幾十年的完善不可同日而語
;
========
8種主流NoSQL數(shù)據(jù)庫系統(tǒng)特性對比和最佳應用場景
這篇文章主要介紹了8種主流NoSQL數(shù)據(jù)庫系統(tǒng)特性對比和最佳應用場景,對選擇一個NoSQL數(shù)據(jù)庫來說是
一個不錯的參考文章,需要的朋友可以參考下
..曾在多家大公司任職的軟件架構師兼顧問Kristóf Kovács在博客中對主流的NoSQL數(shù)據(jù)庫(Cassandra
、Mongodb、CouchDB、Redis、Riak、Membase、Neo4j以及HBase)進行了全方位的對比。
雖然SQL數(shù)據(jù)庫是非常有用的工具,但經(jīng)歷了15年的一支獨秀之后壟斷即將被打破。這只是時間問題:被
迫使用關系數(shù)據(jù)庫,但最終發(fā)現(xiàn)不能適應需求的情況不勝枚舉。
但是NoSQL數(shù)據(jù)庫之間的不同,遠超過兩SQL數(shù)據(jù)庫之間的差別。這意味著軟件架構師更應該在項目開始
時就選擇好一個適合的NoSQL數(shù)據(jù)庫。針對這種情況,這里對 Cassandra、 Mongodb、CouchDB、Redis、?
Riak、 Membase、Neo4j和HBase進行了比較:
注:NoSQL是一項全新的數(shù)據(jù)庫革命性運動,NoSQL的擁護者們提倡運用非關系型的數(shù)據(jù)存儲。現(xiàn)今的計
算機體系結構在數(shù)據(jù)存儲方面要求具 備龐大的水平擴 展性,而NoSQL致力于改變這一現(xiàn)狀。目前Google
的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數(shù)據(jù)庫。
1. CouchDB
所用語言: Erlang
特點:DB一致性,易于使用
使用許可: Apache
協(xié)議: HTTP/REST
雙向數(shù)據(jù)復制,
持續(xù)進行或臨時處理,
處理時帶沖突檢查,
因此,采用的是master-master復制(見編注2)
MVCC – 寫操作不阻塞讀操作
可保存文件之前的版本
Crash-only(可靠的)設計
需要不時地進行數(shù)據(jù)壓縮
視圖:嵌入式 映射/減少
格式化視圖:列表顯示
支持進行服務器端文檔驗證
支持認證
根據(jù)變化實時更新
支持附件處理
因此, CouchApps(獨立的 js應用程序)
需要 jQuery程序庫
最佳應用場景:適用于數(shù)據(jù)變化較少,執(zhí)行預定義查詢,進行數(shù)據(jù)統(tǒng)計的應用程序。適用于需要提供數(shù)
據(jù)版本支持的應用程序。
例如: CRM、CMS系統(tǒng)。 master-master復制對于多站點部署是非常有用的。
注:master-master復制:是一種數(shù)據(jù)庫同步方法,允許數(shù)據(jù)在一組計算機之間共享數(shù)據(jù),并且可以通過
小組中任意成員在組內(nèi)進行數(shù)據(jù)更新。
2.Redis
所用語言:C/C++
特點:運行異常快
使用許可: BSD
協(xié)議:類 Telnet
有硬盤存儲支持的內(nèi)存數(shù)據(jù)庫,
但自2.0版本以后可以將數(shù)據(jù)交換到硬盤(注意, 2.4以后版本不支持該特性!)
Master-slave復制(見編注3)
雖然采用簡單數(shù)據(jù)或以鍵值索引的哈希表,但也支持復雜操作,例如 ZREVRANGEBYSCORE。
INCR & co (適合計算極限值或統(tǒng)計數(shù)據(jù))
支持 sets(同時也支持 union/diff/inter)
支持列表(同時也支持隊列;阻塞式 pop操作)
支持哈希表(帶有多個域的對象)
支持排序 sets(高得分表,適用于范圍查詢)
Redis支持事務
支持將數(shù)據(jù)設置成過期數(shù)據(jù)(類似快速緩沖區(qū)設計)
Pub/Sub允許用戶實現(xiàn)消息機制
最佳應用場景:適用于數(shù)據(jù)變化快且數(shù)據(jù)庫大小可遇見(適合內(nèi)存容量)的應用程序。
例如:股票價格、數(shù)據(jù)分析、實時數(shù)據(jù)搜集、實時通訊。
注:Master-slave復制:如果同一時刻只有一臺服務器處理所有的復制請求,這被稱為 Master-slave復
制,通常應用在需要提供高可用性的服務器集群。
3. MongoDB
所用語言:C++
特點:保留了SQL一些友好的特性(查詢,索引)。
使用許可: AGPL(發(fā)起者: Apache)
協(xié)議: Custom, binary( BSON)
Master/slave復制(支持自動錯誤恢復,使用 sets 復制)
內(nèi)建分片機制
支持 javascript表達式查詢
可在服務器端執(zhí)行任意的 javascript函數(shù)
update-in-place支持比CouchDB更好
在數(shù)據(jù)存儲時采用內(nèi)存到文件映射
對性能的關注超過對功能的要求
建議最好打開日志功能(參數(shù) –journal)
在32位操作系統(tǒng)上,數(shù)據(jù)庫大小限制在約2.5Gb
空數(shù)據(jù)庫大約占 192Mb
采用 GridFS存儲大數(shù)據(jù)或元數(shù)據(jù)(不是真正的文件系統(tǒng))
最佳應用場景:適用于需要動態(tài)查詢支持;需要使用索引而不是 map/reduce功能;需要對大數(shù)據(jù)庫有性
能要求;需要使用 CouchDB但因為數(shù)據(jù)改變太頻繁而占滿內(nèi)存的應用程序。
例如:你本打算采用 MySQL或 PostgreSQL,但因為它們本身自帶的預定義欄讓你望而卻步。
4. Riak
所用語言:Erlang和C,以及一些Javascript
特點:具備容錯能力
使用許可: Apache
協(xié)議: HTTP/REST或者 custom binary
可調(diào)節(jié)的分發(fā)及復制(N, R, W)
用 JavaScript or Erlang在操作前或操作后進行驗證和安全支持。
使用JavaScript或Erlang進行 Map/reduce
連接及連接遍歷:可作為圖形數(shù)據(jù)庫使用
索引:輸入元數(shù)據(jù)進行搜索(1.0版本即將支持)
大數(shù)據(jù)對象支持( Luwak)
提供“開源”和“企業(yè)”兩個版本
全文本搜索,索引,通過 Riak搜索服務器查詢( beta版)
支持Masterless多站點復制及商業(yè)許可的 SNMP監(jiān)控
最佳應用場景:適用于想使用類似 Cassandra(類似Dynamo)數(shù)據(jù)庫但無法處理 bloat及復雜性的
情況。適用于你打算做多站點復制,但又需要對單個站點的擴展性,可用性及出錯處理有要求的情況。
例如:銷售數(shù)據(jù)搜集,工廠控制系統(tǒng);對宕機時間有嚴格要求;可以作為易于更新的 web服務器使用。
5. Membase
所用語言: Erlang和C
特點:兼容 Memcache,但同時兼具持久化和支持集群
使用許可: Apache 2.0
協(xié)議:分布式緩存及擴展
非常快速(200k+/秒),通過鍵值索引數(shù)據(jù)
可持久化存儲到硬盤
所有節(jié)點都是唯一的( master-master復制)
在內(nèi)存中同樣支持類似分布式緩存的緩存單元
寫數(shù)據(jù)時通過去除重復數(shù)據(jù)來減少 IO
提供非常好的集群管理 web界面
更新軟件時軟無需停止數(shù)據(jù)庫服務
支持連接池和多路復用的連接代理
最佳應用場景:適用于需要低延遲數(shù)據(jù)訪問,高并發(fā)支持以及高可用性的應用程序
例如:低延遲數(shù)據(jù)訪問比如以廣告為目標的應用,高并發(fā)的 web 應用比如網(wǎng)絡游戲(例如 Zynga)
6. Neo4j
所用語言: Java
特點:基于關系的圖形數(shù)據(jù)庫
使用許可: GPL,其中一些特性使用 AGPL/商業(yè)許可
協(xié)議: HTTP/REST(或嵌入在 Java中)
可獨立使用或嵌入到 Java應用程序
圖形的節(jié)點和邊都可以帶有元數(shù)據(jù)
很好的自帶web管理功能
使用多種算法支持路徑搜索
使用鍵值和關系進行索引
為讀操作進行優(yōu)化
支持事務(用 Java api)
使用 Gremlin圖形遍歷語言
支持 Groovy腳本
支持在線備份,高級監(jiān)控及高可靠性支持使用 AGPL/商業(yè)許可
最佳應用場景:適用于圖形一類數(shù)據(jù)。這是 Neo4j與其他nosql數(shù)據(jù)庫的最顯著區(qū)別
例如:社會關系,公共交通網(wǎng)絡,地圖及網(wǎng)絡拓譜
7. Cassandra
所用語言: Java
特點:對大型表格和 Dynamo支持得最好
使用許可: Apache
協(xié)議: Custom, binary (節(jié)約型)
可調(diào)節(jié)的分發(fā)及復制(N, R, W)
支持以某個范圍的鍵值通過列查詢
類似大表格的功能:列,某個特性的列集合
寫操作比讀操作更快
基于 Apache分布式平臺盡可能地 Map/reduce
我承認對 Cassandra有偏見,一部分是因為它本身的臃腫和復雜性,也因為 Java的問題(配置,出現(xiàn)異
常,等等)
最佳應用場景:當使用寫操作多過讀操作(記錄日志)如果每個系統(tǒng)組建都必須用 Java編寫(沒有人因
為選用 Apache的軟件被解雇)
例如:銀行業(yè),金融業(yè)(雖然對于金融交易不是必須的,但這些產(chǎn)業(yè)對數(shù)據(jù)庫的要求會比它們更大)寫
比讀更快,所以一個自然的特性就是實時數(shù)據(jù)分析
8. HBase
(配合 ghshephard使用)
所用語言: Java
特點:支持數(shù)十億行X上百萬列
使用許可: Apache
協(xié)議:HTTP/REST (支持 Thrift,見編注4)
在 BigTable之后建模
采用分布式架構 Map/reduce
對實時查詢進行優(yōu)化
高性能 Thrift網(wǎng)關
通過在server端掃描及過濾實現(xiàn)對查詢操作預判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby( JIRB)的shell
對配置改變和較小的升級都會重新回滾
不會出現(xiàn)單點故障
堪比MySQL的隨機訪問性能
最佳應用場景:適用于偏好BigTable:)并且需要對大數(shù)據(jù)進行隨機、實時訪問的場合。
例如: Facebook消息數(shù)據(jù)庫(更多通用的用例即將出現(xiàn))
注:Thrift 是一種接口定義語言,為多種其他語言提供定義和創(chuàng)建服務,由Facebook開發(fā)并開源。
當然,所有的系統(tǒng)都不只具有上面列出的這些特性。這里我僅僅根據(jù)自己的觀點列出一些我認為的重要
特性。與此同時,技術進步是飛速的,所以上述的內(nèi)容肯定需要不斷更新。我會盡我所能地更新這個列
表。
========
總結
以上是生活随笔為你收集整理的nosql数据库学习总结的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SqlServer性能监控和优化总结
- 下一篇: 图解使用PowerTool对Window