有SQL數(shù)據(jù)庫為什么還要有NoSQL

問題問得好，nosql的出現(xiàn)是在sql不能滿足業(yè)務(wù)數(shù)據(jù)處理的前提下誕生的，

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了樂東黎族免費建站歡迎大家使用！

如何選擇數(shù)據(jù)庫

如何選擇數(shù)據(jù)庫

柳樹

公眾號：柳樹的絮叨叨

關(guān)注他

30 人贊同了該文章

我們正在做一個電子書小程序。

1.0 層次模型數(shù)據(jù)庫

用戶購買，生成訂單，訂單詳情里有用戶購買的電子書：

一層一層鋪開，一對多，這是「層次模型數(shù)據(jù)庫」（Hierarchical Database）。

2.0 網(wǎng)狀模型數(shù)據(jù)庫

一筆訂單可以購買多本電子書，一本電子書也可以被多筆訂單購買：

這就形成了「多對多」的「網(wǎng)狀模型數(shù)據(jù)庫」（Network Database）。

上面講的兩種數(shù)據(jù)庫，也許你聽都沒聽過。

我們用的，是「關(guān)系模型」，而非上面的「層次模型」或者「網(wǎng)狀模型」。

為什么？

你會說，這樣不方便遍歷所有訂單。

并不會，再加一個根節(jié)點就好：

你會說，這樣查找效率很低。

也不會，因為可以優(yōu)化下數(shù)據(jù)結(jié)構(gòu)，比如換成 B+ 樹。

為什么我們從一開始就在用「關(guān)系模型數(shù)據(jù)庫」？

3.0 關(guān)系模型數(shù)據(jù)庫

無論是層次模型還是網(wǎng)狀模型，程序員看到的，都是實實在在的物理存儲結(jié)構(gòu)。

查詢時，你要照著里面的數(shù)據(jù)結(jié)構(gòu)，用對應(yīng)的算法來查；

插入時，你也要照著數(shù)據(jù)結(jié)構(gòu)，用對應(yīng)算法來插入，否則你就破壞了數(shù)據(jù)的組織結(jié)構(gòu)，數(shù)據(jù)也就壞掉了。

因為我們都沒用過前面兩種數(shù)據(jù)庫，所以覺得「關(guān)系模型數(shù)據(jù)庫」（以下簡稱 RDB）的一切都理所當(dāng)然，但其實，它做出了一個革命性的變革：

用邏輯結(jié)構(gòu)（logical representation of data）代替物理結(jié)構(gòu)（physical representation of data）

所謂「邏輯結(jié)構(gòu)」，也就是我們經(jīng)常看到的「表格」，User 是一張表格，Order 是一張表格，Book 又是一張表格，它們之間的關(guān)系，用 id 來關(guān)聯(lián)，這些 id，可能是 number 類型，也可能是 string 類型

但你看到的，不一定就是實際的，你看到的只是讓你方便理解的「邏輯結(jié)構(gòu)」，真實數(shù)據(jù)自然不是這樣按表格來存儲，表格無異于一個數(shù)組，數(shù)組查詢是很慢的。

真實的「物理結(jié)構(gòu)」，也許還是像「層次模型」和「網(wǎng)狀模型」一樣，是復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

但到底是怎樣的數(shù)據(jù)結(jié)構(gòu)，你都無需關(guān)心，你只需把它想象成一張「表」去操作，就連可視化工具，都會幫你把數(shù)據(jù)可視化成表，來方便你理解。

這個觀念的提出，來自于 1970 年 Codd 的一篇論文，A Relational Model of Data for Large Shared Data Banks：

Future users of large data banks must?be protected from having to know how the data is organized in the machine?(the internal representation).?

Activities of users at terminals and most application programs should?remain unaffected when the internal representation of data is changed?and even when some aspects of the external representation are changed.?

—— Codd

Codd 的這種思想，其實就是經(jīng)濟學(xué)里提到的：分工產(chǎn)生效能。

程序員們不需要直接和物理結(jié)構(gòu)打交道，只負(fù)責(zé)告訴數(shù)據(jù)庫，他想做什么，至于數(shù)據(jù)是如何存儲、如何索引，都交給數(shù)據(jù)庫，最終他們看到的就是一張張?zhí)貏e直觀、特別好理解的 excel 表格。

