隨著大數(shù)據(jù)時代的到來，越來越多的網(wǎng)站、應(yīng)用系統(tǒng)需要支撐海量數(shù)據(jù)存儲，高并發(fā)請求、高可用、高可擴(kuò)展性等特性要求，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在應(yīng)付這些調(diào)整已經(jīng)顯得力不從心，暴露了許多能以克服的問題。由此，各種各樣的NoSQL（Not Only SQL）數(shù)據(jù)庫作為傳統(tǒng)關(guān)系型數(shù)據(jù)的一個有力補(bǔ)充得到迅猛發(fā)展。

本文將分析傳統(tǒng)數(shù)據(jù)庫的存在的相關(guān)問題，以及幾大類NoSQL如何解決這些問題，希望給大家提供在不同業(yè)務(wù)場景下，關(guān)于存儲方面技術(shù)選型提供參考。

1 傳統(tǒng)數(shù)據(jù)庫缺點

• 大數(shù)據(jù)場景下I/O較高 因為數(shù)據(jù)是按行存儲，即使只針對其中某一列進(jìn)行運算，關(guān)系型數(shù)據(jù)庫也會將整行數(shù)據(jù)從存儲設(shè)備中讀入內(nèi)存，導(dǎo)致I/O較高
• 存儲的是行記錄，無法存儲數(shù)據(jù)結(jié)構(gòu)
• 表結(jié)構(gòu)schema擴(kuò)展不方便 如要需要修改表結(jié)構(gòu)，需要執(zhí)行執(zhí)行DDL(data definition language)，語句修改，修改期間會導(dǎo)致鎖表，部分服務(wù)不可用
• 全文搜索功能較弱 關(guān)系型數(shù)據(jù)庫下只能夠進(jìn)行子字符串的匹配查詢，當(dāng)表的數(shù)據(jù)逐漸變大的時候，like查詢的匹配會非常慢，即使在有索引的情況下。況且關(guān)系型數(shù)據(jù)庫也不應(yīng)該對文本字段進(jìn)行索引
• 存儲和處理復(fù)雜關(guān)系型數(shù)據(jù)功能較弱 許多應(yīng)用程序需要了解和導(dǎo)航高度連接數(shù)據(jù)之間的關(guān)系，才能啟用社交應(yīng)用程序、推薦引擎、欺詐檢測、知識圖譜、生命科學(xué)和 IT/網(wǎng)絡(luò)等用例。然而傳統(tǒng)的關(guān)系數(shù)據(jù)庫并不善于處理數(shù)據(jù)點之間的關(guān)系。它們的表格數(shù)據(jù)模型和嚴(yán)格的模式使它們很難添加新的或不同種類的關(guān)聯(lián)信息。

2 NoSQL解決方案

NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫，可以理解為SQL的一個有力補(bǔ)充。

在NoSQL許多方面性能大大優(yōu)于非關(guān)系型數(shù)據(jù)庫的同時，往往也伴隨一些特性的缺失，比較常見的，是事務(wù)庫事務(wù)功能的缺失。 數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個基本要素：ACID如下：

名稱 描述 A Atomicity

(原子性) 一個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會在中間某個環(huán)節(jié)結(jié)束。

事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。 C Consistency

一致性 在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。 I Isolation

隔離性 數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對數(shù)據(jù)進(jìn)行讀寫和修改的能力。隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。 D Durability

持久性 事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。 下面介紹5大類NoSQL數(shù)據(jù)針對傳統(tǒng)關(guān)系型數(shù)據(jù)庫的缺點提供的解決方案：

2.1 列式數(shù)據(jù)庫

列式數(shù)據(jù)庫是以列相關(guān)存儲架構(gòu)進(jìn)行數(shù)據(jù)存儲的數(shù)據(jù)庫，主要適合于批量數(shù)據(jù)處理和即時查詢。相對應(yīng)的是行式數(shù)據(jù)庫，數(shù)據(jù)以行相關(guān)的存儲體系架構(gòu)進(jìn)行空間分配，主要適合于小批量的數(shù)據(jù)處理，常用于聯(lián)機(jī)事務(wù)型數(shù)據(jù)處理。

