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

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

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

對于關(guān)系型數(shù)據(jù)庫來說，一直非常流行的原因有如下四個(gè)：

1. 強(qiáng)事務(wù)一致性，數(shù)據(jù)庫的ACID(原子性、一致性、隔離性、持久性)保障了所有記錄的數(shù)據(jù)全是準(zhǔn)確的，對于早期互聯(lián)網(wǎng)來說，大家都不完全信任看不到摸不著的東西，所以這個(gè)特點(diǎn)非常重要;
2. 容易理解，二維表的結(jié)構(gòu)非常貼合現(xiàn)實(shí)世界。
3. 使用方便，通用的sql語言使得操作關(guān)系型數(shù)據(jù)庫非常方便;
4. 容易維護(hù)，在設(shè)計(jì)的時(shí)候采用了實(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)如下：

• 無法應(yīng)對高并發(fā)的讀寫請求，關(guān)系型數(shù)據(jù)庫是以行結(jié)構(gòu)來存儲的，比如我們想獲取某個(gè)地域的用戶名單，需要按行讀取，再獲取其中的用戶名字這一屬性，對于磁盤的IO消耗非常大;
• 無法彈性伸縮，關(guān)系型數(shù)據(jù)庫無法像webserver那樣簡單的通過增加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能，對于數(shù)據(jù)庫海量劇增的今天、服務(wù)需要24小時(shí)提供的企業(yè)來說，這非常難受;
• 不再需要事務(wù)強(qiáng)一致性、讀寫實(shí)時(shí)性，早期這是關(guān)系型數(shù)據(jù)庫的優(yōu)點(diǎn)，而隨著互聯(lián)網(wǎng)業(yè)務(wù)覆蓋范圍的廣泛，用戶可以接受一定的延遲、一定的錯(cuò)誤。

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

• 支持高性能并發(fā)讀寫的Key-Value數(shù)據(jù)庫，如Redis;
• 支持海量數(shù)據(jù)訪問的文檔數(shù)據(jù)庫，如MongoDB、CouchDB;
• 支持大數(shù)據(jù)存儲和分析的列式數(shù)據(jù)庫，如HBase;
• 支持全文搜索的搜索引擎數(shù)據(jù)庫，如ElasticSearch。

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

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

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

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

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

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

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