大數據時代的數據庫選擇：SQL還是NoSQL？

執行大數據項目的企業面對的關鍵決策之一是使用哪個數據庫，SQL還是NoSQL?SQL有著驕人的業績，龐


大的安裝基礎;而NoSQL正在獲得可觀的收益，且有很多支持者。我們來看看兩位專家對這個問題的看法
一、專家簡介
VoltDB公司首席技術官Ryan Betts表示，SQL已經贏得了大型企業的廣泛部署，大數據是它可以支持的另


一個領域。
Couchbase公司首席執行官Bob Wiederhold表示，NoSQL是可行的選擇，并且從很多方面來看，它是大數


據的最佳選擇，特別是涉及到可擴展性時。
二、SQL經歷時間的考驗，并仍然在蓬勃發展
結構化查詢語言(SQL)是經過時間考驗的勝利者，它已經主宰了幾十年，目前大數據公司和組織(例如谷


歌、Facebook、Cloudera和Apache)正在積極投資于SQL。
在成為主導技術(例如SQL)后，有時候我們很容易忘記其優越性。SQL的獨特優勢包括：
1. SQL能夠加強與數據的交互，并允許對單個數據庫設計提出問題。這是很關鍵的特征，因為無法交互


的數據基本上是沒用的，并且，增強的交互性能夠帶來新的見解、新的問題和更有意義的未來交互。
2. SQL是標準化的，使用戶能夠跨系統運用他們的知識，并對第三方附件和工具提供支持。
3. SQL能夠擴展，并且是多功能和經過時間驗證的，這能夠解決從快寫為主導的傳輸到掃描密集型深入


分析等問題。
4. SQL對數據呈現和存儲采用正交形式，一些SQL系統支持JSON和其他結構化對象格式，比NoSQL具有更


好的性能和更多功能。
雖然NoSQL的出現帶來了一些影響，但SQL仍然主導著市場，并在大數據領域贏得了很多投資和廣泛部署


。
NoSQL的說法很含糊，對于本次討論，我借用Rick Cattell對NoSQL的定義，即提供簡單操作(例如密鑰/


數值存儲)或簡單記錄和索引，并專注于這些簡單操作的橫向可擴展性的系統。
很顯然，現在很多新的數據庫并不是都一樣，認識每種數據庫背后的原理以及潛在問題是成功的關鍵。


NoSQL的主要特點使其更適合于特定的問題。例如，圖形數據庫更適合于數據通過關系組織的情況，而專


門的文本搜索系統更適合于需要實時搜索的情況。
在這里，讓我們看看SQL系統的主要優勢和差異化功能：
* SQL可實現交互性。 SQL是一種聲明性查詢語言。用戶說出他們想要什么(例如，顯示過去五年三月份


期間頂級客戶的地理位置)，數據庫內部就會構件算法并提取請求的結果。相比之下，NoSQL編程創新


MapReduce是一種程序性查詢技術。在用戶提出請求時，MapReduce要求用戶不僅說出自己想要什么，而


且要求他們陳述如何產生答案。
這聽起來像一個無趣的技術差異，但這很關鍵，原因在于：首先，聲明性SQL查詢更容易通過圖形化工具


以及點擊報告構建器來構建。這讓分析師、操作員、管理者和其他不具備軟件編程能力的員工進行數據


庫查詢;其次，數據庫引擎可以利用內部信息來選擇最有效的算法。改變數據庫的物理布局或數據庫，最


佳算法仍然能夠計算出來。而在程序性系統中，編程人員需要重新訪問和重新編程算法，這是非常昂貴


且容易出錯的過程。
市場理解這個關鍵區別。在2010年，谷歌宣布部署SQL來補充MapReduce，主要受內部用戶需求所驅動。


最近，Facebook發布了Presto(一種SQL部署)來查詢其PB級HDFS集群。根據Facebook表示：“隨著我們的


倉庫增長到PB級，以及我們的需求變化，我們清楚地意識到，我們需要一個提供低延時查詢的互動系統


。”此外，Cloudera也正在構建Impala—另一個基于HDFS的SQL部署。
* SQL是標準化的。 雖然供應商有時候會添加自己的語言到SQL界面，但SQL的核心是標準化的，還有其


他規格(例如ODBC和JDBC)提供廣泛可用的穩定界面到SQL存儲。這帶來了一個管理和操作工具生態系統，