基于列式數(shù)據(jù)庫的列列存儲特性，可以解決某些特定場景下關(guān)系型數(shù)據(jù)庫I/O較高的問題

2.1.1 基本原理

傳統(tǒng)關(guān)系型數(shù)據(jù)庫是按照行來存儲數(shù)據(jù)庫，稱為“行式數(shù)據(jù)庫”，而列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。

將表放入存儲系統(tǒng)中有兩種方法，而我們絕大部分是采用行存儲的。 行存儲法是將各行放入連續(xù)的物理位置，這很像傳統(tǒng)的記錄和文件系統(tǒng)。 列存儲法是將數(shù)據(jù)按照列存儲到數(shù)據(jù)庫中，與行存儲類似，下圖是兩種存儲方法的圖形化解釋：

2.1.2 常見列式數(shù)據(jù)庫

• HBase

HBase是一個開源的非關(guān)系型分布式數(shù)據(jù)庫（NoSQL），它參考了谷歌的BigTable建模，實現(xiàn)的編程語言為 Java。它是Apache軟件基金會的Hadoop項目的一部分，運行于HDFS文件系統(tǒng)之上，為 Hadoop 提供類似于BigTable 規(guī)模的服務(wù)。因此，它可以容錯地存儲海量稀疏的數(shù)據(jù)。

• BigTable

BigTable是一種壓縮的、高性能的、高可擴(kuò)展性的，基于Google文件系統(tǒng)（Google File System，GFS）的數(shù)據(jù)存儲系統(tǒng)，用于存儲大規(guī)模結(jié)構(gòu)化數(shù)據(jù)，適用于云端計算。

2.1.3 相關(guān)特性

優(yōu)點如下：

• 高效的儲存空間利用率**

列式數(shù)據(jù)庫由于其針對不同列的數(shù)據(jù)特征而發(fā)明的不同算法使其往往有比行式數(shù)據(jù)庫高的多的壓縮率，普通的行式數(shù)據(jù)庫一般壓縮率在3：1 到5：1 左右，而列式數(shù)據(jù)庫的壓縮率一般在8：1到30：1 左右。 比較常見的，通過字典表壓縮數(shù)據(jù)： 下面中才是那張表本來的樣子。經(jīng)過字典表進(jìn)行數(shù)據(jù)壓縮后，表中的字符串才都變成數(shù)字了。正因為每個字符串在字典表里只出現(xiàn)一次了，所以達(dá)到了壓縮的目的(有點像規(guī)范化和非規(guī)范化Normalize和Denomalize)

• 查詢效率高

讀取多條數(shù)據(jù)的同一列效率高，因為這些列都是存儲在一起的，一次磁盤操作可以數(shù)據(jù)的指定列全部讀取到內(nèi)存中。 下圖通過一條查詢的執(zhí)行過程說明列式存儲(以及數(shù)據(jù)壓縮)的優(yōu)點

執(zhí)行步驟如下：

i. 去字典表里找到字符串對應(yīng)數(shù)字(只進(jìn)行一次字符串比較)。

ii. 用數(shù)字去列表里匹配，匹配上的位置設(shè)為1。

iii. 把不同列的匹配結(jié)果進(jìn)行位運算得到符合所有條件的記錄下標(biāo)。

iv. 使用這個下標(biāo)組裝出最終的結(jié)果集。

復(fù)制代碼

• 適合做聚合操作

• 適合大量的數(shù)據(jù)而不是小數(shù)據(jù)

缺點如下：

• 不適合掃描小量數(shù)據(jù)
• 不適合隨機(jī)的更新
• 不適合做含有刪除和更新的實時操作
• 單行的數(shù)據(jù)是ACID的，多行的事務(wù)時，不支持事務(wù)的正?；貪L，支持 I(Isolation)隔離性(事務(wù)串行提交)，D(Durability)持久性，不能保證 A(Atomicity)原子性， C(Consistency)一致性

2.1.4 使用場景

以HBase為例說明：

