es学习笔记

最新推荐文章于 2024-08-15 14:12:25 发布
最新推荐文章于 2024-08-15 14:12:25 发布
阅读量98 收藏 1
点赞数
文章标签： elasticsearch 笔记 大数据
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wm_true/article/details/131933506
版权

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

前缀查询，正则表达式查询，短语查询，位置查询，越近越好？

wm_true
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
ElasticSearch学习笔记
10-29
ElasticSearch学习笔记 ElasticSearch是基于Apache Lucene的搜索和数据分析引擎，提供了RESTful API用于数据的索引、搜索和分析。本笔记将对ElasticSearch的基本概念、架构、应用场景和实现细节进行详细介绍。 一...
Elasticsearch结构。倒排索引
灵魂和肉体总要有一个在路上
12-18 388
学习Elasticsearch就是为了解决大数据量的问题，无论是存储、查询、高可用等等问题都可以使用Elasticsearch来进行处理，因此Elasticsearch也可以变相的理解为非关系型数据库，因为它没表、没有所谓的关系，说白了还是存数据的 Elasticsearch可以搭建集群 倒排索引：根据数据查询id（如：Elasticsearch根据分词查询，他会根据关键字去分词区查询关键字对...
ElasticSearch 学习笔记
01-20
ElasticSearch 是一款强大的搜索引擎，基于 Lucene 构建，具备高效、可扩展的特性，广泛应用于日志分析、实时数据分析、全文检索等领域。本文主要介绍 ElasticSearch 的基础概念、核心功能以及一些重要机制。 首先...
elasticsearch学习笔记.rar
03-20
在"elasticsearch学习笔记.pdf"中，你将详细学习这些概念，并通过实际案例来加深理解，包括如何安装配置ES，创建和管理索引，执行搜索，以及进行高级操作如数据导入导出、监控和报警等。这将是你掌握Elasticsearch...
ElasticSearch学习笔记1
08-08
ElasticSearch学习笔记1 ElasticSearch是基于Lucene的搜索服务器，它提供了高性能的全文搜索功能，支持开箱即用的集群化扩展。ElasticSearch可以通过标准的REST API或特定于编程语言的客户端库与之交互。 一、什么...
ElasticSearch文档数据关联关系处理
qq_44027353的博客
08-15 628
再更新操作时，对象类型和嵌套对象nested方式有一个问题，因为根对象和嵌套对象本质上它们还是存在一个文档中的，每次更新时就可以需要重新索引整个文档。ES提供了父子关联关系，通过维护parent/child的关系，分离它们，使父文档和子文档是两个独立的文档，更新其中一个文档不会影响另一个文档。创建子文档时，必须通过routing指定父文档id，保证父子文档在一个shard中，提高join查询性能。user字段如果保存的是一个对象数组，在搜索时添加两个查询条件，数组中两个对象分别满足一个条件。
Spring Cloud 动态配置的魔法：实时更新的秘诀
2401_85342379的博客
08-11 517
通过Spring Cloud Config Server实现的动态配置更新，我们能够为微服务架构带来更高的灵活性和更低的维护成本。掌握这一魔法，将使开发者在面对配置变更时更加从容不迫，确保服务的稳定性和响应性。动态配置更新不仅是技术的进步，更是微服务治理理念的体现。通过本文的深入分析和代码示例，读者应该对Spring Cloud如何实现服务的动态配置更新有了清晰的认识。希望本文能够帮助读者在自己的项目中有效地应用这一功能，提升系统的动态性和健壮性。
git常用操作大全
Black.Spider的博客
08-12 444
1. git diff 不接参数，顺序展示多个文件的差异内容（和暂存区内容对比）； 接参数filename，展示指定文件的差异内容（和暂存区内容对比）； 接参数–cached，暂存区和本地仓库进行对比。 2. git checkout -b [branch_name] 创建一个新的本地分支 3. git branch -vv 查看本地分支的跟踪情况 4. git branch -a 查看所有分支（包括远程分支） 5. git branch -D [branch_name] 删除本地分支
Elasticsearch 搜索高亮功能及示例
一起coding，一起嗨。
08-12 372
Elasticsearch 搜索高亮功能及示例
Elasticsearch 排序机制详解
一起coding，一起嗨。
08-12 444
Elasticsearch 排序机制详解
排序算法之基数排序
rd_w_csdn的博客
08-12 942
基数排序（radix sort）的核心思想与计数排序一致，也通过统计个数来实现排序。在此基础上，基数排序利用数字各位之间的递进关系，依次对每一位进行排序，从而得到最终的排序结果。
ElasticSearch数据建模
最新发布
qq_44027353的博客
08-15 568
此时如果计算平均值那么结果是(100+99+98)/3 ，但是我们期望的是(100+99+98+0+0)/5。案例：针对版本号的搜索，我们一般会对版本号进行模糊查询，优化方式将一个版本号字段变为保存Object对象类型，其实就是拆分为多个字段，字段的值如果为null，那么就会导致对该字段进行聚合操作得到的结果不准确。正则，通配符查询，前缀查询属于Term查询，但是性能不够好。对于多属性的字段，比如cookie，商品属性，可以考虑使用Nested。一个文档中，最好避免大量的字段。
Elasticsearch 综合搜索案例解析
一起coding，一起嗨。
08-12 544
Elasticsearch 综合搜索案例解析
解决 Kibana 中的 “Invalid character in header content” 错误
一起coding，一起嗨。
08-14 239
解决 Kibana 中的 “Invalid character in header content” 错误
Elasticsearch中的自动补全功能详解与实践
一起coding，一起嗨。
08-14 389
Elasticsearch中的自动补全功能详解与实践
Elasticsearch 度量（Metric）聚合详解及示例
一起coding，一起嗨。
08-13 429
Elasticsearch 度量（Metric）聚合详解及示例
简单了解一下 git reset
weixin_52648900的博客
08-12 580
介绍git reset --soft、--mixed、--hard的区别和用法
使用 Elasticsearch RestHighLevelClient 进行查询
一起coding，一起嗨。
08-12 512
使用 Elasticsearch RestHighLevelClient 进行查询
Elasticsearch 桶（Bucket）聚合详解及示例
一起coding，一起嗨。
08-13 338
Elasticsearch 桶（Bucket）聚合详解及示例
elasticsearch 学习笔记
08-19
elasticsearch 学习笔记包括以下内容: 一、Elasticsearch概述: - Elasticsearch是一种开源的分布式搜索和分析引擎，可以用于快速搜索、分析和存储大量的结构化和非结构化数据。 - Elasticsearch与Solr相比有一些区别，包括用户、开发和贡献者社区的规模和成熟度等方面。 二、Elasticsearch安装: 1. 下载Elasticsearch，可以从官方网站或华为云镜像下载。 2. 安装Elasticsearch。 三、安装head插件: - head插件是一个可视化的管理界面，可以方便地管理和监控Elasticsearch集群。 四、安装Kibana: 1. Kibana是一个开源的数据可视化工具，用于展示和分析Elasticsearch中的数据。 2. 下载Kibana并安装。 3. 启动Kibana并进行访问测试。 4. 可选的汉化操作。 五、ES核心概念理解: - 学习ES的核心概念，包括索引、文档、映射、查询等。 以上是elasticsearch学习笔记的主要内容，希望对你有帮助。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [Elasticsearch 学习笔记（上）](https://blog.csdn.net/m0_52691962/article/details/127064350)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值