可以在SQL系統之上設計、監控、檢查、探索和構建應用程序。
SQL用戶和程序員可用跨多個后端系統重復使用其API和UI知識，減少了應用程序的開發時間。標準化還


允許聲明性第三方提取、轉換、加載(ETL)工具，使企業可以在數據庫之間以及跨系統傳輸數據。
* SQL可擴展。 認為SQL必須犧牲以獲得可擴展性的看法，完全是錯誤的。如前所述，Facebook創建了一


個SQL界面來查詢PB級數據。SQL能夠非常有效地運行極快的ACID傳輸。SQL對數據存儲和索引提供的抽象


[注]化允許跨各種問題和數據集大小的一致使用，讓SQL可以跨集群復制數據存儲有效地運行。使用SQL


作為界面獨立于構建云、規模或HA系統，SQL中并沒有什么在阻止和限制容錯、高可用性和復制。事實上


，所有現代SQL系統支持云友好型橫向可擴展性、復制和容錯性。
* SQL支持JSON。 幾年前，很多SQL系統增加了XML文檔支持。現在，隨著JSON成為一種流行的數據交換


格式，SQL供應商也紛紛加入了JSON型的支持。基于現在靈活的編程過程和web基礎設施的正常運行時間


要求，我們很需要結構化數據類型的支持。Oracle 12c、PostgreSQL 9.2、VoltDB和其他支持JSON的數


據庫，通常具有優于“原生”JSON的性能。
SQL將繼續贏得市場份額，并會繼續看到新的投資和部署。NoSQL數據庫提供專有查詢語言或簡單的鍵值


語義，而沒有更深層次的技術差異化。現代SQL系統提供可擴展性的同時，還支持更豐富的查詢語義，并


有龐大的用戶安裝基礎，廣泛的生態系統整合和深度企業部署。
三、NoSQL更適合大數據應用程序
NoSQL越來越多地被認為是關系型數據庫的可行替代品，特別是對于大數據應用程序。此外，無模式數據


模型通常更適合于現在捕捉和處理的數據種類和類型。
當我們談論NoSQL領域的大數據時，我們指的是從操作數據庫讀取和寫入。不要將操作數據庫與分析數據


庫混淆，這通常會查看大量數據，并從這些數據獲取可視性。
雖然操作數據庫的大數據看起來不具有可分析性，但操作數據庫通常會存儲超大量用戶的大型數據集，


這些用戶經常需要訪問數據來實時執行交易。這種數據庫的操作規模也解釋了NoSQL的關鍵特性，也就是


為什么NoSQL是大數據應用程序的關鍵的原因。
四、NoSQL是可擴展性的關鍵
每次技術行業經歷硬件發展的根本性轉變時，都會出現一個拐點。在數據庫領域，從縱向擴展到橫向擴


展的轉變推動了NoSQL的發展。關系型數據庫(包括來自甲骨文和IBM的數據庫)是縱向擴展。也就是說，


它們是集中式、共享一切的技術，只能通過增加更多昂貴的硬件來擴展。
而NoSQL數據庫是分布式橫向擴展技術。它們使用了分布式節點集(稱為集群)來提供高度彈性擴展功能，


讓用戶可以添加節點來動態處理負載。
分布式橫向擴展的做法通常要比縱向做法更加便宜。商業關系型數據庫的授權費用也讓人望而卻步，因


為他們的價格是按每臺服務器來計算。另一方面，NoSQL數據庫通常是開源技術，按照運行的服務器集群


收費，而且價格相對便宜。
五、NoSQL是靈活性的關鍵
關系型數據庫和NoSQL數據模型有很大的不同。關系型模式獲取數據，并將數據分配到很多相互關聯的表


中，這些表通過外鍵相互應用。
當用戶需要對數據集運行查詢時，所需信息需要從多個表中收集(通常涉及數百個企業應用程序)，并結


合這些信息，再提供給應用程序。同樣地，當寫入數據時，需要在多個表協調和執行寫入。當數據相對


較少，并且，數據以較慢速度流入數據庫時，關系型數據庫通常能夠捕捉和存儲信息。然而，現在的應


用程序通常需要快速寫入(和讀取)海量數據。
NoSQL數據庫采用非常不同的模式。在其核心，NoSQL數據庫其實是“NoREL”，或者說非關系型，這意味


著它們沒有依賴于表以及表之間的聯系，以存儲和組織信息。例如，以文檔為導向的NoSQL數據庫獲取你