• 大數(shù)據(jù)量 （100s TB級數(shù)據(jù)） 且有快速隨機(jī)訪問的需求
• 寫密集型應(yīng)用，每天寫入量巨大，而相對讀數(shù)量較小的應(yīng)用 比如IM的歷史消息，游戲的日志等等
• 不需要復(fù)雜查詢條件來查詢數(shù)據(jù)的應(yīng)用 HBase只支持基于rowkey的查詢，對于HBase來說，單條記錄或者小范圍的查詢是可以接受的，大范圍的查詢由于分布式的原因，可能在性能上有點影響，HBase不適用與有join，多級索引，表關(guān)系復(fù)雜的數(shù)據(jù)模型
• 對性能和可靠性要求非常高的應(yīng)用 由于HBase本身沒有單點故障，可用性非常高。
• 數(shù)據(jù)量較大，而且增長量無法預(yù)估的應(yīng)用，需要進(jìn)行優(yōu)雅的數(shù)據(jù)擴(kuò)展的 HBase支持在線擴(kuò)展，即使在一段時間內(nèi)數(shù)據(jù)量呈井噴式增長，也可以通過HBase橫向擴(kuò)展來滿足功能。
• 存儲結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)

2.2 K-V數(shù)據(jù)庫

指的是使用鍵值(key-value)存儲的數(shù)據(jù)庫，其數(shù)據(jù)按照鍵值對的形式進(jìn)行組織、索引和存儲。

KV 存儲非常適合不涉及過多數(shù)據(jù)關(guān)系業(yè)務(wù)關(guān)系的數(shù)據(jù)，同時能有效減少讀寫磁盤的次數(shù)，比 SQL 數(shù)據(jù)庫存儲擁有更好的讀寫性能，能夠解決關(guān)系型數(shù)據(jù)庫無法存儲數(shù)據(jù)結(jié)構(gòu)的問題。

2.2.1 常見 K-V數(shù)據(jù)庫

• Redis

Redis是一個使用ANSI C編寫的開源、支持網(wǎng)絡(luò)、基于內(nèi)存、可選持久性的鍵值對存儲數(shù)據(jù)庫。從2015年6月開始，Redis的開發(fā)由Redis Labs贊助，而2013年5月至2015年6月期間，其開發(fā)由Pivotal贊助。在2013年5月之前，其開發(fā)由VMware贊助。根據(jù)月度排行網(wǎng)站DB-Engines.com的數(shù)據(jù)顯示，Redis是最流行的鍵值對存儲數(shù)據(jù)庫。

• Cassandra

Apache Cassandra（社區(qū)內(nèi)一般簡稱為C*）是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)。它最初由Facebook開發(fā)，用于儲存收件箱等簡單格式數(shù)據(jù)，集Google BigTable的數(shù)據(jù)模型與Amazon Dynamo的完全分布式架構(gòu)于一身。Facebook于2008將 Cassandra 開源，此后，由于Cassandra良好的可擴(kuò)展性和性能，被 Apple, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix等知名網(wǎng)站所采用，成為了一種流行的分布式結(jié)構(gòu)化數(shù)據(jù)存儲方案。

• LevelDB

• 
  
• LevelDB是一個由Google公司所研發(fā)的鍵／值對（Key/Value Pair）嵌入式數(shù)據(jù)庫管理系統(tǒng)編程庫， 以開源的BSD許可證發(fā)布。

2.2.2 相關(guān)特性

以Redis為例： 優(yōu)點如下：

• 性能極高：Redis能支持超過10W的TPS
• 豐富的數(shù)據(jù)類型： Redis支持包括String，Hash，List，Set，Sorted Set，Bitmap和hyperloglog
• 豐富的特性：Redis還支持 publish/subscribe, 通知, key 過期等等特性

缺點如下： 針對ACID，Redis事務(wù)不能支持原子性和持久性(A和D)，只支持隔離性和一致性(I和C) 特別說明一下，這里所說的無法保證原子性，是針對Redis的事務(wù)操作，因為事務(wù)是不支持回滾（roll back），而因為Redis的單線程模型，Redis的普通操作是原子性的

