NOSQL這個(gè)概念其實(shí)唱了好多好多年了，但是真正浸淫其中, 理解深刻并享受到紅利的人占比其實(shí)并不高。

近期筆者自己會(huì)在大數(shù)據(jù)、圖數(shù)據(jù)等方面邊學(xué)習(xí)邊記錄一些筆記，持續(xù)分享自己的心得體會(huì)，此文權(quán)當(dāng)發(fā)力之前的開山篇，希望更多關(guān)心該領(lǐng)域的朋友多多關(guān)注、支持和幫助。

NOSQL的概念

剛剛出現(xiàn)NOSQL這個(gè)概念的時(shí)候，很多人都是似而非的字面理解成"不是SQL"， 與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫是兩個(gè)完全獨(dú)立的陣營(yíng)，實(shí)際上完全不是這么回事。個(gè)人更傾向于理解NOSQL的誕生更多的是為了補(bǔ)充關(guān)系型數(shù)據(jù)庫的短板，滿足現(xiàn)下互聯(lián)網(wǎng)海量數(shù)據(jù)、高并發(fā)、低延遲和非結(jié)構(gòu)化數(shù)據(jù)易擴(kuò)展等需求。

NoSQL = Not Only SQL，意即“不僅僅是SQL”，是對(duì)不同于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)的統(tǒng)稱。與關(guān)系型數(shù)據(jù)庫相比，它們?cè)诩軜?gòu)和數(shù)據(jù)模型方面做了“減法”，而在擴(kuò)展和并發(fā)等方面做了“加法”。

NOSQL簡(jiǎn)史

NoSQL一詞最早出現(xiàn)于1998年，是Carlo Strozzi開發(fā)的一個(gè)輕量、開源、不提供SQL功能的關(guān)系數(shù)據(jù)庫。

2009年，Last.fm的Johan Oskarsson發(fā)起了一次關(guān)于分布式開源數(shù)據(jù)庫的討論，來自Rackspace的Eric Evans再次提出了NoSQL的概念，這時(shí)的NoSQL主要指非關(guān)系型、分布式、不提供ACID的數(shù)據(jù)庫設(shè)計(jì)模式。

2009年在亞特蘭大舉行的"no:sql(east)"討論會(huì)是一個(gè)里程碑，其口號(hào)是"select fun, profit from real_world where relational=false;"。因此，對(duì)NoSQL最普遍的解釋是"非關(guān)聯(lián)型的"，強(qiáng)調(diào)Key-Value Stores和文檔數(shù)據(jù)庫的優(yōu)點(diǎn)，而不是單純的反對(duì)RDBMS。

為何要使用NoSQL

NoSQL具有靈活的數(shù)據(jù)模型，可以處理非結(jié)構(gòu)化/半結(jié)構(gòu)化的大數(shù)據(jù)

NoSQL很容易實(shí)現(xiàn)可伸縮性（向上擴(kuò)展與水平擴(kuò)展）

NoSQL在不太影響性能的情況，就可以方便的實(shí)現(xiàn)高可用的架構(gòu)

NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡(jiǎn)單。

NOSQL的分類

主流的NoSQL數(shù)據(jù)庫主要分為4類：

鍵值(Key-Value)存儲(chǔ)數(shù)據(jù)庫

這一類數(shù)據(jù)庫主要會(huì)使用到一個(gè)哈希表，這個(gè)表中有一個(gè)特定的鍵和一個(gè)指針指向特定的數(shù)據(jù)。Key/value模型對(duì)于IT系統(tǒng)來說的優(yōu)勢(shì)在于簡(jiǎn)單、易部署。但是如果DBA只對(duì)部分值進(jìn)行查詢或更新的時(shí)候，Key/value就顯得效率低下了。例如：Redis,Memcache, DynamoDB等

列存儲(chǔ)(Wide-Column)數(shù)據(jù)庫

