在互聯網應用中，數據爆發式的增長，實際上軟件架構的本質就是對數據的維護。對數據的操作可以歸納為三類:讀、寫和檢索。

隨著網站的流量越來越大，數據量也爆發式的增長，網站響應越來越慢，服務器經常宕機。傳統的關系型數據庫已經不能滿足流量和數據的爆發式增長。于是根據不同的業務需求，出現了很多不同的數據庫。

根據數據庫的類型劃分。有關系型數據庫:mysql,oracle,sqlserver,postgresql等。nosql數據庫:mongodb,hbase,cassandra,redis，CouchDB，Riak，Membase等。

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

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

[[208342]]

傳統的關系型數據庫(RDBMS)是用途最廣泛也是用的最多的數據庫。關系型數據庫是強事物一致性(ACID)，使用比較早，技術相對成熟，查詢可以根據字段，以及表現各個數據對象之間的關系。在CAP理論中實現的是CA。沒有P分區性，單點瓶頸是硬傷。

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

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

以下對各種業務場景應該如何優化和存儲選型。

一、讀多寫少

在互聯網應用中，對于一般的量級，免費的關系型數據庫mysql、postgresql是***。支持事物，穩定性和成熟度比較好。

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

二、讀多寫多

高并發場景中，對數據庫的操作往往提現在高并發讀和高并發寫。當讀和寫都成為瓶頸時，這時采用的方案有：

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

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

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

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

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

三、讀少寫多

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

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

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

四、讀少寫少

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

五、復雜條件檢索

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

常用開源的搜索引擎有luence,solr,elasticsearch，sphinx等。

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

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

總結：

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

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

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

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