大部分業(yè)務(wù)不需要嚴(yán)格遵循ACID原則，例如游戲?qū)崟r排行榜，粉絲關(guān)注等場景，即使部分?jǐn)?shù)據(jù)持久化失敗，其實業(yè)務(wù)影響也非常小。因此在設(shè)計方案時，需要根據(jù)業(yè)務(wù)特征和要求來做選擇

2.2.3 使用場景

• 適用場景 儲存用戶信息(比如會話)、配置文件、參數(shù)、購物車等等。這些信息一般都和ID（鍵）掛鉤
• 不適用場景
• 需要通過值來查詢，而不是鍵來查詢。Key-Value數(shù)據(jù)庫中根本沒有通過值查詢的途徑。
• 需要儲存數(shù)據(jù)之間的關(guān)系。在Key-Value數(shù)據(jù)庫中不能通過兩個或以上的鍵來關(guān)聯(lián)數(shù)據(jù)
• 需要事務(wù)的支持。在Key-Value數(shù)據(jù)庫中故障產(chǎn)生時不可以進(jìn)行回滾。

2.3 文檔數(shù)據(jù)庫

文檔數(shù)據(jù)庫（也稱為文檔型數(shù)據(jù)庫）是旨在將半結(jié)構(gòu)化數(shù)據(jù)存儲為文檔的一種數(shù)據(jù)庫。文檔數(shù)據(jù)庫通常以 JSON 或 XML 格式存儲數(shù)據(jù)。

由于文檔數(shù)據(jù)庫的no-schema特性，可以存儲和讀取任意數(shù)據(jù)。

由于使用的數(shù)據(jù)格式是JSON或者BSON，因為JSON數(shù)據(jù)是自描述的，無需在使用前定義字段，讀取一個JSON中不存在的字段也不會導(dǎo)致SQL那樣的語法錯誤，可以解決關(guān)系型數(shù)據(jù)庫表結(jié)構(gòu)schema擴(kuò)展不方便的問題

2.3.1 常見文檔數(shù)據(jù)庫

• MongoDB

MongoDB是一種面向文檔的數(shù)據(jù)庫管理系統(tǒng)，由C++撰寫而成，以此來解決應(yīng)用程序開發(fā)社區(qū)中的大量現(xiàn)實問題。2007年10月，MongoDB由10gen團(tuán)隊所發(fā)展。2009年2月首度推出。

• CouchDB

Apache CouchDB是一個開源數(shù)據(jù)庫，專注于易用性和成為'完全擁抱web的數(shù)據(jù)庫'。它是一個使用JSON作為存儲格式，JavaScript作為查詢語言，MapReduce和HTTP作為API的NoSQL數(shù)據(jù)庫。其中一個顯著的功能就是多主復(fù)制。CouchDB的第一個版本發(fā)布在2005年，在2008年成為了Apache的項目。

2.3.2 相關(guān)特性

以MongoDB為例進(jìn)行說明

優(yōu)點如下：

• 新增字段簡單 無需像關(guān)系型數(shù)據(jù)庫一樣先執(zhí)行DDL語句修改表結(jié)構(gòu)，程序代碼直接讀寫即可
• 容易兼容歷史數(shù)據(jù) 對于歷史數(shù)據(jù)，即使沒有新增的字段，也不會導(dǎo)致錯誤，只會返回空值，此時代碼兼容處理即可
• 容易存儲復(fù)雜數(shù)據(jù) JSON是一種強(qiáng)大的描述語言，能夠描述復(fù)雜的數(shù)據(jù)結(jié)構(gòu)

相比傳統(tǒng)關(guān)系型數(shù)據(jù)庫，文檔數(shù)據(jù)庫的缺點主要是對多條數(shù)據(jù)記錄的事務(wù)支持較弱，具體體現(xiàn)如下：

