隨著云計算、大數(shù)據(jù)、物聯(lián)網(wǎng)時代的到來，越來越多的網(wǎng)民涌入互聯(lián)網(wǎng)，越來越多的應(yīng)用系統(tǒng)需要支撐海量數(shù)據(jù)存儲，還需要隨著業(yè)務(wù)需求滿足高并發(fā)、高可靠、高擴展性等要求，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)不能完全滿足需求了，因此NoSQL應(yīng)運而生。

那么SQL是什么？、NoSQL又是什么？業(yè)務(wù)系統(tǒng)如何數(shù)據(jù)庫技術(shù)選型呢？

NoSQL!= NO SQL，而是NotOnlySQL,作為關(guān)系型數(shù)據(jù)庫的補充而出現(xiàn)。關(guān)系型數(shù)據(jù)庫即采用了關(guān)系模型來組織的數(shù)據(jù)庫，簡單來說，就是二維表格模型，包含關(guān)系（表名）、元組（二維表中的一行）、屬性（二維表中的一列）、域（屬性的取值范圍）、關(guān)鍵字（唯一能標識元組的屬性）、關(guān)系模式（表結(jié)構(gòu)，對關(guān)系的描述）等概念。以一個用戶信息表來說，用戶信息表就是整個關(guān)系，元組就是姓名、性別、年齡、電話、地域組成的一行記錄，屬性則是單獨的地域列、年齡列等，域就是地域是中國全省市等，關(guān)鍵字就是用戶ID、能唯一標識這個用戶，關(guān)系模式就是這整個表，包含姓名、性別、年齡、電話、地域?qū)傩浴?/p>

對于關(guān)系型數(shù)據(jù)庫來說，一直非常流行的原因有如下四個：1、強事務(wù)一致性，數(shù)據(jù)庫的ACID（原子性、一致性、隔離性、持久性）保障了所有記錄的數(shù)據(jù)全是準確的，對于早期互聯(lián)網(wǎng)來說，大家都不完全信任看不到摸不著的東西，所以這個特點非常重要；

2、容易理解，二維表的結(jié)構(gòu)非常貼合現(xiàn)實世界。

3、使用方便，通用的sql語言使得操作關(guān)系型數(shù)據(jù)庫非常方便；

4、容易維護，在設(shè)計的時候采用了實體完整性、參照完整性等理念，減少了數(shù)據(jù)冗余和數(shù)據(jù)不一致。常用的關(guān)系型數(shù)據(jù)庫有Mysql、Oracle等。

然而隨著互聯(lián)網(wǎng)海量數(shù)據(jù)的增加，關(guān)系型數(shù)據(jù)庫也產(chǎn)生了瓶頸，具體表現(xiàn)如下：

1、無法應(yīng)對高并發(fā)的讀寫請求，關(guān)系型數(shù)據(jù)庫是以行結(jié)構(gòu)來存儲的，比如我們想獲取某個地域的用戶名單，需要按行讀取，再獲取其中的用戶名字這一屬性，對于磁盤的IO消耗非常大；

2、無法彈性伸縮，關(guān)系型數(shù)據(jù)庫無法像webserver那樣簡單的通過增加更多的硬件和服務(wù)節(jié)點來擴展性能，對于數(shù)據(jù)庫海量劇增的今天、服務(wù)需要24小時提供的企業(yè)來說，這非常難受；

3、不再需要事務(wù)強一致性、讀寫實時性，早期這是關(guān)系型數(shù)據(jù)庫的優(yōu)點，而隨著互聯(lián)網(wǎng)業(yè)務(wù)覆蓋范圍的廣泛，用戶可以接受一定的延遲、一定的錯誤。

因此NoSQL關(guān)系型數(shù)據(jù)庫出現(xiàn)了，作為關(guān)系型數(shù)據(jù)庫的補充，再根據(jù)互聯(lián)網(wǎng)時代的需求不同，可以分為：

1、支持高性能并發(fā)讀寫的Key-Value數(shù)據(jù)庫，如Redis；

2、支持海量數(shù)據(jù)訪問的文檔數(shù)據(jù)庫，如MongoDB、CouchDB；

