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

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

NOSQL的概念

剛剛出現(xiàn)NOSQL這個(gè)概念的時(shí)候赏枚，很多人都是似而非的字面理解成"不是SQL"， 與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是兩個(gè)完全獨(dú)立的陣營(yíng)晓猛，實(shí)際上完全不是這么回事饿幅。個(gè)人更傾向于理解NOSQL的誕生更多的是為了補(bǔ)充關(guān)系型數(shù)據(jù)庫(kù)的短板，滿足現(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ù)庫(kù)的數(shù)據(jù)庫(kù)管理系統(tǒng)的統(tǒng)稱乳乌。與關(guān)系型數(shù)據(jù)庫(kù)相比，它們?cè)诩軜?gòu)和數(shù)據(jù)模型方面做了“減法”市咆，而在擴(kuò)展和并發(fā)等方面做了“加法”汉操。

NOSQL簡(jiǎn)史

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

2009年搜变，Last.fm的Johan Oskarsson發(fā)起了一次關(guān)于分布式開(kāi)源數(shù)據(jù)庫(kù)的討論采缚，來(lái)自Rackspace的Eric Evans再次提出了NoSQL的概念，這時(shí)的NoSQL主要指非關(guān)系型挠他、分布式仰担、不提供ACID的數(shù)據(jù)庫(kù)設(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ù)庫(kù)的優(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ù)庫(kù)都具有非常高的讀寫(xiě)性能败砂，尤其在大數(shù)據(jù)量下赌渣，同樣表現(xiàn)優(yōu)秀。這得益于它的無(wú)關(guān)系性昌犹，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單坚芜。

NOSQL的分類

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

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

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

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

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

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

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

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

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

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

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

http://nosql-database.org/

十萬(wàn)個(gè)為什么

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

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

列數(shù)據(jù)庫(kù)的存儲(chǔ)方式與行數(shù)據(jù)庫(kù)也有顯著不同：行式存儲(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)行查詢。

我是不是說(shuō)的挺明白的？

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

我們就以社交網(wǎng)絡(luò)為例搞挣，來(lái)簡(jiǎn)要說(shuō)明下圖數(shù)據(jù)庫(kù)到底快在哪里带迟。 如下我們有個(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ù)庫(kù)來(lái)說(shuō)，這種多對(duì)多的模型囱桨，除了基本的users表之外仓犬， 這個(gè)朋友之間的映射關(guān)系表必然需要建一張。

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

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

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

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

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

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

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

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

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

六度分離問(wèn)題

六度分離（六度區(qū)隔）理論（Six Degrees of Separation）：“你和任何一個(gè)陌生人之間所間隔的人不會(huì)超過(guò)五個(gè)荞估，也就是說(shuō)咳促，最多通過(guò)五個(gè)人你就能夠認(rèn)識(shí)任何一個(gè)陌生人∑貌眨”

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

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

柯尼斯堡七橋問(wèn)題

-- 一筆畫(huà)問(wèn)題

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

這個(gè)問(wèn)題的解決被世人作為圖論的起源來(lái)看待趣席，歐拉也由此被稱為“圖論之父”兵志。