• Atomicity(原子性) 僅支持單行/文檔級原子性，不支持多行、多文檔、多語句原子性
• Isolation(隔離性) 隔離級別僅支持已提交讀（Read committed）級別，可能導(dǎo)致不可重復(fù)讀，幻讀的問題
• 不支持復(fù)雜查詢 例如join查詢，如果需要join查詢，需要多次操作數(shù)據(jù)庫

MongonDB還是支持多文檔事務(wù)的Consistency(一致性)和Durability(持久性)

雖然官方宣布MongoDB將在4.0版本中正式推出多文檔ACID事務(wù)支持，最后落地情況還有待見證。

2.3.3 使用場景

適用場景：

• 數(shù)據(jù)量很大或者未來會變得很大
• 表結(jié)構(gòu)不明確，且字段在不斷增加，例如內(nèi)容管理系統(tǒng)，信息管理系統(tǒng)

不適用場景：

• 在不同的文檔上需要添加事務(wù)。Document-Oriented數(shù)據(jù)庫并不支持文檔間的事務(wù)
• 多個文檔直接需要復(fù)雜查詢，例如join

2.4 全文搜索引擎

傳統(tǒng)關(guān)系型數(shù)據(jù)庫主要通過索引來達(dá)到快速查詢的目的，在全文搜索的業(yè)務(wù)下，索引也無能為力，主要體現(xiàn)在：

• 全文搜索的條件可以隨意排列組合，如果通過索引來滿足，則索引的數(shù)量非常多
• 全文搜索的模糊匹配方式，索引無法滿足，只能用like查詢，而like查詢是整表掃描，效率非常低

而全文搜索引擎的出現(xiàn)，正是解決關(guān)系型數(shù)據(jù)庫全文搜索功能較弱的問題

2.4.1 基本原理

全文搜索引擎的技術(shù)原理稱為“倒排索引”（inverted index），是一種索引方法，其基本原理是建立單詞到文檔的索引。與之相對是，是“正排索引”，其基本原理是建立文檔到單詞的索引。

現(xiàn)在有如下文檔集合：

正排索引得到索引如下：

可見，正排索引適用于根據(jù)文檔名稱查詢文檔內(nèi)容

簡單的倒排索引如下：

帶有單詞頻率信息的倒排索引如下：

可見，倒排索引適用于根據(jù)關(guān)鍵詞來查詢文檔內(nèi)容

2.4.2 常見全文搜索引擎

• Elasticsearch

• 
  
• Elasticsearch是一個基于Lucene的搜索引擎。它提供了一個分布式，多租戶 -能夠全文搜索與發(fā)動機(jī)HTTP Web界面和無架構(gòu)JSON文件。Elasticsearch是用Java開發(fā)的，并根據(jù)Apache License的條款作為開源發(fā)布。根據(jù)DB-Engines排名，Elasticsearch是最受歡迎的企業(yè)搜索引擎，后面是基于Lucene的Apache Solr。
• Solr

• 
  
• Solr是Apache Lucene項目的開源企業(yè)搜索平臺。其主要功能包括全文檢索、命中標(biāo)示、分面搜索、動態(tài)聚類、數(shù)據(jù)庫集成，以及富文本（如Word、PDF）的處理。Solr是高度可擴(kuò)展的，并提供了分布式搜索和索引復(fù)制

2.4.3 相關(guān)特性

以Elasticsearch為例： 優(yōu)點如下：

• 查詢效率高 對海量數(shù)據(jù)進(jìn)行近實時的處理
• 可擴(kuò)展性 基于集群環(huán)境可以方便橫向擴(kuò)展，可以承載PB級數(shù)據(jù)
• 高可用 Elasticsearch集群彈性-他們將發(fā)現(xiàn)新的或失敗的節(jié)點，重組和重新平衡數(shù)據(jù)，確保數(shù)據(jù)是安全的和可訪問的

缺點如下：

• ACID支持不足 單一文檔的數(shù)據(jù)是ACID的，包含多個文檔的事務(wù)時不支持事務(wù)的正常回滾，支持 I(Isolation)隔離性（基于樂觀鎖機(jī)制的），D(Durability)持久性，

  不支持 A(Atomicity)原子性，C(Consistency)一致性

