一、ES具有哪些优势
存储
ElasticSearch天然支持分布式，具备存储海量数据的能力，其搜索和数据分析的功能都建立在ElasticSearch存储的海量的数据之上；ElasticSearch很方便的作为海量数据的存储工具，特别是在数据量急剧增长的当下，ElasticSearch结合爬虫等数据收集工具可以发挥很大用处。
搜索
ElasticSearch使用倒排索引，每个字段都被索引且可用于搜索，更是提供了丰富的搜索api，在海量数据下近实时实现近秒级的响应,基于Lucene的开源搜索引擎，为搜索引擎（全文检索，高亮，搜索推荐等）提供了检索的能力。
数据分析
ElasticSearch也提供了大量数据分析的api和丰富的聚合能力，支持在海量数据的基础上进行数据的分析和处理。具体场景：
爬虫爬取不同电商平台的某个商品的数据，通过ElasticSearch进行数据分析（各个平台的历史价格、购买力等等）
二、ElasticSearch架构
- Gateway是ES用来存储索引的文件系统，支持多种类型。
- Gateway的上层是一个分布式的lucene框架。
- Lucene之上是ES的模块，包括：索引模块、搜索模块、映射解析模块等
- ES模块之上是 Discovery、Scripting和第三方插件。Discovery是ES的节点发现模块，不同机器上的ES节点要组成集群需要进行消息通信，集群内部需要选举master节点，这些工作都是由Discovery模块完成。支持多种发现机制，如 Zen 、EC2、gce、Azure。Scripting用来支持在查询语句中插入javascript、python等脚本语言，scripting模块负责解析这些脚本，使用脚本语句性能稍低。ES也支持多种第三方插件。
- 再上层是ES的传输模块和JMX.传输模块支持多种传输协议，如 Thrift、memecached、http，默认使用http。JMX是java的管理框架，用来管理ES应用。
- 最上层是ES提供给用户的接口，可以通过RESTful接口和ES集群进行交互。
三、ElasticSearch核心概念
- Cluster集群：一个集群由一个唯一的名字标识，默认为“elasticsearch”。
- Node 节点：存储集群的数据，参与集群的索引和搜索功能。
- Shard 分片：在创建一个索引时可以指定分成多少个分片来存储
- Index 索引: 一个索引是一个文档的集合（等同于solr中的集合）。
- Document 文档：被索引的一条数据，索引的基本信息单元，以JSON格式来表示。（就是数据）
- type类型：在一个索引中，你可以定义一种或多种类型。（本身就是个鸡肋，实际很少用到，6x后取消该概念，所以可以忽略）。
- mapping：映射像关系数据库中的表结构，每一个索引都有一个映射，它定义了索引中的每一个字段类型，以及一个索引范围内的设置。一个映射可以事先被定义，或者在第一次存储文档的时候自动识别。
- field：一个文档中包含零个或者多个字段，字段可以是一个简单的值（例如字符串、整数、日期），也可以是一个数组或对象的嵌套结构。字段类似于关系数据库中的表中的列。每个字段都对应一个字段类型，例如整数、字符串、对象等。字段还可以指定如何分析该字段的值。
对比RDBMS
四、mapping全面讲解
Mapping简介#
mapping 是用来定义文档及其字段的存储方式、索引方式的手段，例如利用mapping 来定义以下内容：
- 哪些字段需要被定义为全文检索类型
- 哪些字段包含number、date类型等
- 格式化时间格式
- 自定义规则，用于控制动态添加字段的映射
Mapping Type#
每个索引都拥有唯一的 mapping type，用来决定文档将如何被索引。mapping type由下面两部分组成
Meta-fields
元字段用于自定义如何处理文档的相关元数据。 元字段的示例包括文档的_index，_type，_id和_source字段。
Fields or properties
映射类型包含与文档相关的字段或属性的列表。
分词器最佳实践#
因为后续的keyword和text设计分词问题，这里给出分词最佳实践。即索引时用ik_max_word，搜索时分词器用ik_smart，这样索引时最大化的将内容分词，搜索时更精确的搜索到想要的结果。
例如我想搜索的是小米手机，我此时的想法是想搜索出小米手机的商品，而不是小米音响、小米洗衣机等其他产品，也就是说商品信息中必须只有小米手机这个词。
我们后续会使用"search_analyzer": "ik_smart"来实现这样的需求。
字段类型
- 一种简单的数据类型，例如text、keyword、double、boolean、long、date、ip类型。
- 也可以是一种分层的json对象（支持属性嵌套）。
- 也可以是一些不常用的特殊类型，例如geo_point、geo_shape、completion
针对同一字段支持多种字段类型可以更好地满足我们的搜索需求，例如一个string类型的字段可以设置为text来支持全文检索，与此同时也可以让这个字段拥有keyword类型来做排序和聚合，另外我们也可以为字段单独配置分词方式，例如"analyzer": "ik_max_word"。
text 类型
text类型的字段用来做全文检索，例如邮件的主题、淘宝京东中商品的描述等。这种字段在被索引存储前先进行分词，存储的是分词后的结果，而不是完整的字段。text字段不适合做排序和聚合。如果是一些结构化字段，分词后无意义的字段建议使用keyword类型，例如邮箱地址、主机名、商品标签等。
有参数包含以下:
| analyzer | 用来分词，包含索引存储阶段和搜索阶段（其中查询阶段可以被search_analyzer参数覆盖），该参数默认设置为index的analyzer设置或者standard analyzer |
| fields | Multi-fields允许同一个字符串值同时被不同的方式索引，例如用不同的analyzer使一个field用来排序和聚类，另一个同样的string用来分析和全文检索。下面会做详细的说明 |
| search_analyzer | 这个字段用来指定搜索阶段时使用的分词器，默认使用analyzer的设置 |
| search_quote_analyzer | 搜索遇到短语时使用的分词器，默认使用search_analyzer的设置 |
keyword 类型
keyword用于索引结构化内容（例如电子邮件地址，主机名，状态代码，邮政编码或标签）的字段，这些字段被拆分后不具有意义，所以在es中应索引完整的字段，而不是分词后的结果。
通常用于过滤（例如在博客中根据发布状态来查询所有已发布文章），排序和聚合。keyword只能按照字段精确搜索，例如根据文章id查询文章详情。如果想根据本字段进行全文检索相关词汇，可以使用text类型。
有参数包含以下:
| index | 是否可以被搜索到。默认是true |
| fields | Multi-fields允许同一个字符串值同时被不同的方式索引，例如用不同的analyzer使一个field用来排序和聚类，另一个同样的string用来分析和全文检索。下面会做详细的说明 |
| null_value | 如果该字段为空，设置的默认值，默认为null |
| ignore_above | 设置索引字段大小的阈值。该字段不会索引大小超过该属性设置的值，默认为2147483647，代表着可以接收任意大小的值。但是这一值可以被PUT Mapping Api中新设置的ignore_above来覆盖这一值。 |
date类型
支持排序，且可以通过format字段对时间格式进行格式化。
json中没有时间类型，所以在es在规定可以是以下的形式：
一段格式化的字符串，例如"2015-01-01"或者"2015/01/01 12:10:30"
一段long类型的数字，指距某个时间的毫秒数，例如1420070400001
一段integer类型的数字，指距某个时间的秒数
object类型
mapping中不用特意指定field为object类型，因为这是它的默认类型。
json类型天生具有层级的概念，文档内部还可以包含object类型进行嵌套。例如：
PUT my_index/_doc/1
{
"region": "US",
"manager": {
"age": 30,
"name": {
"first": "John",
"last": "Smith"
}
}
}在es中上述对象会被按照以下的形式进行索引：
{
"region": "US",
"manager.age": 30,
"manager.name.first": "John",
"manager.name.last": "Smith"
}mapping可以对不同字段进行不同的设置：
PUT my_index
{
"mappings": {
"properties": {
"region": {
"type": "keyword"
},
"manager": {
"properties": {
"age": { "type": "integer" },
"name": {
"properties": {
"first": { "type": "text" },
"last": { "type": "text" }
}
}
}
}
}
}
}nest类型
nest类型是一种特殊的object类型，它允许object可以以数组形式被索引，而且数组中的某一项都可以被独立检索。
而且es中没有内部类的概念，而是通过简单的列表来实现nest效果，例如下列结构的文档：
PUT my_index/_doc/1
{
"group" : "fans",
"user" : [
{
"first" : "John",
"last" : "Smith"
},
{
"first" : "Alice",
"last" : "White"
}
]
}上面格式的对象会被按照下列格式进行索引，因此会发现一个user中的两个属性值不再匹配，alice和white失去了联系
{
"group" : "fans",
"user.first" : [ "alice", "john" ],
"user.last" : [ "smith", "white" ]
}range类型
支持以下范围类型：
| integer_range | -2的31次 到 2的31次-1. |
| float_range | 32位单精度浮点数 |
| long_range | -2的63次 到 2的63次-1. |
| double_range | 64位双精度浮点数 |
| date_range | unsigned 64-bit integer milliseconds |
| ip_range | ipv4和ipv6或者两者的混合 |
使用范例为：
PUT range_index
{
"settings": {
"number_of_shards": 2
},
"mappings": {
"properties": {
"age_range": {
"type": "integer_range"
},
"time_frame": {
"type": "date_range",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
}
}
}
PUT range_index/_doc/1?refresh
{
"age_range" : {
"gte" : 10,
"lte" : 20
},
"time_frame" : {
"gte" : "2015-10-31 12:00:00",
"lte" : "2015-11-01"
}
}实战：同时使用keyword和text类型
注：term是查询时对关键字不分词，keyword是索引时不分词
上述我们讲解过keyword和text一个不分词索引，一个是分词后索引，我们利用他们的fields属性来让当前字段同时具备keyword和text类型。
首先我们创建索引并指定mapping，为title同时设置keyword和text属性
PUT /idx_item/
{
"settings": {
"index": {
"number_of_shards" : "2",
"number_of_replicas" : "0"
}
},
"mappings": {
"properties": {
"itemId" : {
"type": "keyword",
"ignore_above": 64
},
"title" : {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"fields": {
"keyword" : {"ignore_above" : 256, "type" : "keyword"}
}
},
"desc" : {"type": "text", "analyzer": "ik_max_word"},
"num" : {"type": "integer"},
"price" : {"type": "long"}
}
}
}实战：格式化时间、以及按照时间排序
我们创建索引idx_pro，将mytimestamp和createTime字段分别格式化成两种时间格式
PUT /idx_pro/
{
"settings": {
"index": {
"number_of_shards" : "2",
"number_of_replicas" : "0"
}
},
"mappings": {
"properties": {
"proId" : {
"type": "keyword",
"ignore_above": 64
},
"name" : {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"fields": {
"keyword" : {"ignore_above" : 256, "type" : "keyword"}
}
},
"mytimestamp" : {
"type": "date",
"format": "epoch_millis"
},
"createTime" : {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss"
}
}
}
}四、ElasticSearch 常用的查询过滤语句
查询与过滤的区别？
查询会计算文档匹配程度的_score，过滤则不会，所以过滤效率会更高
Filter DSL
term 过滤
term主要用于精确匹配哪些值，比如数字，日期，布尔值或 not_analyzed 的字符串(未经分析的文本数据类型)：
{ "term": { "age": 26 }}
{ "term": { "date": "2014-09-01" }}
{ "term": { "public": true }}
{ "term": { "tag": "full_text" }}完整的例子， hostname 字段完全匹配成 saaap.wangpos.com 的数据：
{
"query": {
"term": {
"hostname": "saaap.wangpos.com"
}
}
}terms 过滤
terms 跟 term 有点类似，但 terms 允许指定多个匹配条件。 如果某个字段指定了多个值，那么文档需要一起去做匹配：
{
"terms": {
"tag": [ "search", "full_text", "nosql" ]
}
}完整的例子，所有http的状态是 302 、304 的， 由于ES中状态是数字类型的字段，所有这里我们可以直接这么写。：
{
"query": {
"terms": {
"status": [
304,
302
]
}
}
}range 过滤
range过滤允许我们按照指定范围查找一批数据：
{
"range": {
"age": {
"gte": 20,
"lt": 30
}
}
}范围操作符包含：
- gt :: 大于
- gte:: 大于等于
- lt :: 小于
- lte:: 小于等于
一个完整的例子， 请求页面耗时大于1秒的数据，upstream_response_time 是 nginx 日志中的耗时，ES中是数字类型。
{
"query": {
"range": {
"upstream_response_time": {
"gt": 1
}
}
}
}exists 和 missing 过滤
exists 和 missing 过滤可以用于查找文档中是否包含指定字段或没有某个字段，类似于SQL语句中的IS_NULL条件.
{
"exists": {
"field": "title"
}
}这两个过滤只是针对已经查出一批数据来，但是想区分出某个字段是否存在的时候使用。
bool 过滤
bool 过滤可以用来合并多个过滤条件查询结果的布尔逻辑，它包含一下操作符：
- must :: 多个查询条件的完全匹配,相当于 and。
- must_not :: 多个查询条件的相反匹配，相当于 not。
- should :: 至少有一个查询条件匹配, 相当于 or。
这些参数可以分别继承一个过滤条件或者一个过滤条件的数组：
{
"bool": {
"must": { "term": { "folder": "inbox" }},
"must_not": { "term": { "tag": "spam" }},
"should": [
{ "term": { "starred": true }},
{ "term": { "unread": true }}
]
}
}Query DSL
match_all 查询
可以查询到所有文档，是没有查询条件下的默认语句。
{
"match_all": {}
}此查询常用于合并过滤条件。 比如说你需要检索所有的邮箱,所有的文档相关性都是相同的，所以得到的_score为1.
match 查询
match查询是一个标准查询，不管你需要全文本查询还是精确查询基本上都要用到它。
如果你使用 match 查询一个全文本字段，它会在真正查询之前用分析器先分析match一下查询字符：
{
"match": {
"tweet": "About Search"
}
}如果用match下指定了一个确切值，在遇到数字，日期，布尔值或者not_analyzed 的字符串时，它将为你搜索你给定的值：
{ "match": { "age": 26 }}
{ "match": { "date": "2014-09-01" }}
{ "match": { "public": true }}
{ "match": { "tag": "full_text" }}提示： 做精确匹配搜索时，你最好用过滤语句，因为过滤语句可以缓存数据。
match查询只能就指定某个确切字段某个确切的值进行搜索，而你要做的就是为它指定正确的字段名以避免语法错误。
multi_match 查询
multi_match查询允许你做match查询的基础上同时搜索多个字段，在多个字段中同时查一个：
{
"multi_match": {
"query": "full text search",
"fields": [ "title", "body" ]
}
}bool 查询
bool 查询与 bool 过滤相似，用于合并多个查询子句。不同的是，bool 过滤可以直接给出是否匹配成功， 而bool 查询要计算每一个查询子句的 _score （相关性分值）。
- must:: 查询指定文档一定要被包含。
- must_not:: 查询指定文档一定不要被包含。
- should:: 查询指定文档，有则可以为文档相关性加分。
以下查询将会找到 title 字段中包含 "how to make millions"，并且 "tag" 字段没有被标为 spam。 如果有标识为 "starred" 或者发布日期为2014年之前，那么这些匹配的文档将比同类网站等级高：
{
"bool": {
"must": { "match": { "title": "how to make millions" }},
"must_not": { "match": { "tag": "spam" }},
"should": [
{ "match": { "tag": "starred" }},
{ "range": { "date": { "gte": "2014-01-01" }}}
]
}
}提示： 如果bool 查询下没有must子句，那至少应该有一个should子句。但是 如果有must子句，那么没有should子句也可以进行查询。
短语匹配(Phrase Matching)
当你需要寻找邻近的几个单词时，你会使用match_phrase查询：
GET /my_index/my_type/_search
{
"query": {
"match_phrase": {
"title": "quick brown fox"
}
}
}和match查询类似，match_phrase查询首先解析查询字符串来产生一个词条列表。然后会搜索所有的词条，但只保留含有了所有搜索词条的文档，并且词条的位置要邻接。一个针对短语quick fox的查询不会匹配。
我们的任何文档，因为没有文档含有邻接在一起的quick和box词条。
match_phrase查询也可以写成类型为phrase的match查询：
"match": {
"title": {
"query": "quick brown fox",
"type": "phrase"
}
}