原文來源：51CTO技術棧公眾號，本文原題：NoSQL還是SQL？這一篇講清楚，收錄時有修訂和改動。
1、引言
隨著互聯(lián)網(wǎng)大數(shù)據(jù)時代的到來，越來越多的網(wǎng)站、應用系統(tǒng)都需要支撐大量甚至海量數(shù)據(jù)存儲，同時還伴有高并發(fā)、高可用、高可擴展等特性要求。
很多時候，傳統(tǒng)的關系型數(shù)據(jù)庫在應付這些已經(jīng)顯得力不從心，并暴露了許多難以克服的問題。
由此，各種各樣的 NoSQL（Not Only SQL）數(shù)據(jù)庫作為傳統(tǒng)關系型數(shù)據(jù)的一個有力補充得到迅猛發(fā)展。
本文將分析傳統(tǒng)數(shù)據(jù)庫（即SQL數(shù)據(jù)庫）存在的一些問題，以及盤點目前市面上幾大類 NoSQL 特性、優(yōu)缺點等，希望給大家提供一些在不同業(yè)務場景下存儲技術選型方面的參考。
點評：作為專業(yè)分享即時通訊開發(fā)知識的社區(qū)來說，很多IM開發(fā)者在進行架構(gòu)設計和選型的第一時間想到的，就是該如何選擇數(shù)據(jù)庫，MySQL？Oracle？SQL Server？或者NoSQL？這顯然沒有標準答案，因為每個產(chǎn)品、每套系統(tǒng)、每個架構(gòu)都有自身的用戶規(guī)模、適應場景、成本因素等等考量。本文可能無法給予同為即時通訊開發(fā)者的你一個確切答案，但當你在讀完本文，對市面上主要數(shù)據(jù)庫（包括NoSQL數(shù)據(jù)庫）的技術特性、適用場景、優(yōu)缺點都有了解之后，相信你完全能夠根據(jù)自已產(chǎn)品或系統(tǒng)的特點，找到適合你的數(shù)據(jù)庫方案，這也正是本文的意義所在。
學習交流：
- 即時通訊/推送技術開發(fā)交流5群：215477170 [推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-2759-1-1.html）
2、關于作者
陳彩華（caison）：主要從事服務端開發(fā)、需求分析、系統(tǒng)設計、優(yōu)化重構(gòu)工作，主要開發(fā)語言是 Java，現(xiàn)任廣州貝聊服務端研發(fā)工程師。
陳彩華還分享過另幾篇技術文章，如有興趣可一并閱讀：
3、系列文章
▼ IM開發(fā)干貨系列文章（本文是其第18篇）：
如果您是IM開發(fā)初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發(fā)移動端IM》。4、傳統(tǒng)SQL數(shù)據(jù)庫的缺點
傳統(tǒng)的關系數(shù)據(jù)庫有如下幾個缺點。
1）大數(shù)據(jù)場景下 I/O 較高：因為數(shù)據(jù)是按行存儲，即使只針對其中某一列進行運算，關系型數(shù)據(jù)庫也會將整行數(shù)據(jù)從存儲設備中讀入內(nèi)存，導致 I/O 較高。
2）存儲的是行記錄：無法存儲數(shù)據(jù)結(jié)構(gòu)。
3）表結(jié)構(gòu) Schema 擴展不方便：如要修改表結(jié)構(gòu)，需要執(zhí)行 DDL(data definition language)，語句修改，修改期間會導致鎖表，部分服務不可用。
4）全文搜索功能較弱：關系型數(shù)據(jù)庫下只能夠進行子字符串的匹配查詢，當表的數(shù)據(jù)逐漸變大的時候，like 查詢的匹配會非常慢，即使在有索引的情況下。況且關系型數(shù)據(jù)庫也不應該對文本字段進行索引。
5）存儲和處理復雜關系型數(shù)據(jù)功能較弱：許多應用程序需要了解和導航高度連接數(shù)據(jù)之間的關系，才能啟用社交應用程序、推薦引擎、欺詐檢測、知識圖譜、生命科學和 IT/網(wǎng)絡等用例。然而傳統(tǒng)的關系數(shù)據(jù)庫并不善于處理數(shù)據(jù)點之間的關系。它們的表格數(shù)據(jù)模型和嚴格的模式使它們很難添加新的或不同種類的關聯(lián)信息。
5、NoSQL 解決方案
NoSQL（Not Only SQL），泛指非關系型的數(shù)據(jù)庫，可以理解為 SQL 的一個有力補充。
在 NoSQL 許多方面性能大大優(yōu)于非關系型數(shù)據(jù)庫的同時，往往也伴隨一些特性的缺失，比較常見的是事務庫事務功能的缺失。
數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素 ACID 如下：
下面將分別介紹 5 大類 NoSQL 數(shù)據(jù)庫的技術特性，以及針對傳統(tǒng)關系型數(shù)據(jù)庫的缺點。
6、列式數(shù)據(jù)庫
列式數(shù)據(jù)庫是以列相關存儲架構(gòu)進行數(shù)據(jù)存儲的數(shù)據(jù)庫，主要適合于批量數(shù)據(jù)處理和即時查詢。
相對應的是行式數(shù)據(jù)庫，數(shù)據(jù)以行相關的存儲體系架構(gòu)進行空間分配，主要適合于小批量的數(shù)據(jù)處理，常用于聯(lián)機事務型數(shù)據(jù)處理。
基于列式數(shù)據(jù)庫的列列存儲特性，可以解決某些特定場景下關系型數(shù)據(jù)庫 I/O 較高的問題。
6.1 基本原理
傳統(tǒng)關系型數(shù)據(jù)庫是按照行來存儲數(shù)據(jù)庫，稱為“行式數(shù)據(jù)庫”，而列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。
將表放入存儲系統(tǒng)中有兩種方法，而我們絕大部分是采用行存儲的。行存儲法是將各行放入連續(xù)的物理位置，這很像傳統(tǒng)的記錄和文件系統(tǒng)。
列存儲法是將數(shù)據(jù)按照列存儲到數(shù)據(jù)庫中，與行存儲類似。
下圖是兩種存儲方法的圖形化解釋：
6.2 常見列式數(shù)據(jù)庫
HBase：是一個開源的非關系型分布式數(shù)據(jù)庫（NoSQL），它參考了谷歌的 BigTable 建模，實現(xiàn)的編程語言為 Java。
它是 Apache 軟件基金會的 Hadoop 項目的一部分，運行于 HDFS 文件系統(tǒng)之上，為 Hadoop 提供類似于 BigTable 規(guī)模的服務。因此，它可以容錯地存儲海量稀疏的數(shù)據(jù)。
BigTable：是一種壓縮的、高性能的、高可擴展性的，基于 Google 文件系統(tǒng)（Google File System，GFS）的數(shù)據(jù)存儲系統(tǒng)，用于存儲大規(guī)模結(jié)構(gòu)化數(shù)據(jù)，適用于云端計算。
6.3 相關特性
1）優(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)過字典表進行數(shù)據(jù)壓縮后，表中的字符串才都變成數(shù)字了。
正因為每個字符串在字典表里只出現(xiàn)一次了，所以達到了壓縮的目的(有點像規(guī)范化和非規(guī)范化 Normalize 和 Denomalize)。
查詢效率高：讀取多條數(shù)據(jù)的同一列效率高，因為這些列都是存儲在一起的，一次磁盤操作可以把數(shù)據(jù)的指定列全部讀取到內(nèi)存中。
下圖通過一條查詢的執(zhí)行過程說明列式存儲(以及數(shù)據(jù)壓縮)的優(yōu)點：
執(zhí)行步驟如下：
a. 去字典表里找到字符串對應數(shù)字(只進行一次字符串比較)；
b. 用數(shù)字去列表里匹配，匹配上的位置設為 1。；
c. 把不同列的匹配結(jié)果進行位運算得到符合所有條件的記錄下標；
d. 使用這個下標組裝出最終的結(jié)果集。
列式數(shù)據(jù)庫還適合做聚合操作，適合大量的數(shù)據(jù)而不是小數(shù)據(jù)。
2）缺點如下：
不適合掃描小量數(shù)據(jù)；
不適合隨機的更新；
不適合做含有刪除和更新的實時操作；
單行的數(shù)據(jù)是 ACID 的，多行的事務時，不支持事務的正常回滾，支持 I(Isolation)隔離性(事務串行提交)，D(Durability)持久性，不能保證 A(Atomicity)原子性， C(Consistency)一致性。
6.3 使用場景
以 HBase 為例說明：
1）大數(shù)據(jù)量（100s TB級數(shù)據(jù)），且有快速隨機訪問的需求；
2）寫密集型應用，每天寫入量巨大，而相對讀數(shù)量較小的應用，比如 IM 的歷史消息，游戲的日志等等；
3）不需要復雜查詢條件來查詢數(shù)據(jù)的應用，HBase 只支持基于 rowkey 的查詢，對于 HBase 來說，單條記錄或者小范圍的查詢是可以接受的。大范圍的查詢由于分布式的原因，可能在性能上有點影響，HBase 不適用于有 join，多級索引，表關系復雜的數(shù)據(jù)模型；
4）對性能和可靠性要求非常高的應用，由于 HBase 本身沒有單點故障，可用性非常高；
5）數(shù)據(jù)量較大而且增長量無法預估的應用，需要進行優(yōu)雅的數(shù)據(jù)擴展的 HBase 支持在線擴展，即使在一段時間內(nèi)數(shù)據(jù)量呈井噴式增長，也可以通過 HBase 橫向擴展來滿足功能；
6）存儲結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)。
7、K-V 數(shù)據(jù)庫
指的是使用鍵值(key-value)存儲的數(shù)據(jù)庫，其數(shù)據(jù)按照鍵值對的形式進行組織、索引和存儲。
K-V 存儲非常適合不涉及過多數(shù)據(jù)關系業(yè)務關系的數(shù)據(jù)，同時能有效減少讀寫磁盤的次數(shù)，比 SQL 數(shù)據(jù)庫存儲擁有更好的讀寫性能，能夠解決關系型數(shù)據(jù)庫無法存儲數(shù)據(jù)結(jié)構(gòu)的問題。
7.1 常見 K-V 數(shù)據(jù)庫
Redis：是一個使用 ANSI C 編寫的開源、支持網(wǎng)絡、基于內(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 良好的可擴展性和性能。
它被 Apple，Comcas，Instagram，Spotify，eBay，Rackspace，Netflix 等知名網(wǎng)站所采用，成為了一種流行的分布式結(jié)構(gòu)化數(shù)據(jù)存儲方案。
LevelDB：是一個由 Google 公司所研發(fā)的鍵／值對（Key/Value Pair）嵌入式數(shù)據(jù)庫管理系統(tǒng)編程庫， 以開源的 BSD 許可證發(fā)布。
7.2 相關特性
以 Redis 為例，K-V 數(shù)據(jù)庫優(yōu)點如下：
1）性能極高：Redis 能支持超過 10W 的 TPS；
2）豐富的數(shù)據(jù)類型：Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog；
3）豐富的特性：Redis 還支持 publish/subscribe，通知，key 過期等等特性。
缺點如下：
針對 ACID，Redis 事務不能支持原子性和持久性(A 和 D)，只支持隔離性和一致性(I 和 C) 。
特別說明一下：這里所說的無法保證原子性，是針對 Redis 的事務操作，因為事務是不支持回滾（roll back），而因為 Redis 的單線程模型，Redis 的普通操作是原子性的。
大部分業(yè)務不需要嚴格遵循 ACID 原則，例如游戲?qū)崟r排行榜，粉絲關注等場景，即使部分數(shù)據(jù)持久化失敗，其實業(yè)務影響也非常小。因此在設計方案時，需要根據(jù)業(yè)務特征和要求來做選擇。
7.3 使用場景
適用場景：
儲存用戶信息(比如會話)、配置文件、參數(shù)、購物車等等。這些信息一般都和 ID（鍵）掛鉤。
不適用場景：
1）需要通過值來查詢，而不是鍵來查詢：Key-Value 數(shù)據(jù)庫中根本沒有通過值查詢的途徑；
2）需要儲存數(shù)據(jù)之間的關系：在 Key-Value 數(shù)據(jù)庫中不能通過兩個或以上的鍵來關聯(lián)數(shù)據(jù)；
3）需要事務的支持：在 Key-Value 數(shù)據(jù)庫中故障產(chǎn)生時不可以進行回滾。
8、文檔數(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 中不存在的字段也不會導致 SQL 那樣的語法錯誤，可以解決關系型數(shù)據(jù)庫表結(jié)構(gòu) Schema 擴展不方便的問題。
8.1 常見文檔數(shù)據(jù)庫
MongoDB：是一種面向文檔的數(shù)據(jù)庫管理系統(tǒng)，由 C++ 撰寫而成，以此來解決應用程序開發(fā)社區(qū)中的大量現(xiàn)實問題。2007 年 10 月，MongoDB 由 10gen 團隊所發(fā)展。2009 年 2 月首度推出。
CouchDB：Apache CouchDB 是一個開源數(shù)據(jù)庫，專注于易用性和成為"完全擁抱 Web 的數(shù)據(jù)庫"。
它是一個使用 JSON 作為存儲格式，JavaScript 作為查詢語言，MapReduce 和 HTTP 作為 API 的 NoSQL 數(shù)據(jù)庫。
其中一個顯著的功能就是多主復制。CouchDB 的第一個版本發(fā)布在 2005 年，在 2008 年成為了 Apache 的項目。
8.2 相關特性
以 MongoDB 為例進行說明，文檔數(shù)據(jù)庫優(yōu)點如下：
1）新增字段簡單，無需像關系型數(shù)據(jù)庫一樣先執(zhí)行 DDL 語句修改表結(jié)構(gòu)，程序代碼直接讀寫即可；
2）容易兼容歷史數(shù)據(jù)，對于歷史數(shù)據(jù)，即使沒有新增的字段，也不會導致錯誤，只會返回空值，此時代碼兼容處理即可；
3）容易存儲復雜數(shù)據(jù)，JSON 是一種強大的描述語言，能夠描述復雜的數(shù)據(jù)結(jié)構(gòu)。
相比傳統(tǒng)關系型數(shù)據(jù)庫，文檔數(shù)據(jù)庫的缺點主要是對多條數(shù)據(jù)記錄的事務支持較弱，具體體現(xiàn)如下：
1）Atomicity(原子性)，僅支持單行/文檔級原子性，不支持多行、多文檔、多語句原子性；
2）Solation(隔離性)，隔離級別僅支持已提交讀（Read committed）級別，可能導致不可重復讀，幻讀的問題；
3）不支持復雜查詢，例如 join 查詢，如果需要 join 查詢，需要多次操作數(shù)據(jù)庫。
MongonDB 還支持多文檔事務的 Consistency(一致性)和 Durability(持久性)，雖然官方宣布 MongoDB 將在 4.0 版本中正式推出多文檔 ACID 事務支持，最后落地情況還有待見證。
8.3 使用場景
適用場景：
1）數(shù)據(jù)量很大或者未來會變得很大；
2）表結(jié)構(gòu)不明確，且字段在不斷增加，例如內(nèi)容管理系統(tǒng)，信息管理系統(tǒng)。
不適用場景：
1）在不同的文檔上需要添加事務。Document-Oriented 數(shù)據(jù)庫并不支持文檔間的事務；
2）多個文檔之間需要復雜查詢，例如 join。
9、全文搜索引擎
傳統(tǒng)關系型數(shù)據(jù)庫主要通過索引來達到快速查詢的目的，在全文搜索的業(yè)務下，索引也無能為力。
主要體現(xiàn)在：
1）全文搜索的條件可以隨意排列組合，如果通過索引來滿足，則索引的數(shù)量非常多；
2）全文搜索的模糊匹配方式，索引無法滿足，只能用 like 查詢，而 like 查詢是整表掃描，效率非常低。
而全文搜索引擎的出現(xiàn)，正是解決關系型數(shù)據(jù)庫全文搜索功能較弱的問題。
9.1 基本原理
全文搜索引擎的技術原理稱為“倒排索引”（inverted index），是一種索引方法，其基本原理是建立單詞到文檔的索引。與之相對的是“正排索引”，其基本原理是建立文檔到單詞的索引。
現(xiàn)在有如下文檔集合：
正排索引得到索引如下：
由上可見，正排索引適用于根據(jù)文檔名稱查詢文檔內(nèi)容。
簡單的倒排索引如下：
帶有單詞頻率信息的倒排索引如下：
由上可見，倒排索引適用于根據(jù)關鍵詞來查詢文檔內(nèi)容。
9.2 常見全文搜索引擎
Elastic search：是一個基于 Lucene 的搜索引擎。它提供了一個分布式，多租戶，能夠全文搜索與發(fā)動機 HTTP Web 界面和無架構(gòu) JSON 文件。
Elastic search 是用 Java 開發(fā)的，并根據(jù) Apache License 的條款作為開源發(fā)布。
根據(jù) DB-Engines 排名，Elasticsearch 是最受歡迎的企業(yè)搜索引擎，后面是基于 Lucene 的 Apache Solr。
Solr：是 Apache Lucene 項目的開源企業(yè)搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態(tài)聚類、數(shù)據(jù)庫集成，以及富文本（如 Word、PDF）的處理。Solr 是高度可擴展的，并提供了分布式搜索和索引復制。
9.3 相關特性
以 Elasticsearch 為例，全文搜索引擎優(yōu)點如下：
1）查詢效率高，對海量數(shù)據(jù)進行近實時的處理；
2）可擴展性，基于集群環(huán)境可以方便橫向擴展，可以承載 PB 級數(shù)據(jù)；
3）高可用，Elasticsearch 集群彈性，他們將發(fā)現(xiàn)新的或失敗的節(jié)點，重組和重新平衡數(shù)據(jù)，確保數(shù)據(jù)是安全的和可訪問的。
缺點如下：
1）ACID 支持不足，單一文檔的數(shù)據(jù)是 ACID 的，包含多個文檔的事務時不支持事務的正常回滾，支持 I(Isolation)隔離性（基于樂觀鎖機制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性；
2）對類似數(shù)據(jù)庫中通過外鍵的復雜的多表關聯(lián)操作支持較弱；
3）讀寫有一定延時，寫入的數(shù)據(jù)，最快 1s 中能被檢索到；
4）更新性能較低，底層實現(xiàn)是先刪數(shù)據(jù)，再插入新數(shù)據(jù)；
5）內(nèi)存占用大，因為 Lucene 將索引部分加載到內(nèi)存中。
9.4 使用場景
適用場景如下：
1）分布式的搜索引擎和數(shù)據(jù)分析引擎；
2）全文檢索，結(jié)構(gòu)化檢索，數(shù)據(jù)分析；
3）對海量數(shù)據(jù)進行近實時的處理，可以將海量數(shù)據(jù)分散到多臺服務器上去存儲和檢索。
不適用場景如下：
1）數(shù)據(jù)需要頻繁更新；
2）需要復雜關聯(lián)查詢。
10、圖形數(shù)據(jù)庫
圖形數(shù)據(jù)庫應用圖形理論存儲實體之間的關系信息。最常見例子就是社會網(wǎng)絡中人與人之間的關系。
關系型數(shù)據(jù)庫用于存儲“關系型”數(shù)據(jù)的效果并不好，其查詢復雜、緩慢、超出預期。
而圖形數(shù)據(jù)庫的獨特設計恰恰彌補了這個缺陷，解決關系型數(shù)據(jù)庫存儲和處理復雜關系型數(shù)據(jù)功能較弱的問題。
10.1 常見圖形數(shù)據(jù)庫
Neo4j：是由 Neo4j，Inc. 開發(fā)的圖形數(shù)據(jù)庫管理系統(tǒng)。由其開發(fā)人員描述為具有原生圖存儲和處理的符合 ACID 的事務數(shù)據(jù)庫，根據(jù) DB-Engines 排名，Neo4j 是最流行的圖形數(shù)據(jù)庫。
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：是一個可擴展的圖形數(shù)據(jù)庫，針對存儲和查詢包含分布在多機群集中的數(shù)百億個頂點和邊緣的圖形進行了優(yōu)化。
Titan 是一個事務性數(shù)據(jù)庫，可以支持數(shù)千個并發(fā)用戶實時執(zhí)行復雜的圖形遍歷。
10.2 相關特性
以 Neo4j 為例，Neo4j 使用數(shù)據(jù)結(jié)構(gòu)中圖（graph）的概念來進行建模。Neo4j 中兩個最基本的概念是節(jié)點和邊。
節(jié)點表示實體，邊則表示實體之間的關系。節(jié)點和邊都可以有自己的屬性。不同實體通過各種不同的關系關聯(lián)起來，形成復雜的對象圖。
針對關系數(shù)據(jù)，兩種數(shù)據(jù)庫的存儲結(jié)構(gòu)不同：
Neo4j 中，存儲節(jié)點時使用了“index-free adjacency”，即每個節(jié)點都有指向其鄰居節(jié)點的指針，可以讓我們在 O(1) 的時間內(nèi)找到鄰居節(jié)點。
另外，按照官方的說法，在 Neo4j 中邊是最重要的，即“first-class entities”，所以單獨存儲，這有利于在圖遍歷的時候提高速度，也可以很方便地以任何方向進行遍歷。
優(yōu)點如下：
1）高性能表現(xiàn)，圖的遍歷是圖數(shù)據(jù)結(jié)構(gòu)所具有的獨特算法，即從一個節(jié)點開始，根據(jù)其連接的關系，可以快速和方便地找出它的鄰近節(jié)點。
這種查找數(shù)據(jù)的方法并不受數(shù)據(jù)量的大小所影響，因為鄰近查詢始終查找的是有限的局部數(shù)據(jù)，不會對整個數(shù)據(jù)庫進行搜索。
2）設計的靈活性，數(shù)據(jù)結(jié)構(gòu)的自然伸展特性及其非結(jié)構(gòu)化的數(shù)據(jù)格式，讓圖數(shù)據(jù)庫設計可以具有很大的伸縮性和靈活性。
因為隨著需求的變化而增加的節(jié)點、關系及其屬性并不會影響到原來數(shù)據(jù)的正常使用。
3）開發(fā)的敏捷性，直觀明了的數(shù)據(jù)模型，從需求的討論開始，到程序開發(fā)和實現(xiàn)，以及最終保存在數(shù)據(jù)庫中的樣子，它的模樣似乎沒有什么變化，甚至可以說本來就是一模一樣的。
4）完全支持 ACID，不像別的 NoSQL 數(shù)據(jù)庫，Neo4j 還具有完全事務管理特性，完全支持 ACID 事務管理。
缺點如下：
1）具有支持節(jié)點，關系和屬性的數(shù)量的限制；
2）不支持拆分。
10.3 使用場景
適用場景如下：
1）在一些關系性強的數(shù)據(jù)中，例如社交網(wǎng)絡；
2）推薦引擎。如果我們將數(shù)據(jù)以圖的形式表現(xiàn)，那么將會非常有益于推薦的制定。
不適用場景如下：
1）記錄大量基于事件的數(shù)據(jù)（例如日志條目或傳感器數(shù)據(jù)）；
2）對大規(guī)模分布式數(shù)據(jù)進行處理，類似于 Hadoop；
3）適合于保存在關系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)；
4）二進制數(shù)據(jù)存儲。
11、本文小結(jié)
關系型數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫的選型，往往需要考慮幾個指標：
1）數(shù)據(jù)量；
2）并發(fā)量；
3）實時性；
4）一致性要求；
5）讀寫分布和類型；
6）安全性；
7）運維成本。
常見軟件系統(tǒng)數(shù)據(jù)庫選型參考如下：
1）內(nèi)部使用的管理型系統(tǒng)，如運營系統(tǒng)，數(shù)據(jù)量少，并發(fā)量小，首選考慮關系型；
2）大流量系統(tǒng)，如電商單品頁，后臺考慮選關系型，前臺考慮選內(nèi)存型；
3）日志型系統(tǒng)，原始數(shù)據(jù)考慮選列式，日志搜索考慮選倒排索引；
4）搜索型系統(tǒng)，例如站內(nèi)搜索，非通用搜索，如商品搜索，后臺考慮選關系型，前臺考慮選倒排索引；
5）事務型系統(tǒng)，如庫存，交易，記賬，考慮選關系型+緩存+一致性型協(xié)議；
6）離線計算，如大量數(shù)據(jù)分析，考慮選列式或者關系型也可以；
7）實時計算，如實時監(jiān)控，可以考慮選內(nèi)存型或者列式數(shù)據(jù)庫。
在設計實踐中，我們要基于需求、業(yè)務驅(qū)動架構(gòu)，無論選用 RDB/NoSQL/DRDB，一定是以需求為導向，最終數(shù)據(jù)存儲方案必然是各種權(quán)衡的綜合性設計。
附錄：更多IM架構(gòu)及其它熱門問題文章匯總
[1] 有關IM架構(gòu)設計的文章：
《淺談IM系統(tǒng)的架構(gòu)設計》
《簡述移動端IM開發(fā)的那些坑：架構(gòu)設計、通信協(xié)議和客戶端》
《一套海量在線用戶的移動端IM架構(gòu)設計實踐分享(含詳細圖文)》
《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時通訊系統(tǒng)的技術架構(gòu)演進歷程》
《蘑菇街即時通訊/IM服務器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術挑戰(zhàn)和架構(gòu)演進之路PPT》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設計實踐》
《微信技術總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產(chǎn)品的技術方法論》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》
《IM開發(fā)基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構(gòu)？》
《IM開發(fā)基礎知識補課(三)：快速理解服務端數(shù)據(jù)庫讀寫分離原理及實踐建議》
《IM開發(fā)基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創(chuàng)造的技術神話》
《微信朋友圈千億訪問量背后的技術挑戰(zhàn)和實踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術架構(gòu)、網(wǎng)絡方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設計的方方面面》
《以微博類應用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》
《IM開發(fā)基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分布式架構(gòu)的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設計實踐》
《阿里技術分享：深度揭秘阿里數(shù)據(jù)庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構(gòu)、技術實現(xiàn)等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節(jié)》
《社交軟件紅包技術解密(四)：微信紅包系統(tǒng)是如何應對高并發(fā)的》
《社交軟件紅包技術解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高并發(fā)技術實踐》
《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構(gòu)等》
《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現(xiàn)IM的負載均衡？》
《即時通訊新手入門：快速理解RPC技術——基本概念、原理和用途》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》
《從游擊隊到正規(guī)軍：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進之路》
《IM開發(fā)基礎知識補課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》
>> 更多同類文章 ……
[2] 更多其它架構(gòu)設計相關文章：
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設計的方方面面》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》
《新手入門：零基礎理解大型分布式架構(gòu)的演進歷史、技術原理、最佳實踐》
《阿里技術分享：深度揭秘阿里數(shù)據(jù)庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》
《達達O2O后臺架構(gòu)演進實踐：從0到4000高并發(fā)請求背后的努力》
《優(yōu)秀后端架構(gòu)師必會知識：史上最全MySQL大表優(yōu)化方案總結(jié)》
《小米技術分享：解密小米搶購系統(tǒng)千萬高并發(fā)架構(gòu)的演進和實踐》
《一篇讀懂分布式架構(gòu)下的負載均衡技術：分類、原理、算法、常見方案等》
《通俗易懂：如何設計能支撐百萬并發(fā)的數(shù)據(jù)庫架構(gòu)？》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》
《從新手到架構(gòu)師，一篇就夠：從100到1000萬高并發(fā)的架構(gòu)演進之路》
《美團技術分享：深度解密美團的分布式ID生成算法》
>> 更多同類文章 ……
[3] IM開發(fā)綜合文章：
《新手入門一篇就夠：從零開發(fā)移動端IM》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結(jié)》
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應、安全保障》
《騰訊技術分享：社交網(wǎng)絡圖片的帶寬壓縮技術演進之路》
《小白必讀：閑話HTTP短連接中的Session和Token》
《IM開發(fā)基礎知識補課：正確理解前置HTTP SSO單點登陸接口的原理》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《移動端IM開發(fā)需要面對的技術問題》
《開發(fā)IM是自己設計協(xié)議用字節(jié)流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現(xiàn)方式嗎？》
《IM消息送達保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和群聊中的在線狀態(tài)同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《談談移動端 IM 開發(fā)中登錄請求的優(yōu)化》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》
《淺談移動端IM的多點登陸和消息漫游原理》
《完全自已開發(fā)的IM該如何設計“失敗重試”機制？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《微信對網(wǎng)絡影響的技術試驗及分析（論文全文）》
《即時通訊系統(tǒng)的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡下APP的流量消耗（上篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網(wǎng)絡層跨平臺組件庫Mars已正式開源》
《基于社交網(wǎng)絡的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的？》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(音視頻技術篇)》
《字符編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特點、性能、調(diào)優(yōu)等》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術實踐》
《IM開發(fā)基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發(fā)IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《融云技術分享：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《IM開發(fā)基礎知識補課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2759-1-1.html）