• 對類似數(shù)據(jù)庫中通過外鍵的復(fù)雜的多表關(guān)聯(lián)操作支持較弱
• 讀寫有一定延時，寫入的數(shù)據(jù)，最快1s中能被檢索到
• 更新性能較低，底層實現(xiàn)是先刪數(shù)據(jù)，再插入新數(shù)據(jù)
• 內(nèi)存占用大，因為Lucene 將索引部分加載到內(nèi)存中

2.4.4 使用場景

適用場景如下：

• 分布式的搜索引擎和數(shù)據(jù)分析引擎
• 全文檢索，結(jié)構(gòu)化檢索，數(shù)據(jù)分析
• 對海量數(shù)據(jù)進(jìn)行近實時的處理 可以將海量數(shù)據(jù)分散到多臺服務(wù)器上去存儲和檢索

不適用場景如下：

• 數(shù)據(jù)需要頻繁更新
• 需要復(fù)雜關(guān)聯(lián)查詢

2.5 圖形數(shù)據(jù)庫

圖形數(shù)據(jù)庫應(yīng)用圖形理論存儲實體之間的關(guān)系信息。最常見例子就是社會網(wǎng)絡(luò)中人與人之間的關(guān)系。關(guān)系型數(shù)據(jù)庫用于存儲“關(guān)系型”數(shù)據(jù)的效果并不好，其查詢復(fù)雜、緩慢、超出預(yù)期，而圖形數(shù)據(jù)庫的獨特設(shè)計恰恰彌補(bǔ)了這個缺陷，解決關(guān)系型數(shù)據(jù)庫存儲和處理復(fù)雜關(guān)系型數(shù)據(jù)功能較弱的問題。

2.5.1 常見圖形數(shù)據(jù)庫

• Neo4j

Neo4j是由Neo4j，Inc。開發(fā)的圖形數(shù)據(jù)庫管理系統(tǒng)。由其開發(fā)人員描述為具有原生圖存儲和處理的符合ACID的事務(wù)數(shù)據(jù)庫，根據(jù)DB-Engines排名， Neo4j是最流行的圖形數(shù)據(jù)庫。

• ArangoDB

ArangoDB是由triAGENS GmbH開發(fā)的原生多模型數(shù)據(jù)庫系統(tǒng)。數(shù)據(jù)庫系統(tǒng)支持三個重要的數(shù)據(jù)模型（鍵/值，文檔，圖形），其中包含一個數(shù)據(jù)庫核心和統(tǒng)一查詢語言AQL（ArangoDB查詢語言）。查詢語言是聲明性的，允許在單個查詢中組合不同的數(shù)據(jù)訪問模式。ArangoDB是一個NoSQL數(shù)據(jù)庫系統(tǒng)，但AQL在很多方面與SQL類似。

• Titan

Titan是一個可擴(kuò)展的圖形數(shù)據(jù)庫，針對存儲和查詢包含分布在多機(jī)群集中的數(shù)百億個頂點和邊緣的圖形進(jìn)行了優(yōu)化。Titan是一個事務(wù)性數(shù)據(jù)庫，可以支持?jǐn)?shù)千個并發(fā)用戶實時執(zhí)行復(fù)雜的圖形遍歷。

2.5.2 相關(guān)特性

以Neo4j為例：

Neo4j 使用數(shù)據(jù)結(jié)構(gòu)中圖（graph）的概念來進(jìn)行建模。 Neo4j 中兩個最基本的概念是節(jié)點和邊。節(jié)點表示實體，邊則表示實體之間的關(guān)系。節(jié)點和邊都可以有自己的屬性。不同實體通過各種不同的關(guān)系關(guān)聯(lián)起來，形成復(fù)雜的對象圖。

針對關(guān)系數(shù)據(jù)，2種2數(shù)據(jù)庫的存儲結(jié)構(gòu)不同：

Neo4j中，存儲節(jié)點時使用了”index-free adjacency”，即每個節(jié)點都有指向其鄰居節(jié)點的指針，可以讓我們在O(1)的時間內(nèi)找到鄰居節(jié)點。另外，按照官方的說法，在Neo4j中邊是最重要的,是”first-class entities”，所以單獨存儲，這有利于在圖遍歷的時候提高速度，也可以很方便地以任何方向進(jìn)行遍歷

