大數(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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。