這部分?jǐn)?shù)據(jù)庫通常是用來應(yīng)對(duì)分布式存儲(chǔ)的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點(diǎn)是指向了多個(gè)列。這些列是由列家族來安排的。如：Cassandra, HBase。

文檔型(Document)數(shù)據(jù)庫

文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲(chǔ)相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲(chǔ)，比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級(jí)版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如：CouchDB, MongoDB。

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

圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴(kuò)展到多個(gè)服務(wù)器上。NoSQL數(shù)據(jù)庫沒有標(biāo)準(zhǔn)的查詢語言(SQL)，因此進(jìn)行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。 如：OrientDB, Neo4J, Titan等。

其他還有類似對(duì)象數(shù)據(jù)庫，XML數(shù)據(jù)庫大家自行搜索吧。另外很多NOSQL數(shù)據(jù)庫其實(shí)是支持多模型的，比如OrientDB同時(shí)支持Key-Value, Document, Graph, Object數(shù)據(jù)庫。

更多NOSQL數(shù)據(jù)庫列表請(qǐng)看

http://nosql-database.org/

十萬個(gè)為什么

列數(shù)據(jù)庫到底牛逼在哪里

其實(shí)應(yīng)該這么說，列數(shù)據(jù)庫只有在OLAP,或者說對(duì)部分列進(jìn)行聚合操作的場(chǎng)景下, 比如sum、count、groupby之類的運(yùn)算，它確實(shí)優(yōu)秀。但是如果是OLTP，大量的更新或者大量的整行查詢，那列數(shù)據(jù)庫沒有優(yōu)勢(shì)，甚至反而會(huì)比RDBMS更慢。

列數(shù)據(jù)庫的存儲(chǔ)方式與行數(shù)據(jù)庫也有顯著不同：行式存儲(chǔ)中，主鍵是rowid，由它關(guān)聯(lián)到索引數(shù)據(jù)；列式存儲(chǔ)中，主鍵是數(shù)據(jù)本身，關(guān)聯(lián)回rowid，即“數(shù)據(jù)即索引”。

這里有個(gè)對(duì)比的paper, 有興趣的可以讀一下

http://db.csail.mit.edu/projects/cstore/abadi-sigmod08.pdf

列存儲(chǔ) vs 行存儲(chǔ) WIKI

https://en.wikipedia.org/wiki/Column-oriented_DBMS

文檔DB?VS鍵值DB

它倆的主要區(qū)別簡(jiǎn)單一句話，就是：鍵值DB不知道Value的格式和內(nèi)容，而文檔DB知道且可以在格式化的Value內(nèi)容（Json/XML）上建立索引進(jìn)行查詢。

我是不是說的挺明白的？

圖DB做社交關(guān)系為什么快

我們就以社交網(wǎng)絡(luò)為例，來簡(jiǎn)要說明下圖數(shù)據(jù)庫到底快在哪里。 如下我們有個(gè)朋友關(guān)系表：

> SELECT * FROM friends;

+-------------+--------------+

| user_id ? ? | friend_id ? ?|

+-------------+--------------+

| 1 ? ? ? ? ? | 2 ? ? ? ? ? ?|

| 1 ? ? ? ? ? | 3 ? ? ? ? ? ?|

| 1 ? ? ? ? ? | 4 ? ? ? ? ? ?|

| 2 ? ? ? ? ? | 5 ? ? ? ? ? ?|

| 2 ? ? ? ? ? | 6 ? ? ? ? ? ?|

| 2 ? ? ? ? ? | 7 ? ? ? ? ? ?|

| 3 ? ? ? ? ? | 8 ? ? ? ? ? ?|

| 3 ? ? ? ? ? | 9 ? ? ? ? ? ?|

| 3 ? ? ? ? ? | 10 ? ? ? ? ? |

+-------------+--------------+

對(duì)于關(guān)系型數(shù)據(jù)庫來說，這種多對(duì)多的模型，除了基本的users表之外， 這個(gè)朋友之間的映射關(guān)系表必然需要建一張。

