在服務端會經常遇到資料儲存的選型問題，是選擇使用關係型資料庫 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 三個元件組成，包括了日誌收集、聚合、多維度查詢、視覺化顯示等。
（完）
更多精彩文章，盡在「服務端思維」微信公眾號！