而數(shù)據(jù)庫則把維護(hù)物理結(jié)構(gòu)的復(fù)雜邏輯，交給了自己， 對程序員屏蔽了復(fù)雜的實現(xiàn)細(xì)節(jié)。

開發(fā)時寫的代碼少了，耦合性降低了，數(shù)據(jù)也不容易損壞，也就提高了生產(chǎn)效率（productive）。

一切能用同樣的耗能，帶來更多效能的技術(shù)，都會被廣泛使用。

NoSQL

那后來為什么又有了 NoSQL 呢？

在 RDB 被發(fā)明的時代，軟件多用于大型企業(yè)，比如銀行、金融等等，人們對數(shù)據(jù)的要求非常純粹：準(zhǔn)確、可靠、安全，讓數(shù)據(jù)按照期望，正確的寫入，不要給老子算錯錢就好，于是有了具有 ACID 特性的事務(wù)：原子性、一致性、隔離性和持久性。

那時候用網(wǎng)絡(luò)的人很少，通過終端來訪問客戶端的人，更少，自然的，數(shù)據(jù)庫的數(shù)據(jù)量和訪問量都跟現(xiàn)在沒法比，一臺機器，足矣，最多再來個一主多從：

后來，你知道的，每個人手里都有個手機，每分每秒，都有成千上萬的數(shù)據(jù)，寫入你的數(shù)據(jù)庫、從你的數(shù)據(jù)庫被查出，于是有了「分布式」，有了 BASE 和 CAP。這時候，RDB 就會發(fā)現(xiàn)，自己之前的那一套 ACID，竟然有點作繭自縛了：

為了保證事務(wù)的隔離性，要進(jìn)行加鎖，在分布式的環(huán)境下，就要對多臺機器的數(shù)據(jù)進(jìn)行加鎖；

為了保證事務(wù)的原子性，在機器 A 的操作和在機器 B 的操作，要么一起成功，要么一起失敗；

…...

這些都要去不同節(jié)點的機器進(jìn)行通訊和協(xié)調(diào)，實現(xiàn)起來非常復(fù)雜，而且要付出更多的網(wǎng)絡(luò) IO，影響性能。

ACID 在分布式系統(tǒng)上實現(xiàn)起來就會變得難以實現(xiàn)，即使實現(xiàn)了，也要付出很大的性能成本，于是才有了后來的各種「分布式一致性協(xié)議」，Paxos、Raft、2PC …… 而 Mysql 也提供了各種方案來實現(xiàn)分布式，當(dāng)然，這些方案自然是很復(fù)雜的，比如 「NDB Cluster」 ：

而 NoSQL 則沒有這么多承諾，它的一致性，一般都是最終一致性，當(dāng)然你可以選擇強一致，那自然就要付出點性能作為代價，當(dāng)然你還可以弱一致，這樣會更不安全，但是更快，一切取決于你對數(shù)據(jù)的要求。

除此之外，RDB 的「數(shù)據(jù)庫范式」（Database Schema），也成了限制擴展性的瓶頸。為了避免數(shù)據(jù)冗余導(dǎo)致的各種問題（占用空間、刪除異常、更新異常等等），我們在設(shè)計關(guān)系模型時，通常都是按照最小單位來設(shè)計的。

什么叫最小單位，比如用戶有地址和愛好，那么在正確設(shè)計的關(guān)系模型（比如 3NF）里，這就是三張表：

如果這三張表被分散在不同的機器，那進(jìn)行關(guān)聯(lián)查詢時，就需要多次跨機器的通訊；

而對于 NoSQL，這三類信息，都可以利用 Json 格式的數(shù)據(jù)，將它們存放在一起：

完整的存儲進(jìn)去，完整的取出來，不需要額外的操作。

NoSQL 比 RDB 有更強的擴展性，可以充分利用分布式系統(tǒng)來提升讀寫性能和可靠性。

這不是誰設(shè)計好壞的問題，而是跟他們要解決的問題有關(guān)：RDB 誕生于互聯(lián)網(wǎng)萌芽的時代，那時數(shù)據(jù)的準(zhǔn)確、可靠是最重要的，而 NoSQL 誕生于互聯(lián)網(wǎng)快速發(fā)展普及的時代，大數(shù)據(jù)、分布式、擴展性成了數(shù)據(jù)庫的另一個重要特性。