也就是說雖然我們RDBMS這么多年的數(shù)據(jù)庫設(shè)計(jì)，比如ER設(shè)計(jì)中的Relationship或者以外鍵的形式存在，或者以中間表的形式存在。

我們現(xiàn)在需要查詢這樣一個(gè)場(chǎng)景，找userid=1用戶的朋友的朋友，也就是社交網(wǎng)絡(luò)里的2度查詢，大家想想這個(gè)SQL應(yīng)該怎么寫（不難，大家自己試驗(yàn)一下吧）。

問題是在互聯(lián)網(wǎng)海量數(shù)據(jù)的社交模型中，2度查詢太簡(jiǎn)單了，6度查詢或者更高呢？你這個(gè)SQL語句還能寫出來么或者說能跑出來么？（6度查詢的笛卡爾積是相當(dāng)恐怖的數(shù)字）。

但是對(duì)于圖數(shù)據(jù)庫而言，Relationship關(guān)系是一等公民（在圖數(shù)據(jù)庫領(lǐng)域一般叫做Edge, 圖中的箭頭）, 與上圖中用戶本身的頂點(diǎn)Vetex(圖中的圓)是相同的地位。

在圖數(shù)據(jù)庫中，我要查詢userid=1用戶的朋友的朋友，只需要先定位到Vertex(1)，然后從這個(gè)頂點(diǎn)遍歷所有的friend Edge, 就可以查詢出想要的結(jié)果，就算是6度查詢，也不過是多了幾層遍歷而已，這個(gè)性能的消耗是線性的，完全不是關(guān)系型數(shù)據(jù)庫笛卡爾積的指數(shù)性增長(zhǎng)可比！

100個(gè)用戶可能區(qū)別不大，但如果是100w的用戶關(guān)系圖譜，對(duì)于圖數(shù)據(jù)庫而言都是從一個(gè)點(diǎn)來遍歷，性能沒有明顯的區(qū)別。

有個(gè)比較好理解的類比，想象你作為一個(gè)觀眾坐在八萬人體育館看球賽，這是一場(chǎng)沒人關(guān)注的比賽，賽場(chǎng)只做了100個(gè)人，那在你座位旁邊的人（視作有關(guān)系）是有限的幾個(gè)人，或者甚至旁邊沒人；但是如果這是一場(chǎng)同城德比超級(jí)火爆的比賽，賽場(chǎng)坐滿了八萬人，坐在你旁邊跟你有關(guān)系的人其實(shí)還是有限的那幾個(gè)而已（有限“度”的遍歷），離你遠(yuǎn)的人對(duì)從你開始的遍歷沒有任何顯著的影響！

這就是圖數(shù)據(jù)庫的魅力， 我應(yīng)該說明白了吧？

再來幾個(gè)裝逼理論

六度分離問題

六度分離（六度區(qū)隔）理論（Six Degrees of Separation）：“你和任何一個(gè)陌生人之間所間隔的人不會(huì)超過五個(gè)，也就是說，最多通過五個(gè)人你就能夠認(rèn)識(shí)任何一個(gè)陌生人?！?/p>

根據(jù)這個(gè)理論，你和世界上的任何一個(gè)人之間只隔著五個(gè)人，不管對(duì)方在哪個(gè)國(guó)家，屬哪類人種，是哪種膚色。

這個(gè)理論也是做社交網(wǎng)絡(luò)的一個(gè)基本理念。

柯尼斯堡七橋問題

-- 一筆畫問題

在哥尼斯堡的一個(gè)公園里，有七座橋?qū)⑵绽赘駹柡又袃蓚€(gè)島及島與河岸連接起來(如圖)。問是否可能從這四塊陸地中任一塊出發(fā)，恰好通過每座橋一次，再回到起點(diǎn)？歐拉于1736年研究并解決了此問題，他把問題歸結(jié)為如右圖的“一筆畫”問題，證明上述走法是不可能的。

這個(gè)問題的解決被世人作為圖論的起源來看待，歐拉也由此被稱為“圖論之父”。