想要存儲的數據，并采用JSON格式整合到文檔中。每個JSON文檔可以被你的應用程序視為一個對象。


JSON文檔可能會提取跨越25個表的數據，將數據集成到一個文檔中。
聚合這些信息可能會導致信息重復，但由于存儲已不再是一個成本問題，數據模型靈活性、發布所產生


文檔的簡便性以及讀取和寫入性能提高，讓這成為不錯的選擇。
六、NoSQL是大數據應用程序的關鍵
通過第三方(包括社交媒體網站)，數據正變得越來越容易捕捉和訪問。這些數據包括：個人用戶信息、


地理位置數據、用戶生產的內容、機器記錄數據和傳感器產生的數據。企業還可以依賴于大數據來推動


其關鍵任務型應用程序。同時，企業正在轉向到NoSQL數據庫，因為這種數據庫非常適合現在新型的數據


類型。
開發人員想要一個靈活的數據庫，可以很容易適應新的數據類型，并且，不會受第三方數據供應商的內


容結構變化的影響。大多數新數據是非結構化和半結構化，因此，開發人員也需要能夠有效存儲這些數


據的數據庫。然而，關系型數據庫采用的嚴格定義的基于模式的做法讓其不可能快速整合新數據類型，


并且很不適合于非結構化和半結構化數據。
總體來說，隨著web和移動應用程序的增加、新的趨勢、網上消費者行為的轉變以及新的數據類型的出現


，行業需要能夠提供可擴展的靈活的數據庫技術來管理和訪問數據。NoSQL技術是有效滿足這些需求的唯


一可行解決方案。
========

初識NoSQL NoSql數據庫入門 NoSql數據庫基礎知識

大家有沒有聽說過“NoSQL”呢？大家可能會誤以為是“No！SQL”的縮寫，但實際上，它是“Not Only?


SQL”的縮寫。它的意義是：適用關系型數據庫的時候就使用關系型數據庫，不適用的時候也沒有必要非


使用關系型數據庫不可，可以考慮使用更加合適的數據存儲。
..做了一年的大一年度項目了，對于關系型數據庫結構還是有些了解了，有的時候還是覺得這種二維表


不是很順手。在看過一篇文章之后，對NoSQL有了初步的了解，


（https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data）。


這篇文章寫的很好，確實寫出來了在實際情況下NoSQL的“用武之地”，而且用了MineCraft作分析，但


是也許不夠全面。比如文章中只是提到了，entity數據用關系型怎么存，event數據用NoSQL怎么存，我


想借我這篇文章，來分析一下event類型的數據原始的關系型數據庫是怎樣存數據的，然后再對這兩種儲


存方式做一種對比，算是對原文都一種補充吧。


對于這種死亡事件，有這樣的兩條數據，一個是關于creeper的爆炸，一種是掉進巖漿。如果必須用關系


型二維表數據庫，我會這樣存儲。（如果您還不知道是什么樣的數據，可以先看之后的NoSQL儲存方法，


那樣看起來更清楚。）


這種情況的數據可以說是數據庫設計中比較復雜的一種情況了，因為它包含兩種情況（當然不止這兩種


情況，那么就會產生更多的結構），不同情況的數據表結構是不同的，這非常麻煩。我們一般的解決方


案是設計四個表格，利用關系型數據庫的關系性。設計如下四張表格。（在這里我就簡寫了）


第一張表


?123456 id #首先用于關聯，主表需要有個id，這個倒不是什么區別，因為NoSQL一般也會有個_id的預


設 ? timestamp #所有共同部分就可以存在一張表中。 ? cause ? player_UID ? player_experience ??


player_age ? ?#對于player_inveneory_id 因為這是一個可以任意長度的數組，又只能保存在另一個表


中了?
第二張表（用于保存creeper死亡方式的死亡事件的）


?123456 id #這是這張表的id以后可以跟別的表格關聯 ? mid #用于關聯主表 ? enemy_type ??


enemy_power ? enemy_distance ? enemy_age?
第三張表（用于保存lava死亡方式的死亡事件的）


?12345 id #這是這張表的id以后可以跟別的表格關聯 mid #用于關聯主表 place_x place_y place_z?
第四張表（用于保存player_inveneory）


?123 id #這是這張表的id以后可以跟別的表格關聯 mid #用于關聯主表 inveneory?
至此關系性數據庫就將這種有不同結構的事件存放方式規定好了，接下來存放如下（我就不畫表格了）


