在互聯(lián)網(wǎng)應(yīng)用中，數(shù)據(jù)爆發(fā)式的增長，實(shí)際上軟件架構(gòu)的本質(zhì)就是對數(shù)據(jù)的維護(hù)。對數(shù)據(jù)的操作可以歸納為三類:讀、寫和檢索。

隨著網(wǎng)站的流量越來越大，數(shù)據(jù)量也爆發(fā)式的增長，網(wǎng)站響應(yīng)越來越慢，服務(wù)器經(jīng)常宕機(jī)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)不能滿足流量和數(shù)據(jù)的爆發(fā)式增長。于是根據(jù)不同的業(yè)務(wù)需求，出現(xiàn)了很多不同的數(shù)據(jù)庫。

根據(jù)數(shù)據(jù)庫的類型劃分。有關(guān)系型數(shù)據(jù)庫:mysql,oracle,sqlserver,postgresql等。nosql數(shù)據(jù)庫:mongodb,hbase,cassandra,redis，CouchDB，Riak，Membase等。

根據(jù)數(shù)據(jù)庫的用途劃分。有緩存數(shù)據(jù)庫:redis,memcached,h2db等，日志數(shù)據(jù)庫:kahadb等。k-v型數(shù)據(jù)庫:leveldb,redis等。

檢索型存儲中間件有：elasticsearch、solr、Lucene等。

[[208342]]

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(RDBMS)是用途最廣泛也是用的最多的數(shù)據(jù)庫。關(guān)系型數(shù)據(jù)庫是強(qiáng)事物一致性(ACID)，使用比較早，技術(shù)相對成熟，查詢可以根據(jù)字段，以及表現(xiàn)各個(gè)數(shù)據(jù)對象之間的關(guān)系。在CAP理論中實(shí)現(xiàn)的是CA。沒有P分區(qū)性，單點(diǎn)瓶頸是硬傷。

當(dāng)關(guān)系型數(shù)據(jù)庫越來越成為瓶頸時(shí)，為解決單點(diǎn)瓶頸犧牲CAP屬性中的C，出現(xiàn)了nosql數(shù)據(jù)庫。針對某些特殊的使用場景，出現(xiàn)了非關(guān)系型數(shù)據(jù)庫。如:nosql，緩存等。以下針對不同的業(yè)務(wù)場景闡述各個(gè)數(shù)據(jù)庫的特性。

對于數(shù)據(jù)庫的選型，ACID是重要的考慮指標(biāo)，如果對ACID要求很高，應(yīng)該選擇關(guān)系型數(shù)據(jù)庫。其次部分對一致性要求不高的，寫并發(fā)非常大的可以考慮其他的nosql數(shù)據(jù)庫。但是有的業(yè)務(wù)并發(fā)非常高，對ACID要求也非常高，則對業(yè)務(wù)數(shù)據(jù)和數(shù)據(jù)庫進(jìn)行拆分。

以下對各種業(yè)務(wù)場景應(yīng)該如何優(yōu)化和存儲選型。

一、讀多寫少

在互聯(lián)網(wǎng)應(yīng)用中，對于一般的量級，免費(fèi)的關(guān)系型數(shù)據(jù)庫mysql、postgresql是***。支持事物，穩(wěn)定性和成熟度比較好。

當(dāng)訪問量越來越大，數(shù)據(jù)量還不是很大的時(shí)候。也就是寫不是瓶頸，而讀成為主要的瓶頸。一是增加從庫分擔(dān)讀的壓力，另一個(gè)是在數(shù)據(jù)庫和應(yīng)用系統(tǒng)之間加一層緩存memcache,redis。增加緩存之后，能抗住很多壓力，大大降低了數(shù)據(jù)庫的讀請求。

二、讀多寫多

高并發(fā)場景中，對數(shù)據(jù)庫的操作往往提現(xiàn)在高并發(fā)讀和高并發(fā)寫。當(dāng)讀和寫都成為瓶頸時(shí)，這時(shí)采用的方案有：

1)對數(shù)據(jù)庫進(jìn)行橫向和縱向擴(kuò)展。按業(yè)務(wù)劃分，把一個(gè)數(shù)據(jù)庫實(shí)例擴(kuò)展成多個(gè)實(shí)例。按數(shù)據(jù)分片，把單表大數(shù)據(jù)量，水平分片成多個(gè)小表。

2)使用內(nèi)存表負(fù)載壓力。常見的內(nèi)存表有：redis開啟aof功能。業(yè)務(wù)數(shù)據(jù)要持久化落盤。否則進(jìn)程一旦重啟，內(nèi)存數(shù)據(jù)就會丟失。

