redis和Elasticsearch比較
| 項目 | Redis | Elasticsearch |
|---|---|---|
| 介紹 | Redis是內存中的數據結構存儲，用作數據庫，緩存和消息代理 | Elasticsearch是一個基於Apache Lucene的現代搜索和分析引擎 |
| 主數據庫模型 | 鍵值存儲 | 搜索引擎 |
| DB-Engines排名 | 得分120.41總排名第9，key－value存儲排名第7 | 得分120.00總排名第10，搜索引擎排名第1 |
| 網站 | redis.io | www.elastic.co/cn/elasticsearch |
| 技術文檔 | redis.io/documentation | www.elastic.co/cn/elasticsearch/features |
| 由開發 | Salvatore Sanfilippo | 彈 |
| 初始發行 | 2009 | 2010 |
| 當前版本 | 5.0.8，2020年3月 | 7.6.1，2020年3月 |
| 許可證信息 | 開源 | 開源 |
| 基於雲的信息 | 沒有 | 沒有 |
| 實現語言 | C | Java |
| 支持的操作系統 | BSD Linux OS X Windows | 所有帶有Java VM的操作系統 |
| 數據scheme | 無scheme | 無scheme |
| 打字 | 局部 | 是 |
| XML支持 | 沒有 | |
| 二級索引 | 沒有 | 是 |
| SQL | 沒有 | 沒有 |
| API和其他訪問方法 | 專有協議 | Java API RESTful HTTP / JSON API |
| 支持的編程語言 | C C＃C ++ Clojure Crystal D Dart Elixir Erlang Fancy Go Haskell Haxe Java JavaScript（Node.js）Lisp Lua MatLab Objective-C OCaml Perl PHP Prolog Python R Rebol Ruby Rust Scala Smalltalk Tcl | .Net Clojure Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala |
| 服務器端腳本 | Lua | 是 |
| 觸發器 | 沒有 | 是 |
| 分區方法 | 拆分 | 拆分 |
| 複製方法 | 主從複製 | 是 |
| MapReduce的 | 沒有 | 沒有 |
| 一致性概念 | 最終的一致性 | 最終的一致性 |
| 外鍵 | 沒有 | 沒有 |
應用場景
elasticsearch、redis的應用場景是怎樣的？
ElasticSearch
ES場景
分佈式的搜索引擎和數據分析引擎，全文檢索，結構化檢索，數據分析
對海量數據進行近實時的處理，站內搜索（電商，招聘，門戶，等等）， IT 系統搜索（ OA ， CRM ， ERP ，等等），數據分析ES不是一個數據庫，而是一個搜索引擎，ES的方方面面也都是圍繞搜索設計的。ES支持全文搜索，這裏簡單解釋下什麼是全文搜索：對於“我在北京的一家互聯網公司工作”這樣的數據，如果你搜索“北京”、“互聯網”、“工作”這些關鍵詞都能命中這條數據的話，這就是全文搜索，你每天都在用的百度、Google都屬於全文搜索。值得一提的是，ES的全文搜索對中文也有很好的支持（單是中文分詞器就有很多種），絕對能夠滿足國內大多數人的全文搜索需求。除了搜索之外，ES還會自動的替你對所有字段建立索引，以實現高性能的複雜聚合查詢，因此只要是存入ES的數據，無論再複雜的聚合查詢也可以得到不錯的性能，而且你再也不用爲如何建立各種複雜索引而頭痛了。
ES也有很多的短處，最明顯的就是字段類型無法修改、寫入性能較低 和 高硬件資源消耗。 前邊講到ES會自動的替你建立索引，儘管這能給全文搜索以及聚合查詢帶來很多好處還能替你省了建索引這一麻煩事，但是這個特性也會帶來一堆問題。ES需要在創建字段前要預先建立Mapping，Mapping中包含每個字段的類型信息，ES需要根據Mapping爲字段建立合適的索引。由於這個Mapping的存在，ES中的字段一但建立就不能再修改類型了。（例如，你建的數據表的某個字段忘了加全文搜索，你想臨時加上，但是表已經建好並且已經有很多數據了，這時候該怎麼辦呢？不好意思，你只能把整個數據表刪了再重建一遍！！！） 自動建立索引使得ES的寫入性能也收到了影響，明顯低於MongoDB。對於同樣的數據ES佔用存儲空間也要明顯大於MongoDB（建那麼多索引能不佔空間嗎？），對硬件資源的消耗也是非常厲害，大數據量下64G內存+SSD基本是標配，算得上是數據庫中的貴族服務了，因此如果你的老闆很小氣，對於ES的選用可要慎重嘍！
redis
redis場景
常規計數：粉絲數，微博數；用戶信息變更；緩存處理，作爲 mysql 的緩存；隊列系統，建有優先級的隊列系統，日誌收集系統Redis是現在最熱門的key-value數據庫。它與MongoDB同在2009年發佈，也同樣是早期大數據時代的數據庫代表作。
Redis的最大特點當然就是key-value存儲所帶來的簡單和高性能了。 所謂key-value存儲，就是每一條記錄只包含一個用於查詢數據的Key，以及與之對應的存儲數據的value，就如同現實生活中的門牌號與住戶，而沒有諸如表、字段這些常規數據庫中必需有的複雜概念，所有的查詢都僅僅依賴於key值。因此，key-value數據庫可謂是數據庫中數據結構最簡單的一種，也得益於這種簡單的結構，再加上Redis會把所有數據加載到內存中的，Redis能得到遠高於MongoDB這類常規數據庫的讀寫性能。當然，Redis的功能還不止key-value存儲這麼簡單，相較它的key-value前輩Memcached，Redis還支持數據持久化，list、set等多種數據結構，主從複製備份等一些列功能，因此Redis絕對稱得上是key-value數據庫中功能最全面、最簡單易用的款。
Redis的key-valule存儲帶來了性能這個優勢，但是也給複雜查詢帶來了很多侷限。 由於閹割掉了數據表、字段這樣的重要特性，且所有的查詢都依賴key，因此Redis無法提供常規數據庫所具備的多列查詢、區段查詢等複雜查詢功能。同時，由於Redis需要把數據存在內存中，這也大大限制了Redis可存儲的數據量，這也決定了Redis難以用在數據規模很大的應用場景中。
Redis犧牲了常規數據庫中的數據表、複雜查詢等功能，換來了很大的性能提升，特別適合那些對讀寫性能要求極高，且數據表結構簡單（key-value、list、set之類）、查詢條件也同樣簡單的應用場景。如果你的數據表結構還挺複雜，你還經常需要做一些複雜查詢操作，那你最好還是老老實實用MongoDB或者SQL吧。
總結
如果你對數據的讀寫要求極高，並且你的數據規模不大，也不需要長期存儲，選redis；
如果你的數據規模較大，對數據的讀性能要求很高，數據表的結構需要經常變，有時還需要做一些聚合查詢，選MongoDB；
如果你需要構造一個搜索引擎或者你想搞一個看着高大上的數據可視化平臺，並且你的數據有一定的分析價值或者你的老闆是土豪，選ElasticSearch；
如果你需要存儲海量數據，連你自己都不知道你的數據規模將來會增長多麼大，那麼選HBase。