?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"?
至此，我們就用關系性數據庫將這兩個事件數據存下了。（好麻煩是吧！）


我們再看NoSQL的儲存方法，因為每條數據并不受字段（列名）限制，完全可以直接保存，不用分表。（


比如JSON格式）


?123456789101112131415161718192021222324252627282930313233 #第一條數據 { ? "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"] ? } } #第二條數據 { ? "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對這種數據存放方式的好處




1.首先是把分散的表結構整合了，讓應該在一起的數據在一起了。
這就像C語言中開多個數組儲存還是用一個結構體數組的區別，將一些有關系的數據放在一起是人類一種


自然的想法，當然會讓人更加舒服，而且可以提高關聯性和升級擴展的簡易程度。


2.存放變得方便
讓我們來考慮有數據來了我們怎么儲存。
對于二維表數據庫：
? ? 1.分析數據是那種類型的
? ? 2.存放主表數據，并獲得返回id
? ? 3.分支，加上主表id在不同情況下向lava或creeper表中存放數據
? ? 4.開循環，向inveneory表中插入多條記錄
? ? 這還只是一個簡述，還要考慮到對多個表格操作時的數據回滾問題，實際寫起來30行左右，那么出


錯的可能就大大提高了。
對于NoSQL類型
? ? 一句話：


?insert(data);#偽碼


其實想想便知道，取數據時原來的關系性數據庫也會同樣麻煩。


3.NoSQL更利于動態生成存放方式，靈活性高了很多，至少我們可以在存放數據的時候再設計數據庫了（


雖然可能預先設計會好一些）


當然，如果存儲的不是事件性或者類似此類數據那么就另當別論了，二維表還是有很多它本身的優勢的


。以上是我的一些個人的分析，當然還有很多普遍認同的觀點，以下是一些普遍認同的關于兩種數據庫


模式的優缺點分析，我也基本同意。?


關系性優勢：
? ? 1.事務處理---保持數據的一致性；
? ? 2.由于以標準化為前提，數據更新的開銷很小（相同的字段基本上只有一處）；
? ? 3.可以進行Join等復雜查詢。


關系型缺點：
? ? 1. 擴展困難：由于存在類似Join這樣多表查詢機制，使得數據庫在擴展方面很艱難;?
? ? 2. 讀寫慢：這種情況主要發生在數據量達到一定規模時由于關系型數據庫的系統邏輯非常復雜，使


得其非常容易發生死鎖等的并發問題，所以導致其讀寫速度下滑非常嚴重;?
? ? 3. 成本高：企業級數據庫的License價格很驚人，并且隨著系統的規模，而不斷上升;?
? ? 4. 有限的支撐容量：現有關系型解決方案還無法支撐Google這樣海量的數據存儲;?


NoSQL優勢，主要體現在下面幾點：?
? ? 1. 簡單的擴展：典型例子是Cassandra，由于其架構是類似于經典的P2P，所以能通過輕松地添加新


的節點來擴展這個集群;?
? ? 2. 快速的讀寫：主要例子有Redis，由于其邏輯簡單，而且純內存操作，使得其性能非常出色，單


節點每秒可以處理超過10萬次讀寫操作;?
? ? 3. 低廉的成本：這是大多數分布式數據庫共有的特點，因為主要都是開源軟件，沒有昂貴的


License成本;?


NoSQL數據庫還存在著很多的不足，常見主要有下面這幾個：?
? ? 1. 不提供對SQL的支持：如果不支持SQL這樣的工業標準，將會對用戶產生一定的學習和應用遷移成


本;?
? ? 2. 支持的特性不夠豐富：現有產品所提供的功能都比較有限，大多數NoSQL數據庫都不支持事務，


也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等;?
? ? 3. 現有產品的不夠成熟：大多數產品都還處于初創期，和關系型數據庫幾十年的完善不可同日而語


;
========

8種主流NoSQL數據庫系統特性對比和最佳應用場景

這篇文章主要介紹了8種主流NoSQL數據庫系統特性對比和最佳應用場景,對選擇一個NoSQL數據庫來說是


一個不錯的參考文章,需要的朋友可以參考下
..曾在多家大公司任職的軟件架構師兼顧問Kristóf Kovács在博客中對主流的NoSQL數據庫（Cassandra


、Mongodb、CouchDB、Redis、Riak、Membase、Neo4j以及HBase）進行了全方位的對比。


