elasticsearch搜索语句大全.docx
《elasticsearch搜索语句大全.docx》由会员分享，可在线阅读，更多相关《elasticsearch搜索语句大全.docx（20页珍藏版）》请在冰豆网上搜索。
elasticsearch搜索语句大全
elasticsearch搜索
搜索
检索单个文档
现在Elasticsearch中已经存储了一些数据，我们可以根据业务需求开始工作了。
第一个需求是能够检索单个员工的信息。
这对于Elasticsearch来说非常简单。
我们只要执行HTTPGET请求并指出文档的“地址”——索引、类型和ID既可。
根据这三部分信息，我们就可以返回原始JSON文档：
GET/megacorp/employee/1
响应的内容中包含一些文档的元信息，JohnSmith的原始JSON文档包含在_source字段中。
{
"_index":
"megacorp",
"_type":
"employee",
"_id":
"1",
"_version":
1,
"found":
true,
"_source":
{
"first_name":
"John",
"last_name":
"Smith",
"age":
25,
"about":
"Ilovetogorockclimbing",
"interests":
["sports","music"]
}
}
我们通过HTTP方法GET来检索文档，同样的，我们可以使用DELETE方法删除文档，使用HEAD方法检查某文档是否存在。
如果想更新已存在的文档，我们只需再PUT一次。
搜索全部文档
我们尝试一个最简单的搜索全部员工的请求：
GET/megacorp/employee/_search
你可以看到我们依然使用megacorp索引和employee类型，但是我们在结尾使用关键字_search来取代原来的文档ID。
响应内容的hits数组中包含了我们所有的三个文档。
默认情况下搜索会返回前10个结果。
{
"took":
6,
"timed_out":
false,
"_shards":
{...},
"hits":
{
"total":
3,
"max_score":
1,
"hits":
[
{
"_index":
"megacorp",
"_type":
"employee",
"_id":
"3",
"_score":
1,
"_source":
{
"first_name":
"Douglas",
"last_name":
"Fir",
"age":
35,
"about":
"Iliketobuildcabinets",
"interests":
["forestry"]
}
},
{
"_index":
"megacorp",
"_type":
"employee",
"_id":
"1",
"_score":
1,
"_source":
{
"first_name":
"John",
"last_name":
"Smith",
"age":
25,
"about":
"Ilovetogorockclimbing",
"interests":
["sports","music"]
}
},
{
"_index":
"megacorp",
"_type":
"employee",
"_id":
"2",
"_score":
1,
"_source":
{
"first_name":
"Jane",
"last_name":
"Smith",
"age":
32,
"about":
"Iliketocollectrockalbums",
"interests":
["music"]
}
}
]
}
}
注意：
响应内容不仅会告诉我们哪些文档被匹配到，而且这些文档内容完整的被包含在其中—我们在给用户展示搜索结果时需要用到的所有信息都有了。
搜索姓氏中包含Smith的员工
要做到这一点，我们将在命令行中使用轻量级的搜索方法。
这种方法常被称作查询字符串（querystring）搜索，因为我们像传递URL参数一样去传递查询语句：
GET/megacorp/employee/_search?
q=last_name:
Smith
我们在请求中依旧使用_search关键字，然后将查询语句传递给参数q=。
这样就可以得到所有姓氏为Smith的结果：
{
...
"hits":
{
"total":
2,
"max_score":
0.30685282,
"hits":
[
{
...
"_source":
{
"first_name":
"John",
"last_name":
"Smith",
"age":
25,
"about":
"Ilovetogorockclimbing",
"interests":
["sports","music"]
}
},
{
...
"_source":
{
"first_name":
"Jane",
"last_name":
"Smith",
"age":
32,
"about":
"Iliketocollectrockalbums",
"interests":
["music"]
}
}
]
}
}
DSL语句查询
查询字符串搜索便于通过命令行完成特定（adhoc）的搜索，但是它也有局限性（参阅简单搜索章节）。
Elasticsearch提供丰富且灵活的查询语言叫做DSL查询（QueryDSL）,它允许你构建更加复杂、强大的查询。
DSL（DomainSpecificLanguage特定领域语言）以JSON请求体的形式出现。
我们可以这样表示之前关于“Smith”的查询:
GET/megacorp/employee/_search
{
"query":
{
"match":
{
"last_name":
"Smith"
}
}
}
这会返回与之前查询相同的结果。
你可以看到有些东西改变了，我们不再使用查询字符串（querystring）做为参数，而是使用请求体代替。
这个请求体使用JSON表示，其中使用了match语句（查询类型之一，具体我们以后会学到）。
更复杂的搜索
我们让搜索稍微再变的复杂一些。
我们依旧想要找到姓氏为“Smith”的员工，但是我们只想得到年龄大于30岁的员工。
我们的语句将添加过滤器（filter）,它使得我们高效率的执行一个结构化搜索：
GET/megacorp/employee/_search
{
"query":
{
"filtered":
{
"filter":
{
"range":
{
"age":
{"gt":
30}<1>
}
},
"query":
{
"match":
{
"last_name":
"smith"<2>
}
}
}
}
}
<1>这部分查询属于区间过滤器（rangefilter）,它用于查找所有年龄大于30岁的数据——gt为"greaterthan"的缩写。
<2>这部分查询与之前的match语句（query）一致。
现在不要担心语法太多，我们将会在以后详细的讨论。
你只要知道我们添加了一个过滤器（filter）用于执行区间搜索，然后重复利用了之前的match语句。
现在我们的搜索结果只显示了一个32岁且名字是“JaneSmith”的员工：
{
...
"hits":
{
"total":
1,
"max_score":
0.30685282,
"hits":
[
{
...
"_source":
{
"first_name":
"Jane",
"last_name":
"Smith",
"age":
32,
"about":
"Iliketocollectrockalbums",
"interests":
["music"]
}
}
]
}
}
全文搜索
到目前为止搜索都很简单：
搜索特定的名字，通过年龄筛选。
让我们尝试一种更高级的搜索，全文搜索——一种传统数据库很难实现的功能。
我们将会搜索所有喜欢“rockclimbing”的员工：
GET/megacorp/employee/_search
{
"query":
{
"match":
{
"about":
"rockclimbing"
}
}
}
你可以看到我们使用了之前的match查询，从about字段中搜索"rockclimbing"，我们得到了两个匹配文档：
{
...
"hits":
{
"total":
2,
"max_score":
0.16273327,
"hits":
[
{
...
"_score":
0.16273327,<1>
"_source":
{
"first_name":
"John",
"last_name":
"Smith",
"age":
25,
"about":
"Ilovetogorockclimbing",
"interests":
["sports","music"]
}
},
{
...
"_score":
0.016878016,<2>
"_source":
{
"first_name":
"Jane",
"last_name":
"Smith",
"age":
32,
"about":
"Iliketocollectrockalbums",
"interests":
["music"]
}
}
]
}
}
<1><2>结果相关性评分。
默认情况下，Elasticsearch根据结果相关性评分来对结果集进行排序，所谓的「结果相关性评分」就是文档与查询条件的匹配程度。
很显然，排名第一的JohnSmith的about字段明确的写到“rockclimbing”。
但是为什么JaneSmith也会出现在结果里呢？
原因是“rock”在她的abuot字段中被提及了。
因为只有“rock”被提及而“climbing”没有，所以她的_score要低于John。
这个例子很好的解释了Elasticsearch如何在各种文本字段中进行全文搜索，并且返回相关性最大的结果集。
相关性（relevance）的概念在Elasticsearch中非常重要，而这个概念在传统关系型数据库中是不可想象的，因为传统数据库对记录的查询只有匹配或者不匹配。
短语搜索
目前我们可以在字段中搜索单独的一个词，这挺好的，但是有时候你想要确切的匹配若干个单词或者短语（phrases）。
例如我们想要查询同时包含"rock"和"climbing"（并且是相邻的）的员工记录。
要做到这个，我们只要将match查询变更为match_phrase查询即可:
GET/megacorp/employee/_search
{
"query":
{
"match_phrase":
{
"about":
"rockclimbing"
}
}
}
毫无疑问，该查询返回JohnSmith的文档：
{
...
"hits":
{
"total":
1,
"max_score":
0.23013961,
"hits":
[
{
...
"_score":
0.23013961,
"_source":
{
"first_name":
"John",
"last_name":
"Smith",
"age":
25,
"about":
"Ilovetogorockclimbing",
"interests":
["sports","music"]
}
}
]
}
}
聚合（groupby）
Elasticsearch有一个功能叫做聚合（aggregations），它允许你在数据上生成复杂的分析统计。
它很像SQL中的GROUPBY但是功能更强大。
举个例子，让我们找到所有职员中最大的共同点（兴趣爱好）是什么：
GET/megacorp/employee/_search
{
"aggs":
{
"all_interests":
{
"terms":
{"field":
"interests"}
}
}
}
暂时先忽略语法只看查询结果：
{
...
"hits":
{...},
"aggregations":
{
"all_interests":
{
"buckets":
[
{
"key":
"music",
"doc_count":
2
},
{
"key":
"forestry",
"doc_count":
1
},
{
"key":
"sports",
"doc_count":
1
}
]
}
}
}
我们可以看到两个职员对音乐有兴趣，一个喜欢林学，一个喜欢运动。
这些数据并没有被预先计算好，它们是实时的从匹配查询语句的文档中动态计算生成的。
如果我们想知道所有姓"Smith"的人最大的共同点（兴趣爱好），我们只需要增加合适的语句既可：
GET/megacorp/employee/_search
{
"query":
{
"match":
{
"last_name":
"smith"
}
},
"aggs":
{
"all_interests":
{
"terms":
{
"field":
"interests"
}
}
}
}
all_interests聚合已经变成只包含和查询语句相匹配的文档了：
...
"all_interests":
{
"buckets":
[
{
"key":
"music",
"doc_count":
2
},
{
"key":
"sports",
"doc_count":
1
}
]
}
聚合也允许分级汇总。
例如，让我们统计每种兴趣下职员的平均年龄：
GET/megacorp/employee/_search
{
"aggs":
{
"all_interests":
{
"terms":
{"field":
"interests"},
"aggs":
{
"avg_age":
{
"avg":
{"field":
"age"}
}
}
}
}
}
虽然这次返回的聚合结果有些复杂，但任然很容易理解：
...
"all_interests":
{
"buckets":
[
{
"key":
"music",
"doc_count":
2,
"avg_age":
{
"value":
28.5
}
},
{
"key":
"forestry",
"doc_count":
1,
"avg_age":
{
"value":
35
}
},
{
"key":
"sports",
"doc_count":
1,
"avg_age":
{
"value":
25
}
}
]
}
该聚合结果比之前的聚合结果要更加丰富。
我们依然得到了兴趣以及数量（指具有该兴趣的员工人数）的列表，但是现在每个兴趣额外拥有avg_age字段来显示具有该兴趣员工的平均年龄。
即使你还不理解语法，但你也可以大概感觉到通过这个特性可以完成相当复杂的聚合工作，你可以处理任何类型的数据。
sql联合查询
左连接
SELECTtest1.id,test1.`value`,test2.id,test2.`name`FROMtest1LEFTJOINtest2ONtest1.`value`=test2.test_id
右连接
SELECTtest1.`value`,test2.idFROMtest1RIGHTJOINtest2ONtest1.`value`=test2.test_id;
内连接
SELECTtest1.`value`,test2.idFROMtest1INNERJOINtest2ONtest1.`value`=test2.test_id;
相当于内连接
SELECTtest1.`value`,test2.idFROMtest1,test2WHEREtest1.`value`=test2.test_id;
cross join 是笛卡儿乘积 就是一张表的行数乘以另一张表的行数
left join 第一张表的连接列在第二张表中没有匹配是,第二张表中的值返回null
right join 第二张表的连接列在第一张表中没有匹配是,第一张表中的值返回null
inner join 只返回两张表连接列的匹配项
映射与分析
映射（mapping）机制用于进行字段类型确认，将每个字段匹配为一种确定的数据类型（string,number,booleans,date等）。
分析（analysis）机制用于进行全文文本（FullText）的分词，以建立供搜索用的反向索引
映射及分析
当在索引中处理数据时，我们注意到一些奇怪的事。
有些东西似乎被破坏了：
在索引中有12个tweets，只有一个包含日期2014-09-15，但是我们看看下面查询中的totalhits。
GET/_search?
q=2014#12个结果
GET/_search?
q=2014-09-15#还是12个结果!
GET/_search?
q=date:
2014-09-15#1一个结果
GET/_search?
q=date:
2014#0个结果!
为什么全日期的查询返回所有的tweets，而针对date字段进行年度查询却什么都不返回？
为什么我们的结果因查询_all字段（译者注：
默认所有字段中进行查询）或date字段而变得不同？
想必是因为我们的数据在_all字段的索引方式和在date字段的索引方式不同而导致。
让我们看看Elasticsearch在对gb索引中的tweet类型进行mapping（也称之为模式定义[注：
此词有待重新定义（schemadefinition）]）后是如何解读我们的文档结构：
GET/gb/_mapping/tweet
返回：
{
"gb":
{
"mappings":
{
"tweet":
{
"properties":
{
"date":
{
"type":
"date",
"format":
"dateOptionalTime"
},
"name":
{
"type":
"string"
},
"tweet":
{
"type":
"string"
},
"user_id":
{
"type":
"long"
}
}
}
}
}
}
Elasticsearch为对字段类型进行猜测，动态生成了字段和类型的映射关系。
返回的信息显示了date字段被识别为date类型。
_all因为是默认字段所以没有在此显示，不过我们知道它是string类型。
date类型的字段和string类型的字段的索引方式是不同的，因此导致查询结果的不同，这并不会让我们觉得惊讶。
你会期望每一种核心数据类型（strings,numbers,booleans及dates）以不同的方式进行索引，而这点也是现实：
在Elasticsearch中他们是被区别对待的。
但是更大的区别在于确切值（exactvalues）（比如string类型）及全文文本（fulltext）之间。
这两者的区别才真的很重要-这是区分搜索引擎和其他数据库的根本差异。
确切值（Exactvalues）vs.全文文本（Fulltext）
Elasticsearch中的数据可以大致分为两种类型：
确切值及全文文本。
确切值是确定的，正如它的名字一样。
比如一个date或用户ID，也可以包含更多的字符串比如username或email地址。
确切值"Foo"和"foo"就并不相同。
确切值2014和2014-09-15也不相同。
全文文本，从另一个角度来说是文本化的数据（常常以人类的语言书写），比如一篇推文（Twitter的文章）或邮件正文。
全文文本常常被称为非结构化数据，其实是一种用词不当的称谓，实际上自然语言是高度结构化的。
问题是自然语言的语法规则是如此的复杂，计算机难以正确解析。
例如这个句子：
MayisfunbutJuneboresme.
到底是说的月份还是人呢？
确切值是很容易查询的，因为结果是二进制的--要么匹配，要么不匹配。
下面的查询很容易以SQL表达：
WHEREname="JohnSmith"
ANDuser_id=2
ANDdate>"2014-09-15"
而对于全文数据的查询来说，却有些微妙。
我们不会去询问这篇文档是否匹配查询要求？
。
但是，我们会询问这篇文档和查询的匹配程度如何？
。
换句话说，对于查询条件，这篇文档的相关性有多高？
+
我们很少确切的匹配整个全文文本。
我们想在全文中查询包含查询文本的部分。
不仅如此，我们还期望搜索引擎能理解我们的意图：
一个针对"UK"的查询将返回涉及"UnitedKingdom"的文档
一个针对"jump"的查询同时能够匹配"jumped"，"jumps"，"jumping"甚至"leap"
"johnnywalker"也能匹配"JohnnieWalker"，"johnniedepp"及"JohnnyDepp"
"foxnewshunting"能返回有关huntingonFoxNews的故事，而"foxhuntingnews"也能返回关于foxhunting的新闻故事。
为了方便在全文文本字段中进行这些类型的查询，Elasticsearch首先对文本分析（analyzes），然后使用结果建立一个倒排索引。
我们将在以下两个章节讨论倒排索引及分析过程。
升级会员 