服務端指南 數據存儲篇 | 選擇合適的數據存儲方案

在服務端會常常遇到數據存儲的選型問題，是選擇使用關係型數據庫 MySQL，仍是選擇內存數據庫 Redis，仍是選擇文檔數據庫 MongoDB，仍是選擇列族數據庫 HBase， 仍是選擇全文搜索引擎 ElasticSearch 呢？本節主要介紹如何選擇合適的數據存儲方案。

原文地址：服務端指南 數據存儲篇 | 選擇合適的數據存儲方案
博客地址：blog.720ui.com/

關係型數據庫 MySQL

MySQL 是一個最流行的關係型數據庫，在互聯網產品中應用比較普遍。通常狀況下，MySQL 數據庫是選擇的第一方案，基本上有 80% ~ 90% 的場景都是基於 MySQL 數據庫的。由於，須要關係型數據庫進行管理，此外，業務存在許多事務性的操做，須要保證事務的強一致性。同時，可能還存在一些複雜的 SQL 的查詢。值得注意的是，前期儘可能減小表的聯合查詢，便於後期數據量增大的狀況下，作數據庫的分庫分表。

內存數據庫 Redis

隨着數據量的增加，MySQL 已經知足不了大型互聯網類應用的需求。所以，Redis 基於內存存儲數據，能夠極大的提升查詢性能，對產品在架構上很好的補充。例如，爲了提升服務端接口的訪問速度，儘量將讀頻率高的熱點數據存放在 Redis 中。這個是很是典型的以空間換時間的策略，使用更多的內存換取 CPU 資源，經過增長系統的內存消耗，來加快程序的運行速度。

在某些場景下，能夠充分的利用 Redis 的特性，大大提升效率。這些場景包括緩存，會話緩存，時效性，訪問頻率，計數器，社交列表，記錄用戶斷定信息，交集、並集和差集，熱門列表與排行榜，最新動態等。

使用 Redis 作緩存的時候，須要考慮數據不一致與髒讀、緩存更新機制、緩存可用性、緩存服務降級、緩存穿透、緩存預熱等緩存使用問題。

文檔數據庫 MongoDB

MongoDB 是對傳統關係型數據庫的補充，它很是適合高伸縮性的場景，它是可擴展性的表結構。基於這點，能夠將預期範圍內，表結構可能會不斷擴展的 MySQL 表結構，經過 MongoDB 來存儲，這就能夠保證表結構的擴展性。

此外，日誌系統數據量特別大，若是用 MongoDB 數據庫存儲這些數據，利用分片集羣支持海量數據，同時使用匯集分析和 MapReduce 的能力，是個很好的選擇。

MongoDB 還適合存儲大尺寸的數據，GridFS 存儲方案就是基於 MongoDB 的分佈式文件存儲系統。

列族數據庫 HBase

HBase 適合海量數據的存儲與高性能實時查詢，它是運行於 HDFS 文件系統之上，而且做爲 MapReduce 分佈式處理的目標數據庫，以支撐離線分析型應用。在數據倉庫、數據集市、商業智能等領域發揮了愈來愈多的做用，在數以千計的企業中支撐着大量的大數據分析場景的應用。

全文搜索引擎 ElasticSearch

在通常狀況下，關係型數據庫的模糊查詢，都是經過 like 的方式進行查詢。其中，like "value%" 可使用索引，可是對於 like "%value%" 這樣的方式，執行全表查詢，這在數據量小的表，不存在性能問題，可是對於海量數據，全表掃描是很是可怕的事情。ElasticSearch 做爲一個創建在全文搜索引擎 Apache Lucene 基礎上的實時的分佈式搜索和分析引擎，適用於處理實時搜索應用場景。此外，使用 ElasticSearch 全文搜索引擎，還能夠支持多詞條查詢、匹配度與權重、自動聯想、拼寫糾錯等高級功能。所以，可使用 ElasticSearch 做爲關係型數據庫全文搜索的功能補充，將要進行全文搜索的數據緩存一份到 ElasticSearch 上，達處處理複雜的業務與提升查詢速度的目的。

ElasticSearch 不單單適用於搜索場景，還很是適合日誌處理與分析的場景。著名的 ELK 日誌處理方案，由 ElasticSearch、Logstash 和 Kibana 三個組件組成，包括了日誌收集、聚合、多維度查詢、可視化顯示等。

（完）

更多精彩文章，盡在「服務端思惟」微信公衆號！