雖然SQL數據庫是非常有用的工具，但經歷了15年的一支獨秀之后壟斷即將被打破。這只是時間問題：被


迫使用關系數據庫，但最終發現不能適應需求的情況不勝枚舉。


但是NoSQL數據庫之間的不同，遠超過兩SQL數據庫之間的差別。這意味著軟件架構師更應該在項目開始


時就選擇好一個適合的NoSQL數據庫。針對這種情況，這里對 Cassandra、 Mongodb、CouchDB、Redis、?


Riak、 Membase、Neo4j和HBase進行了比較：


注：NoSQL是一項全新的數據庫革命性運動，NoSQL的擁護者們提倡運用非關系型的數據存儲。現今的計


算機體系結構在數據存儲方面要求具 備龐大的水平擴 展性，而NoSQL致力于改變這一現狀。目前Google


的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數據庫。


1. CouchDB


所用語言： Erlang
特點：DB一致性，易于使用
使用許可： Apache
協議： HTTP/REST
雙向數據復制，
持續進行或臨時處理，
處理時帶沖突檢查，
因此，采用的是master-master復制（見編注2）
MVCC – 寫操作不阻塞讀操作
可保存文件之前的版本
Crash-only（可靠的）設計
需要不時地進行數據壓縮
視圖：嵌入式 映射/減少
格式化視圖：列表顯示
支持進行服務器端文檔驗證
支持認證
根據變化實時更新
支持附件處理
因此， CouchApps（獨立的 js應用程序）
需要 jQuery程序庫


最佳應用場景：適用于數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用于需要提供數


據版本支持的應用程序。


例如： CRM、CMS系統。 master-master復制對于多站點部署是非常有用的。


注：master-master復制：是一種數據庫同步方法，允許數據在一組計算機之間共享數據，并且可以通過


小組中任意成員在組內進行數據更新。


2.Redis


所用語言：C/C++
特點：運行異常快
使用許可： BSD
協議：類 Telnet
有硬盤存儲支持的內存數據庫，
但自2.0版本以后可以將數據交換到硬盤（注意， 2.4以后版本不支持該特性！）
Master-slave復制（見編注3）
雖然采用簡單數據或以鍵值索引的哈希表，但也支持復雜操作，例如 ZREVRANGEBYSCORE。
INCR & co （適合計算極限值或統計數據）
支持 sets（同時也支持 union/diff/inter）
支持列表（同時也支持隊列；阻塞式 pop操作）
支持哈希表（帶有多個域的對象）
支持排序 sets（高得分表，適用于范圍查詢）
Redis支持事務
支持將數據設置成過期數據（類似快速緩沖區設計）
Pub/Sub允許用戶實現消息機制


最佳應用場景：適用于數據變化快且數據庫大小可遇見（適合內存容量）的應用程序。


例如：股票價格、數據分析、實時數據搜集、實時通訊。


注：Master-slave復制：如果同一時刻只有一臺服務器處理所有的復制請求，這被稱為 Master-slave復


制，通常應用在需要提供高可用性的服務器集群。


3. MongoDB


所用語言：C++
特點：保留了SQL一些友好的特性（查詢，索引）。
使用許可： AGPL（發起者： Apache）
協議： Custom, binary（ BSON）
Master/slave復制（支持自動錯誤恢復，使用 sets 復制）
內建分片機制
支持 javascript表達式查詢
可在服務器端執行任意的 javascript函數
update-in-place支持比CouchDB更好
在數據存儲時采用內存到文件映射
對性能的關注超過對功能的要求
建議最好打開日志功能（參數 –journal）
在32位操作系統上，數據庫大小限制在約2.5Gb
空數據庫大約占 192Mb
采用 GridFS存儲大數據或元數據（不是真正的文件系統）


最佳應用場景：適用于需要動態查詢支持；需要使用索引而不是 map/reduce功能；需要對大數據庫有性


能要求；需要使用 CouchDB但因為數據改變太頻繁而占滿內存的應用程序。


例如：你本打算采用 MySQL或 PostgreSQL，但因為它們本身自帶的預定義欄讓你望而卻步。


4. Riak