如下優(yōu)點：

• 高性能表現(xiàn) 圖的遍歷是圖數(shù)據(jù)結(jié)構(gòu)所具有的獨特算法，即從一個節(jié)點開始，根據(jù)其連接的關(guān)系，可以快速和方便地找出它的鄰近節(jié)點。這種查找數(shù)據(jù)的方法并不受數(shù)據(jù)量的大小所影響，因為鄰近查詢始終查找的是有限的局部數(shù)據(jù)，不會對整個數(shù)據(jù)庫進(jìn)行搜索
• 設(shè)計的靈活性 數(shù)據(jù)結(jié)構(gòu)的自然伸展特性及其非結(jié)構(gòu)化的數(shù)據(jù)格式，讓圖數(shù)據(jù)庫設(shè)計可以具有很大的伸縮性和靈活性。因為隨著需求的變化而增加的節(jié)點、關(guān)系及其屬性并不會影響到原來數(shù)據(jù)的正常使用
• 開發(fā)的敏捷性 直觀明了的數(shù)據(jù)模型，從需求的討論開始，到程序開發(fā)和實現(xiàn)，以及最終保存在數(shù)據(jù)庫中的樣子，它的模樣似乎沒有什么變化，甚至可以說本來就是一模一樣的
• 完全支持ACID 不像別的NoSQL數(shù)據(jù)庫Neo4j還具有完全事務(wù)管理特性，完全支持ACID事務(wù)管理

缺點如下：

• 具有支持節(jié)點，關(guān)系和屬性的數(shù)量的限制
• 不支持拆分

2.5.3 使用場景

適用場景如下：

• 在一些關(guān)系性強(qiáng)的數(shù)據(jù)中，例如社交網(wǎng)絡(luò)
• 推薦引擎。如果我們將數(shù)據(jù)以圖的形式表現(xiàn)，那么將會非常有益于推薦的制定

不適用場景如下：

• 記錄大量基于事件的數(shù)據(jù)（例如日志條目或傳感器數(shù)據(jù)）
• 對大規(guī)模分布式數(shù)據(jù)進(jìn)行處理，類似于Hadoop
• 適合于保存在關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)
• 二進(jìn)制數(shù)據(jù)存儲

3 總結(jié)

關(guān)系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫的選型，往往需要考慮幾個指標(biāo)：

• 數(shù)據(jù)量
• 并發(fā)量
• 實時性
• 一致性要求
• 讀寫分布和類型
• 安全性
• 運維成本

常見軟件系統(tǒng)數(shù)據(jù)庫選型參考如下：

• 內(nèi)部使用的管理型系統(tǒng) 如運營系統(tǒng)，數(shù)據(jù)量少，并發(fā)量小，首選考慮關(guān)系型
• 大流量系統(tǒng) 如電商單品頁，后臺考慮選關(guān)系型，前臺考慮選內(nèi)存型
• 日志型系統(tǒng) 原始數(shù)據(jù)考慮選列式，日志搜索考慮選倒排索引
• 搜索型系統(tǒng) 例如站內(nèi)搜索，非通用搜索，如商品搜索，后臺考慮選關(guān)系型，前臺考慮選倒排索引
• 事務(wù)型系統(tǒng) 如庫存，交易，記賬，考慮選關(guān)系型型+緩存+一致性型協(xié)議
• 離線計算 如大量數(shù)據(jù)分析，考慮選列式或者關(guān)系型也可以
• 實時計算 如實時監(jiān)控，可以考慮選內(nèi)存型或者列式數(shù)據(jù)庫

設(shè)計實踐中，要基于需求、業(yè)務(wù)驅(qū)動架構(gòu)，無論選用RDB/NoSQL/DRDB,一定是以需求為導(dǎo)向，最終數(shù)據(jù)存儲方案必然是各種權(quán)衡的綜合性設(shè)計