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

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

根據(jù)數(shù)據(jù)庫的類型劃分。有關系型數(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)的關系型數(shù)據(jù)庫(RDBMS)是用途最廣泛也是用的最多的數(shù)據(jù)庫。關系型數(shù)據(jù)庫是強事物一致性(ACID)，使用比較早，技術相對成熟，查詢可以根據(jù)字段，以及表現(xiàn)各個數(shù)據(jù)對象之間的關系。在CAP理論中實現(xiàn)的是CA。沒有P分區(qū)性，單點瓶頸是硬傷。

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

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

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

一、讀多寫少

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

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

二、讀多寫多

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

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

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

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

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

MongoDB：支持Master-Salve復制，無schema，json結構。字段可以任意擴展，可以建立字段索引和全字段索引。可以對任意字段建立索引查詢。數(shù)據(jù)量越來越大時，是吃內(nèi)存的大戶，數(shù)據(jù)一致性問題會越來越嚴重。如果對數(shù)據(jù)一致性要求不高的讀多寫多業(yè)務，可以考慮使用此數(shù)據(jù)庫存儲。

三、讀少寫多

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

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

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

四、讀少寫少

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

五、復雜條件檢索

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

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

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

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

總結：

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

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

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

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