redis：是有硬盤存儲的內(nèi)存數(shù)據(jù)庫，可以支持Master-Slave復(fù)制，其可以提供并發(fā)量遠(yuǎn)高于關(guān)系型數(shù)據(jù)庫。支持的數(shù)據(jù)結(jié)構(gòu)：K-V，K-Sets，K-Queue，K-Hash?？蛇m用于高并發(fā)讀寫業(yè)務(wù)場景，但局限于其數(shù)據(jù)結(jié)構(gòu)，不能做復(fù)雜查詢，只能以Key鍵值為基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)操作。

memcachedb：是基于memcache添加了BerkeleyDB存儲機(jī)制和主輔復(fù)制而來。支持的數(shù)據(jù)結(jié)構(gòu)只要K-V結(jié)構(gòu)?？蛇m用于高并發(fā)讀寫業(yè)務(wù)場景，同樣只局限于其數(shù)據(jù)結(jié)構(gòu)，不能做復(fù)雜查詢，只能以Key鍵值為基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)操作。

MongoDB：支持Master-Salve復(fù)制，無schema，json結(jié)構(gòu)。字段可以任意擴(kuò)展，可以建立字段索引和全字段索引?？梢詫θ我庾侄谓⑺饕樵儭?shù)據(jù)量越來越大時(shí)，是吃內(nèi)存的大戶，數(shù)據(jù)一致性問題會越來越嚴(yán)重。如果對數(shù)據(jù)一致性要求不高的讀多寫多業(yè)務(wù)，可以考慮使用此數(shù)據(jù)庫存儲。

三、讀少寫多

海量數(shù)據(jù)的寫入。如貨車app中的gps路線軌跡數(shù)據(jù)，每天的寫入庫的數(shù)據(jù)量上億條。如此巨大的寫入量用關(guān)系型數(shù)據(jù)庫顯然是不合適的。關(guān)系型數(shù)據(jù)庫雖然可以采用批量導(dǎo)入的方式增強(qiáng)寫入能力，但其強(qiáng)制落盤，對磁盤IO是影響主要因素。cassandra和habase其先寫內(nèi)存，異步落盤機(jī)制對磁盤IO消耗更低。

Cassandra：java開發(fā)，結(jié)構(gòu)簡單。其數(shù)據(jù)采用分片機(jī)制，副本備份與容錯復(fù)制。面向列式存儲。內(nèi)存寫入與異步刷盤的機(jī)制，使其在寫操作遠(yuǎn)高于讀操作場景中，也能輕松應(yīng)對。

HBASE：支持?jǐn)?shù)十億行，數(shù)百萬列。對于海量數(shù)據(jù)的寬表，面向列式存儲，無schema，可任意擴(kuò)展列。

四、讀少寫少

在小系統(tǒng)，業(yè)務(wù)量低、數(shù)據(jù)量少的系統(tǒng)，對讀寫操作都比較少，當(dāng)然是怎么快就怎么來。選用mysql免費(fèi)數(shù)據(jù)庫是最合適的選擇。

五、復(fù)雜條件檢索

關(guān)系型數(shù)據(jù)庫通常使用b+tree索引，非關(guān)系型數(shù)據(jù)庫如cassandra使用LSM結(jié)構(gòu)索引。所有的索引多列復(fù)雜條件查詢的檢索效率遠(yuǎn)遠(yuǎn)低于索引引擎。

常用開源的搜索引擎有l(wèi)uence,solr,elasticsearch，sphinx等。

solr：查詢快，但是更新索引速度偏慢。主要應(yīng)用于那種對數(shù)據(jù)的實(shí)時(shí)性要求不高的業(yè)務(wù)。

elasticserach：更新速度比solr快，但是查詢速度相對solr較慢。主要應(yīng)用于實(shí)時(shí)索引查詢的業(yè)務(wù)。

總結(jié)：

1)對ACID有強(qiáng)要求業(yè)務(wù)一般使用的數(shù)據(jù)存儲采用關(guān)系型數(shù)據(jù)庫，如mysql，postgresql、oracle、sql server等。

2)讀多寫少的場景，使用非關(guān)系型數(shù)據(jù)庫Cassandra、hbase、MongoDB等。

3)緩解高并發(fā)讀對數(shù)據(jù)庫造成的讀瓶頸，使用緩存：memcached、redis等。

4)復(fù)雜的數(shù)據(jù)檢索，使用外置索引：elasticsearch、solr等。