ES笔记
分片定义
分片是一个功能完整的搜索引擎,它拥有使用一个节点上的所有资源的能力。
分片分为:主 分片或副本分片。主分片是主要的。副本分片是备份。当索引创建时,主分片就固定了。副本格式可以随时修改
PUT /blogs/_settings
{
"number_of_replicas" : 2 //修改副本个数
}
文档定义
一个 对象 是基于特定语言的内存的数据结构。为了通过网络发送或者存储它,我们需要将它表示成某种标准的格式。 JSON 是一种以人可读的文本表示对象的方法。 它已经变成 NoSQL 世界交换数据的事实标准。当一个对象被序列化成为 JSON,它被称为一个 JSON 文档 。
在 Elasticsearch 中, 每个字段的所有数据 都是 默认被索引的 。 即每个字段都有为了快速检索设置的专用倒排索引。而且,不像其他多数的数据库,它能在 同一个查询中 使用所有这些倒排索引,并以惊人的速度返回结果。
文档元数据
_index
文档在哪存放
_type
文档表示的对象类别
_id
文档唯一标识
创建文档
PUT /website/blog/123 //put需要指定id
{
"title": "My first blog entry",
"text": "Just trying this out...",
"date": "2014/01/01"
}
POST /website/blog/ // post请求,不传id,可以自动生成id
{
"title": "My second blog entry",
"text": "Still trying this out...",
"date": "2014/01/01"
}
PUT /website/blog/123/_create{ //当index,type,id都不存在时,在创建文档
"title": "My second blog entry",
"text": "Still trying this out...",
"date": "2014/01/01"
}
取回文档
- 为了从 Elasticsearch 中检索出文档,我们仍然使用相同的
_index
,_type
, 和_id
,但是 HTTP 谓词更改为GET
tip
在请求的查询串参数中加上 pretty
参数,正如前面的例子中看到的,这将会调用 Elasticsearch 的 pretty-print 功能,该功能 使得 JSON 响应体更加可读。但是, _source
字段不能被格式化打印出来。相反,我们得到的 _source
字段中的 JSON 串,刚好是和我们传给它的一样
GET /website/blog/123?pretty
-
设置返回的字段
GET /website/blog/123?_source=title,text
-
如果你只想得到
_source
字段,不需要任何元数据,你能使用_source
端点GET /website/blog/123/_source
取回多个文档
那么使用 multi-get 或者 mget
API 来将这些检索请求放在一个请求中,将比逐个文档请求更快地检索到全部文档。
GET /_mget
{
"docs" : [
{
"_index" : "website",
"_type" : "blog",
"_id" : 2
},
{
"_index" : "website",
"_type" : "pageviews",
"_id" : 1,
"_source": "views"
}
]
}
更新文档
在 Elasticsearch 中文档是 不可改变 的,不能修改它们。相反,如果想要更新现有的文档,需要 重建索引 或者进行替换
PUT /website/blog/123
{
"title": "My first blog entry",
"text": "I am starting to get the hang of this...",
"date": "2014/01/02"
}
在响应体中,我们能看到 Elasticsearch 已经增加了 _version
字段值:
{
"_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 2,
"created": false
}
created
标志设置成 false
,是因为相同的索引、类型和 ID 的文档已经存在。
在内部,Elasticsearch 已将旧文档标记为已删除,并增加一个全新的文档。 尽管你不能再对旧版本的文档进行访问,但它并不会立即消失。当继续索引更多的数据,Elasticsearch 会在后台清理这些已删除文档。
文档部分更新
介绍过文档是不可变的:他们不能被修改,只能被替换。 update
API 必须遵循同样的规则。 从外部来看,我们在一个文档的某个位置进行部分更新。然而在内部, update
API 简单使用与之前描述相同的 检索-修改-重建索引 的处理过程。 区别在于这个过程发生在分片内部,这样就避免了多次请求的网络开销。通过减少检索和重建索引步骤之间的时间,我们也减少了其他进程的变更带来冲突的可能性。
update
请求最简单的一种形式是接收文档的一部分作为 doc
的参数, 它只是与现有的文档进行合并。对象被合并到一起,覆盖现有的字段,增加新的字段。 例如,我们增加字段 tags
和 views
到我们的博客文章,如下所示
POST /website/blog/1/_update
{
"doc" : {
"tags" : [ "testing" ],
"views": 0
}
}
POST /website/pageviews/1/_update //更新的文档不存在,就新增 upsert
{
"upsert": {
"views": 1
}
}
//设置参数 retry_on_conflict 来自动完成, 这个参数规定了失败之前 update 应该重试的次数,它的默认值为 0
POST /website/pageviews/1/_update?retry_on_conflict=5
{
"script" : "ctx._source.views+=1",
"upsert": {
"views": 0
}
}
删除文档
删除文档的语法和我们所知道的规则相同,只是使用 DELETE
方法
DELETE /website/blog/123
悲观锁和乐观锁
当我们之前讨论 index
, GET
和 delete
请求时,我们指出每个文档都有一个 _version
(版本)号,当文档被修改时版本号递增。 Elasticsearch 使用这个 _version
号来确保变更以正确顺序得到执行
当我们尝试通过重建文档的索引来保存修改,我们指定 version
为我们的修改会被应用的版本
//我们想这个在我们索引中的文档只有现在的 _version 为 1 时,本次更新才能成功
//乐观锁机制
PUT /website/blog/1?version=1
{
"title": "My first blog entry",
"text": "Starting to get the hang of this..."
}
批操作
略
搜索
空搜索
搜索API的最基础的形式是没有指定任何查询的空搜索,它简单地返回集群中所有索引下的所有文档
GET /_search
分页搜索
size
显示应该返回的结果数量,默认是 10
from
显示应该跳过的初始结果数量,默认是 0
GET /_search?size=5&from=10
分析与分析器
分析 包含下面的过程:
- 首先,将一块文本分成适合于倒排索引的独立的 词条 ,
- 之后,将这些词条统一化为标准格式以提高它们的“可搜索性”,或者 recall
分析器执行上面的工作。 分析器 实际上是将三个功能封装到了一个包里:
-
字符过滤器
首先,字符串按顺序通过每个 字符过滤器 。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML,或者将
&
转化成and
。 -
分词器
其次,字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候,可能会将文本拆分成词条。
-
Token 过滤器
最后,词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条(例如,小写化
Quick
),删除词条(例如, 像a
,and
,the
等无用词),或者增加词条(例如,像jump
和leap
这种同义词)。
内置分析器
Elasticsearch还附带了可以直接使用的预包装的分析器。接下来我们会列出最重要的分析器。为了证明它们的差异,我们看看每个分析器会从下面的字符串得到哪些词条:
"Set the shape to semi-transparent by calling set_trans(5)"
-
标准分析器
标准分析器是Elasticsearch默认使用的分析器。它是分析各种语言文本最常用的选择。它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后,将词条小写。它会产生
set, the, shape, to, semi, transparent, by, calling, set_trans, 5
-
简单分析器
简单分析器在任何不是字母的地方分隔文本,将词条小写。它会产生
set, the, shape, to, semi, transparent, by, calling, set, trans
-
空格分析器
空格分析器在空格的地方划分文本。它会产生
Set, the, shape, to, semi-transparent, by, calling, set_trans(5)
-
语言分析器
特定语言分析器可用于 很多语言。它们可以考虑指定语言的特点。例如,
英语
分析器附带了一组英语无用词(常用单词,例如and
或者the
,它们对相关性没有多少影响),它们会被删除。 由于理解英语语法的规则,这个分词器可以提取英语单词的 词干 。英语
分词器会产生下面的词条:set, shape, semi, transpar, call, set_tran, 5
注意看transparent
、calling
和set_trans
已经变为词根格式。
什么时候使用分析器
当我们 索引 一个文档,它的全文域被分析成词条以用来创建倒排索引。 但是,当我们在全文域 搜索 的时候,我们需要将查询字符串通过 相同的分析过程 ,以保证我们搜索的词条格式与索引中的词条格式一致。
全文查询,理解每个域是如何定义的,因此它们可以做正确的事:
- 当你查询一个 全文 域时, 会对查询字符串应用相同的分析器,以产生正确的搜索词条列表。
- 当你查询一个 精确值 域时,不会分析查询字符串,而是搜索你指定的精确值。
现在你可以理解在 开始章节 的查询为什么返回那样的结果:
date
域包含一个精确值:单独的词条2014-09-15
。_all
域是一个全文域,所以分词进程将日期转化为三个词条:2014
,09
, 和15
。
当我们在 _all
域查询 2014
,它匹配所有的12条推文,因为它们都含有 2014
:
GET /_search?q=2014 # 12 results
当我们在 _all
域查询 2014-09-15
,它首先分析查询字符串,产生匹配 2014
, 09
, 或 15
中 任意 词条的查询。这也会匹配所有12条推文,因为它们都含有 2014
:
GET /_search?q=2014-09-15 # 12 results !
当我们在 date
域查询 2014-09-15
,它寻找 精确 日期,只找到一个推文:
GET /_search?q=date:2014-09-15 # 1 result
当我们在 date
域查询 2014
,它找不到任何文档,因为没有文档含有这个精确日志:
GET /_search?q=date:2014 # 0 results !
测试分析器
有些时候很难理解分词的过程和实际被存储到索引中的词条,特别是你刚接触Elasticsearch。为了理解发生了什么,你可以使用 analyze
API 来看文本是如何被分析的。在消息体里,指定分析器和要分析的文本:
GET /_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
结果中每个元素代表一个单独的词条:
{
"tokens": [
{
"token": "text",
"start_offset": 0,
"end_offset": 4,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "to",
"start_offset": 5,
"end_offset": 7,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "analyze",
"start_offset": 8,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 3
}
]
}
token
是实际存储到索引中的词条。 position
指明词条在原始文本中出现的位置。 start_offset
和 end_offset
指明字符在原始字符串中的位置。
指定分析器
当Elasticsearch在你的文档中检测到一个新的字符串域,它会自动设置其为一个全文 字符串
域,使用 标准
分析器对它进行分析。
你不希望总是这样。可能你想使用一个不同的分析器,适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域—不使用分析,直接索引你传入的精确值,例如用户ID或者一个内部的状态域或标签。
要做到这一点,我们必须手动指定这些域的映射。
映射
Elasticsearch 支持如下简单域类型:
- 字符串:
string
- 整数 :
byte
,short
,integer
,long
- 浮点数:
float
,double
- 布尔型:
boolean
- 日期:
date
查看映射
通过 /_mapping
,我们可以查看 Elasticsearch 在一个或多个索引中的一个或多个类型的映射。在 开始章节 ,我们已经取得索引 gb
中类型 tweet
的映射:
GET /gb/_mapping/tweet
自定义域映射
尽管在很多情况下基本域数据类型已经够用,但你经常需要为单独域自定义映射,特别是字符串域。自定义映射允许你执行下面的操作:
- 全文字符串域和精确值字符串域的区别
- 使用特定语言分析器
- 优化域以适应部分匹配
- 指定自定义数据格式
- 还有更多
域最重要的属性是 type
。对于不是 string
的域,你一般只需要设置 type
:
{
"number_of_clicks": {
"type": "integer"
}
}
默认, string
类型域会被认为包含全文。就是说,它们的值在索引前,会通过一个分析器,针对于这个域的查询在搜索前也会经过一个分析器。
string
域映射的两个最重要属性是 index
和 analyzer
。
index
index
属性控制怎样索引字符串。它可以是下面三个值:
-
analyzed
首先分析字符串,然后索引它。换句话说,以全文索引这个域。
-
not_analyzed
索引这个域,所以它能够被搜索,但索引的是精确值。不会对它进行分析。
-
no
不索引这个域。这个域不会被搜索到。
string
域 index
属性默认是 analyzed
。如果我们想映射这个字段为一个精确值,我们需要设置它为 not_analyzed
:
{
"tag": {
"type": "string",
"index": "not_analyzed"
}
}
其他简单类型(例如 long
, double
, date
等)也接受 index
参数,但有意义的值只有 no
和 not_analyzed
, 因为它们永远不会被分析。
analyzer
对于 analyzed
字符串域,用 analyzer
属性指定在搜索和索引时使用的分析器。默认, Elasticsearch 使用 standard
分析器, 但你可以指定一个内置的分析器替代它,例如 whitespace
、 simple
和 english
:
{
"tweet": {
"type": "string",
"analyzer": "english"
}
}
在 自定义分析器 ,我们会展示怎样定义和使用自定义分析器。
更新映射
当你首次创建一个索引的时候,可以指定类型的映射。你也可以使用 /_mapping
为新类型(或者为存在的类型更新映射)增加映射。
尽管你可以 增加 一个存在的映射,你不能 修改 存在的域映射。如果一个域的映射已经存在,那么该域的数据可能已经被索引。如果你意图修改这个域的映射,索引的数据可能会出错,不能被正常的搜索。
我们可以更新一个映射来添加一个新域,但不能将一个存在的域从 analyzed
改为 not_analyzed
。
为了描述指定映射的两种方式,我们先删除 gd
索引:
DELETE /gb
然后创建一个新索引,指定 tweet
域使用 english
分析器:
PUT /gb
{
"mappings": {
"tweet" : {
"properties" : {
"tweet" : {
"type" : "string",
"analyzer": "english"
},
"date" : {
"type" : "date"
},
"name" : {
"type" : "string"
},
"user_id" : {
"type" : "long"
}
}
}
}
}
通过消息体中指定的 mappings
创建了索引。
稍后,我们决定在 tweet
映射增加一个新的名为 tag
的 not_analyzed
的文本域,使用 _mapping
:
PUT /gb/_mapping/tweet
{
"properties" : {
"tag" : {
"type" : "string",
"index": "not_analyzed"
}
}
}
注意,我们不需要再次列出所有已存在的域,因为无论如何我们都无法改变它们。新域已经被合并到存在的映射中。
测试映射
你可以使用 analyze
API 测试字符串域的映射。比较下面两个请求的输出:
GET /gb/_analyze
{
"field": "tweet",
"text": "Black-cats"
}
GET /gb/_analyze
{
"field": "tag",
"text": "Black-cats"
}
请求体查询
查询表达式
查询表达式(Query DSL)是一种非常灵活又富有表现力的 查询语言。 Elasticsearch 使用它可以以简单的 JSON 接口来展现 Lucene 功能的绝大部分。在你的应用中,你应该用它来编写你的查询语句。它可以使你的查询语句更灵活、更精确、易读和易调试。
查询格式
{
QUERY_NAME: {
FIELD_NAME: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}
}
空查询
GET /_search
{
"query": {
"match_all": {}
}
}
and or 多条件查询
{
"bool": {
"must": { "match": { "tweet": "elasticsearch" }},
"must_not": { "match": { "name": "mary" }},
"should": { "match": { "tweet": "full text" }},
"filter": { "range": { "age" : { "gt" : 30 }} }
}
}
{
"bool" : {
"must" : [{},{}],
"should" : [{},{}],
"must_not" : [{},{}],
}
}
match_all 查询
match_all
查询简单的匹配所有文档。在没有指定查询方式时,它是默认的查询:
{ "match_all": {}}
它经常与 filter 结合使用—例如,检索收件箱里的所有邮件。所有邮件被认为具有相同的相关性,所以都将获得分值为 1
的中性 _score
。
match 查询
无论你在任何字段上进行的是全文搜索还是精确查询,match
查询是你可用的标准查询。
如果你在一个全文字段上使用 match
查询,在执行查询前,它将用正确的分析器去分析查询字符串:
{ "match": { "tweet": "About Search" }}
如果在一个精确值的字段上使用它,例如数字、日期、布尔或者一个 not_analyzed
字符串字段,那么它将会精确匹配给定的值:
{ "match": { "age": 26 }}
{ "match": { "date": "2014-09-01" }}
{ "match": { "public": true }}
{ "match": { "tag": "full_text" }}
对于精确值的查询,你可能需要使用 filter 语句来取代 query,因为 filter 将会被缓存。接下来,我们将看到一些关于 filter 的例子。
不像我们在 轻量 搜索 章节介绍的字符串查询(query-string search), match
查询不使用类似 +user_id:2 +tweet:search
的查询语法。它只是去查找给定的单词。这就意味着将查询字段暴露给你的用户是安全的;你需要控制那些允许被查询字段,不易于抛出语法异常。
match
查询还可以接受 operator
操作符作为输入参数,默认情况下该操作符是 or
。我们可以将它修改成 and
让所有指定词项都必须匹配
GET /my_index/my_type/_search
{
"query": {
"match": {
"title": {
"query": "BROWN DOG!",
"operator": "and" // “or”
}
}
}
}
multi_match 查询
multi_match
查询可以在多个字段上执行相同的 match
查询:
{
"multi_match": {
"query": "full text search",
"fields": [ "title", "body" ]
}
}
range 查询
range
查询找出那些落在指定区间内的数字或者时间:
{
"range": {
"age": {
"gte": 20,
"lt": 30
}
}
}
被允许的操作符如下:
-
gt
大于
-
gte
大于等于
-
lt
小于
-
lte
小于等于
term 查询
term
查询被用于精确值匹配,这些精确值可能是数字、时间、布尔或者那些 not_analyzed
的字符串:
{ "term": { "age": 26 }}
{ "term": { "date": "2014-09-01" }}
{ "term": { "public": true }}
{ "term": { "tag": "full_text" }}
term
查询对于输入的文本不 分析 ,所以它将给定的值进行精确查询。
terms 查询
terms
查询和 term
查询一样,但它允许你指定多值进行匹配。如果这个字段包含了指定值中的任何一个值,那么这个文档满足条件:
{ "terms": { "tag": [ "search", "full_text", "nosql" ] }}
和 term
查询一样,terms
查询对于输入的文本不分析。它查询那些精确匹配的值(包括在大小写、重音、空格等方面的差异)。
包含,而不是相等
一定要了解 term
和 terms
是 包含(contains) 操作,而非 等值(equals) (判断)。 如何理解这句话呢?
如果我们有一个 term(词项)过滤器 { "term" : { "tags" : "search" } }
,它会与以下两个文档 同时 匹配:
{ "tags" : ["search"] }
{ "tags" : ["search", "open_source"] }
term和terms精确相等
如果一定期望得到我们前面说的那种行为(即整个字段完全相等),最好的方式是增加并索引另一个字段, 这个字段用以存储该字段包含词项的数量,同样以上面提到的两个文档为例,现在我们包括了一个维护标签数的新字段:
{ "tags" : ["search"], "tag_count" : 1 }
{ "tags" : ["search", "open_source"], "tag_count" : 2 }
一旦增加这个用来索引项 term 数目信息的字段,我们就可以构造一个 constant_score
查询,来确保结果中的文档所包含的词项数量与要求是一致的:
GET /my_index/my_type/_search
{
"query": {
"constant_score" : {
"filter" : {
"bool" : {
"must" : [
{ "term" : { "tags" : "search" } },
{ "term" : { "tag_count" : 1 } }
]
}
}
}
}
}
exists 查询和 missing 查询
可以实现 is null 和 is not null 的查询
exists
查询和 missing
查询被用于查找那些指定字段中有值 (exists
) 或无值 (missing
) 的文档。这与SQL中的 IS_NULL
(missing
) 和 NOT IS_NULL
(exists
) 在本质上具有共性:
# is not null
{
"exists": {
"field": "title"
}
}
# is null
GET /my_index/posts/_search
{
"query" : {
"constant_score" : {
"filter": {
"missing" : { "field" : "tags" }
}
}
}
}
#嵌套子对象的字段确实判断 es会把子对象解释成 a.b.c这种形式
{
"bool": {
"should": [
{ "exists": { "field": "name.first" }},
{ "exists": { "field": "name.last" }}
]
}
}
这些查询经常用于某个字段有值的情况和某个字段缺值的情况。
组合多查询
现实的查询需求从来都没有那么简单;它们需要在多个字段上查询多种多样的文本,并且根据一系列的标准来过滤。为了构建类似的高级查询,你需要一种能够将多查询组合成单一查询的查询方法。
你可以用 bool
查询来实现你的需求。这种查询将多查询组合在一起,成为用户自己想要的布尔查询。它接收以下参数:
-
must
文档 必须 匹配这些条件才能被包含进来。
-
must_not
文档 必须不 匹配这些条件才能被包含进来。
-
should
如果满足这些语句中的任意语句,将增加
_score
,否则,无任何影响。它们主要用于修正每个文档的相关性得分。 -
filter
必须 匹配,但它以不评分、过滤模式来进行。这些语句对评分没有贡献,只是根据过滤标准来排除或包含文档。
由于这是我们看到的第一个包含多个查询的查询,所以有必要讨论一下相关性得分是如何组合的。每一个子查询都独自地计算文档的相关性得分。一旦他们的得分被计算出来, bool
查询就将这些得分进行合并并且返回一个代表整个布尔操作的得分。
{
"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
语句必须匹配,所有 must_not
语句都必须不匹配,但有多少 should
语句应该匹配呢?默认情况下,没有 should
语句是必须匹配的,只有一个例外:那就是当没有 must
语句的时候,至少有一个 should
语句必须匹配。
就像我们能控制 match
查询的精度 一样,我们可以通过 minimum_should_match
参数控制需要匹配的 should
语句的数量,它既可以是一个绝对的数字,又可以是个百分比:
GET /my_index/my_type/_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "brown" }},
{ "match": { "title": "fox" }},
{ "match": { "title": "dog" }}
],
"minimum_should_match": 2
}
}
}
增加带过滤器(filtering)的查询
如果我们不想因为文档的时间而影响得分,可以用 filter
语句来重写前面的例子:
{
"bool": {
"must": { "match": { "title": "how to make millions" }},
"must_not": { "match": { "tag": "spam" }},
"should": [
{ "match": { "tag": "starred" }}
],
"filter": {
"range": { "date": { "gte": "2014-01-01" }}
}
}
}
range 查询已经从 should
语句中移到 filter
语句
通过将 range 查询移到 filter
语句中,我们将它转成不评分的查询,将不再影响文档的相关性排名。由于它现在是一个不评分的查询,可以使用各种对 filter 查询有效的优化手段来提升性能。
验证查询
查询可以变得非常的复杂,尤其和不同的分析器与不同的字段映射结合时,理解起来就有点困难了。不过 validate-query
API 可以用来验证查询是否合法。
GET /gb/tweet/_validate/query
{
"query": {
"tweet" : {
"match" : "really powerful"
}
}
}
以上 validate
请求的应答告诉我们这个查询是不合法的:
{
"valid" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
}
}
理解错误信息
explain
参数可以提供更多关于查询不合法的信息。
为了找出 查询不合法的原因,可以将 explain
参数 加到查询字符串中:
GET /gb/tweet/_validate/query?explain
{
"query": {
"tweet" : {
"match" : "really powerful"
}
}
}
按照字段的值排序
在这个案例中,通过时间来对 tweets 进行排序是有意义的,最新的 tweets 排在最前。 我们可以使用 sort
参数进行实现:
GET /_search
{
"query" : {
"bool" : {
"filter" : { "term" : { "user_id" : 1 }}
}
},
"sort": { "date": { "order": "desc" }}
}
多级排序
假定我们想要结合使用 date
和 _score
进行查询,并且匹配的结果首先按照日期排序,然后按照相关性排序:
GET /_search
{
"query" : {
"bool" : {
"must": { "match": { "tweet": "manage text search" }},
"filter" : { "term" : { "user_id" : 2 }}
}
},
"sort": [
{ "date": { "order": "desc" }},
{ "_score": { "order": "desc" }}
]
}
排序条件的顺序是很重要的。结果首先按第一个条件排序,仅当结果集的第一个 sort
值完全相同时才会按照第二个条件进行排序,以此类推。
多值字段的排序
一种情形是字段有多个值的排序, 需要记住这些值并没有固有的顺序;一个多值的字段仅仅是多个值的包装,这时应该选择哪个进行排序呢?
对于数字或日期,你可以将多值字段减为单值,这可以通过使用 min
、 max
、 avg
或是 sum
排序模式 。 例如你可以按照每个 date
字段中的最早日期进行排序,通过以下方法:
"sort": {
"dates": {
"order": "asc",
"mode": "min"
}
}
索引管理
创建索引
PUT /blogs
{
"settings" : {
"number_of_shards" : 3, //主分片个数
"number_of_replicas" : 1 //副本分片个数
}
}
PUT /my_index
{
"settings": { ... any settings ... },
"mappings": {
"type_one": { ... any mappings ... },
"type_two": { ... any mappings ... },
...
}
}
删除一个索引
用以下的请求来 删除索引:
DELETE /my_index
索引设置
你可以通过修改配置来自定义索引行为,详细配置参照 索引模块
Elasticsearch 提供了优化好的默认配置。 除非你理解这些配置的作用并且知道为什么要去修改,否则不要随意修改。
下面是两个 最重要的设置:
-
number_of_shards
每个索引的主分片数,默认值是
5
。这个配置在索引创建后不能修改。 -
number_of_replicas
每个主分片的副本数,默认值是
1
。对于活动的索引库,这个配置可以随时修改。
例如,我们可以创建只有 一个主分片,没有副本的小索引:
PUT /my_temp_index
{
"settings": {
"number_of_shards" : 1,
"number_of_replicas" : 0
}
}
然后,我们可以用 update-index-settings
API 动态修改副本数:
PUT /my_temp_index/_settings
{
"number_of_replicas": 1
}
配置分析器
第三个重要的索引设置是 analysis
部分,用来配置已存在的分析器或针对你的索引创建新的自定义分析器。
在 分析与分析器 ,我们介绍了一些内置的分析器,用于将全文字符串转换为适合搜索的倒排索引。
standard
分析器是用于全文字段的默认分析器,对于大部分西方语系来说是一个不错的选择。 它包括了以下几点:
standard
分词器,通过单词边界分割输入的文本。standard
语汇单元过滤器,目的是整理分词器触发的语汇单元(但是目前什么都没做)。lowercase
语汇单元过滤器,转换所有的语汇单元为小写。stop
语汇单元过滤器,删除停用词—对搜索相关性影响不大的常用词,如a
,the
,and
,is
。
默认情况下,停用词过滤器是被禁用的。如需启用它,你可以通过创建一个基于 standard
分析器的自定义分析器并设置 stopwords
参数。 可以给分析器提供一个停用词列表,或者告知使用一个基于特定语言的预定义停用词列表。
在下面的例子中,我们创建了一个新的分析器,叫做 es_std
, 并使用预定义的西班牙语停用词列表:
PUT /spanish_docs
{
"settings": {
"analysis": {
"analyzer": {
"es_std": {
"type": "standard",
"stopwords": "_spanish_"
}
}
}
}
}
## es_std 分析器不是全局的 它仅仅存在于我们定义的 spanish_docs 索引中。 为了使用 analyze API来对它进行测试,我们必须使用特定的索引名
查询字符串
因为string字符串类型的字段默认会分词。因此如果直接用字符串去查询,可能会查不到。因此需要用分词器去看一下查询条件被分词成哪些字段,这样才能预估查询的结果。es会根据字段的分词结果去倒排索引中去查询符合条件的doc
GET /my_store/_analyze
{
"field": "productID",
"text": "XHDK-A-1293-#fJ3"
}
"tokens" : [ {
"token" : "xhdk",
"start_offset" : 0,
"end_offset" : 4,
"type" : "<ALPHANUM>",
"position" : 1
}, {
"token" : "a",
"start_offset" : 5,
"end_offset" : 6,
"type" : "<ALPHANUM>",
"position" : 2
}, {
"token" : "1293",
"start_offset" : 7,
"end_offset" : 11,
"type" : "<NUM>",
"position" : 3
}, {
"token" : "fj3",
"start_offset" : 13,
"end_offset" : 16,
"type" : "<ALPHANUM>",
"position" : 4
} ]
}
解决string类型查询分词的这种问题 1
我们需要告诉 Elasticsearch 该字段具有精确值,要将其设置成 not_analyzed
无需分析的。 我们可以在 自定义字段映射 中查看它的用法。为了修正搜索结果,我们需要首先删除旧索引(因为它的映射不再正确)然后创建一个能正确映射的新索引:
DELETE /my_store
PUT /my_store
{
"mappings" : {
"products" : {
"properties" : {
"productID" : {
"type" : "string",
"index" : "not_analyzed"
}
}
}
}
}
- 删除索引是必须的,因为我们不能更新已存在的映射。
- 在索引被删除后,我们可以创建新的索引并为其指定自定义映射
- 这里我们告诉 Elasticsearch ,我们不想对
productID
做任何分析
解决string类型查询分词的这种问题 2
可以控制查询的属性包含,分词查询的所有所有分字段,这样也可以勉强解决
用 任意 查询词项匹配文档可能会导致结果中出现不相关的长尾。这是种散弹式搜索。可能我们只想搜索包含 所有 词项的文档,也就是说,不去匹配 brown OR dog
,而通过匹配 brown AND dog
找到所有文档。
match
查询还可以接受 operator
操作符作为输入参数,默认情况下该操作符是 or
。我们可以将它修改成 and
让所有指定词项都必须匹配:
GET /my_index/my_type/_search
{
"query": {
"match": {
"title": {
"query": "BROWN DOG!",
"operator": "and" // “or”
}
}
}
}
match
查询的结构需要做稍许调整才能使用 operator
操作符参数。这个查询可以把只包含要给分词的文档排除在外。
查询语句的优先级
我们可能对 title 和 author 两条语句更感兴趣,这样就需要调整查询,使 title 和 author 语句相对来说更重要。
在武器库中,最容易使用的就是 boost
参数。为了提升 title
和 author
字段的权重,为它们分配的 boost
值大于 1
:
GET /_search
{
"query": {
"bool": {
"should": [
{ "match": {
"title": {
"query": "War and Peace",
"boost": 2
}}},
{ "match": {
"author": {
"query": "Leo Tolstoy",
"boost": 2
}}},
{ "bool": {
"should": [
{ "match": { "translator": "Constance Garnett" }},
{ "match": { "translator": "Louise Maude" }}
]
}}
]
}
}
}
字段查询还可以加评分!!
更多高级查询,请见官网
https://www.elastic.co/guide/cn/elasticsearch/guide/current/partial-matching.html
前缀查询,正则表达式查询,短语查询,位置查询,越近越好?