elasticsearch搜索语句大全.docx

上传人:b****8 文档编号:10840808 上传时间:2023-02-23 格式:DOCX 页数:20 大小:22.75KB
下载 相关 举报
elasticsearch搜索语句大全.docx_第1页
第1页 / 共20页
elasticsearch搜索语句大全.docx_第2页
第2页 / 共20页
elasticsearch搜索语句大全.docx_第3页
第3页 / 共20页
elasticsearch搜索语句大全.docx_第4页
第4页 / 共20页
elasticsearch搜索语句大全.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

elasticsearch搜索语句大全.docx

《elasticsearch搜索语句大全.docx》由会员分享,可在线阅读,更多相关《elasticsearch搜索语句大全.docx(20页珍藏版)》请在冰豆网上搜索。

elasticsearch搜索语句大全.docx

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),然后使用结果建立一个倒排索引。

我们将在以下两个章节讨论倒排索引及分析过程。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 幼儿教育 > 育儿理论经验

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1