總結(jié)一下：

RDB 首先得是準(zhǔn)確、可靠，然后才向更高的「可拓展性」發(fā)展；

而 NoSQL 生而分布式，可拓展性強，然后才向更高的「準(zhǔn)確性」發(fā)展。

NoSQL ，not only SQL，其實就是對那種打破了 RDB 嚴(yán)格事務(wù)和關(guān)系模型約束的那些數(shù)據(jù)庫的泛指，而隨著要解決的問題的不同，又誕生了各種各樣的 NoSQL。

首先是「列式數(shù)據(jù)庫」（Column-oriented DBMS），數(shù)據(jù)量上去了，我們想分析網(wǎng)站用戶的年齡分布，簡單說，就是你需要對同一個特征進(jìn)行大數(shù)據(jù)量的分析統(tǒng)計，于是把原來 RDB 的「按行存儲」的范式打破，變成了「按列存儲」，比如 HBase；

然后你發(fā)現(xiàn)有些數(shù)據(jù)變動不是很大，但是經(jīng)常需要被查詢， 查詢時還要關(guān)聯(lián)很多張表，于是你把這些來自不同表的數(shù)據(jù)，揉成一個大對象，按 key-value 的格式存起來，比如 Redis；

再后來你需要對博客內(nèi)容進(jìn)行相關(guān)性搜索，傳統(tǒng) RDB 不支持相關(guān)性搜索，最重要的，還是擴展性差，增加機器的帶來邊際效益有限，于是有了「全文搜索引擎」，比如 Elasticsearch；

除此之外，還有「文檔數(shù)據(jù)庫」、「圖形數(shù)據(jù)庫」……

沒有一種數(shù)據(jù)庫是銀彈。

總結(jié)

這篇文章的題目是「如何選擇數(shù)據(jù)庫」，這是困擾很多人的問題，那么多數(shù)據(jù)庫，到底要選什么好？

可是當(dāng)你問出這樣一個問題時，其實你是在問一種「手段」。我現(xiàn)在要做這樣一個需求，用什么數(shù)據(jù)庫可以幫我實現(xiàn)它？

但其實你需要的不只是一種「手段」，因為如果對方甩給你一個冷冰冰的名字，Mysql、Elasticsearch、MongoDB，你肯定會問，憑什么？

你需要的，是一種「解決方案」。如果你需要數(shù)據(jù)十分嚴(yán)格準(zhǔn)確，分毫不差，那我會推薦你采用「事務(wù)」和「關(guān)系模型」來處理數(shù)據(jù)；如果你需要數(shù)據(jù)能夠被大量讀取和寫入，那我會推薦你擴展性強的「分布式」；如果你的數(shù)據(jù)經(jīng)常是整個讀取、整個更新的，那「關(guān)系模型」就沒有「文檔模型」適合你。

「事務(wù)」、「關(guān)系模型」、「分布式」、「文檔模型」等等，這些就是「解決方案」，知道用什么「解決方案」，用哪個數(shù)據(jù)庫，自然水到渠成。

正如一位大牛說的：

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

用戶不會因為你用了 Mysql 或者 MongoDB 而使用你的軟件，畢竟絕大多數(shù)用戶都不知道 Mysql 和 MongoDB 是什么玩意。

不懂NOSQL這些知識，怎么吹牛B

剛剛出現(xiàn)NOSQL這個概念的時候，很多人都是似而非的字面理解成”不是SQL”， 與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫是兩個完全獨立的陣營，實際上完全不是這么回事。

個人更傾向于理解NOSQL的誕生更多的是為了補充關(guān)系型數(shù)據(jù)庫的短板，滿足現(xiàn)下互聯(lián)網(wǎng)海量數(shù)據(jù)、高并發(fā)、低延遲和非結(jié)構(gòu)化數(shù)據(jù)易擴展等需求。

分享文章：nosql誕生,nosql介紹
標(biāo)題來源：http://chinadenli.net/article35/dsipjpi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、手機網(wǎng)站建設(shè)、、商城網(wǎng)站、定制開發(fā)、網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)