大資料時代的資料庫選擇：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開發並開源。




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


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


表。
========