所用語言：Erlang和C，以及一些Javascript
特點：具備容錯能力
使用許可： Apache
協議： HTTP/REST或者 custom binary
可調節的分發及復制(N, R, W)
用 JavaScript or Erlang在操作前或操作后進行驗證和安全支持。
使用JavaScript或Erlang進行 Map/reduce
連接及連接遍歷：可作為圖形數據庫使用
索引：輸入元數據進行搜索（1.0版本即將支持）
大數據對象支持（ Luwak）
提供“開源”和“企業”兩個版本
全文本搜索，索引，通過 Riak搜索服務器查詢（ beta版）
支持Masterless多站點復制及商業許可的 SNMP監控
　　最佳應用場景：適用于想使用類似 Cassandra（類似Dynamo）數據庫但無法處理 bloat及復雜性的


情況。適用于你打算做多站點復制，但又需要對單個站點的擴展性，可用性及出錯處理有要求的情況。


例如：銷售數據搜集，工廠控制系統；對宕機時間有嚴格要求；可以作為易于更新的 web服務器使用。


5. Membase


所用語言： Erlang和C
特點：兼容 Memcache，但同時兼具持久化和支持集群
使用許可： Apache 2.0
協議：分布式緩存及擴展
非常快速（200k+/秒），通過鍵值索引數據
可持久化存儲到硬盤
所有節點都是唯一的（ master-master復制）
在內存中同樣支持類似分布式緩存的緩存單元
寫數據時通過去除重復數據來減少 IO
提供非常好的集群管理 web界面
更新軟件時軟無需停止數據庫服務
支持連接池和多路復用的連接代理


最佳應用場景：適用于需要低延遲數據訪問，高并發支持以及高可用性的應用程序


例如：低延遲數據訪問比如以廣告為目標的應用，高并發的 web 應用比如網絡游戲（例如 Zynga）


6. Neo4j


所用語言： Java
特點：基于關系的圖形數據庫
使用許可： GPL，其中一些特性使用 AGPL/商業許可
協議： HTTP/REST（或嵌入在 Java中）
可獨立使用或嵌入到 Java應用程序
圖形的節點和邊都可以帶有元數據
很好的自帶web管理功能
使用多種算法支持路徑搜索
使用鍵值和關系進行索引
為讀操作進行優化
支持事務（用 Java api）
使用 Gremlin圖形遍歷語言
支持 Groovy腳本
支持在線備份，高級監控及高可靠性支持使用 AGPL/商業許可


最佳應用場景：適用于圖形一類數據。這是 Neo4j與其他nosql數據庫的最顯著區別


例如：社會關系，公共交通網絡，地圖及網絡拓譜


7. Cassandra


所用語言： Java
特點：對大型表格和 Dynamo支持得最好
使用許可： Apache
協議： Custom, binary (節約型)
可調節的分發及復制(N, R, W)
支持以某個范圍的鍵值通過列查詢
類似大表格的功能：列，某個特性的列集合
寫操作比讀操作更快
基于 Apache分布式平臺盡可能地 Map/reduce
我承認對 Cassandra有偏見，一部分是因為它本身的臃腫和復雜性，也因為 Java的問題（配置，出現異


常，等等）


最佳應用場景：當使用寫操作多過讀操作（記錄日志）如果每個系統組建都必須用 Java編寫（沒有人因


為選用 Apache的軟件被解雇）


例如：銀行業，金融業（雖然對于金融交易不是必須的，但這些產業對數據庫的要求會比它們更大）寫


比讀更快，所以一個自然的特性就是實時數據分析


8. HBase


（配合 ghshephard使用）


所用語言： Java
特點：支持數十億行X上百萬列
使用許可： Apache
協議：HTTP/REST （支持 Thrift，見編注4）
在 BigTable之后建模
采用分布式架構 Map/reduce
對實時查詢進行優化
高性能 Thrift網關
通過在server端掃描及過濾實現對查詢操作預判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby（ JIRB）的shell
對配置改變和較小的升級都會重新回滾
不會出現單點故障
堪比MySQL的隨機訪問性能


最佳應用場景：適用于偏好BigTable:)并且需要對大數據進行隨機、實時訪問的場合。


例如： Facebook消息數據庫（更多通用的用例即將出現）


注：Thrift 是一種接口定義語言，為多種其他語言提供定義和創建服務，由Facebook開發并開源。




當然，所有的系統都不只具有上面列出的這些特性。這里我僅僅根據自己的觀點列出一些我認為的重要


特性。與此同時，技術進步是飛速的，所以上述的內容肯定需要不斷更新。我會盡我所能地更新這個列


表。
========

總結

以上是生活随笔為你收集整理的nosql数据库学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。