3、支持大數(shù)據(jù)存儲和分析的列式數(shù)據(jù)庫，如HBase；

4、支持全文搜索的搜索引擎數(shù)據(jù)庫，如ElasticSearch。

數(shù)據(jù)庫的使用根據(jù)具體的業(yè)務(wù)場景而確定，毫無疑問，涉及交易場景，關(guān)系型數(shù)據(jù)庫是必不可失的，因為我們要求數(shù)據(jù)必須一致，不能允許任何的差錯出現(xiàn)。在大部分互聯(lián)網(wǎng)企業(yè)中，一般是SQL與NoSQL配合使用。現(xiàn)以某高速發(fā)展的電商網(wǎng)站來聊聊如何技術(shù)選型？

從業(yè)務(wù)類型來看，電商具備用戶量&訂單量高速增長、網(wǎng)站延遲低、對部分數(shù)據(jù)準確性要求高的特點，因此需要數(shù)據(jù)庫能支持高讀寫的并發(fā)量、低延遲高吞吐、安全穩(wěn)定、高可用的特點。從數(shù)據(jù)類型來看，包含用戶個人信息數(shù)據(jù)、商品信息數(shù)據(jù)、交易數(shù)據(jù)三類，對于交易數(shù)據(jù)需要保證不能出錯，而其它類數(shù)據(jù)則要求能存儲不出錯。從數(shù)據(jù)驅(qū)動運營的角度來看，未來會利用用戶在平臺產(chǎn)生的所有數(shù)據(jù)進行數(shù)據(jù)分析、智能推薦、二次營銷等。綜上所述，我們選擇的數(shù)據(jù)庫是MySQL與MongoDB。

選擇MySQL毫無疑問是為了保證業(yè)務(wù)核心數(shù)據(jù)如用戶信息、交易數(shù)據(jù)等不能出錯，這是關(guān)系型數(shù)據(jù)庫的最大優(yōu)勢。選擇MongoDB則是因為其高可用、文檔模型的特點。關(guān)于高可用，首先MongoDB的架構(gòu)是primary、secondary模式，一個主節(jié)點接受server的讀寫，兩個從節(jié)點同步primary主節(jié)點的數(shù)據(jù)，當主節(jié)點發(fā)生故障時，從節(jié)點進行選舉，產(chǎn)生新的主節(jié)點，從而保障了業(yè)務(wù)的高可用。

其次MongoDB支持數(shù)據(jù)分片，當業(yè)務(wù)量急速擴展時，原先部署數(shù)據(jù)庫的五臺服務(wù)器就不夠了，現(xiàn)在需要增加服務(wù)器節(jié)點數(shù)，對于Mysql來說，采用分庫分表就可以解決問題，對于MongoDB則是通過將一個集合上的數(shù)據(jù)按片鍵分到不同的分片上，減少同一個數(shù)據(jù)文件上的數(shù)據(jù)量，再通過配置文件將數(shù)據(jù)引向不同的分片即可。

最后MongoDB支持文檔模型，可以根據(jù)業(yè)務(wù)數(shù)據(jù)類型的變化來去增加或刪減字段，而不需要按照確定的表結(jié)構(gòu)去增加刪除。比如在Mysql中，當一個用戶填寫了家里的收貨地址、公司收貨地址、朋友收貨地址等多個地址時，需要建立聯(lián)系人表、地址表將其關(guān)聯(lián)，而在MongoDB中只需要一個集合就可以搞定了。

在數(shù)據(jù)庫選型我們都需要考慮數(shù)據(jù)量、并發(fā)量、實時性、一致性、讀寫分布、數(shù)據(jù)類型、安全性、運維成本都指標，常見的系統(tǒng)數(shù)據(jù)庫選型如下所示：

現(xiàn)在假設(shè)你在主導(dǎo)或參與一個系統(tǒng)的開發(fā)，相信你已經(jīng)非常清楚如何選型數(shù)據(jù)庫、如何應(yīng)對后續(xù)出現(xiàn)的問題了吧？知其然知其所以然～