elasticsearch-基础篇-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_22271479/article/details/88082292

本文详细介绍了Elasticsearch的基础知识，包括乐观并发控制、文档更新、批量操作、搜索语法、索引管理和性能优化技巧。涵盖了从单文档操作到大规模数据处理的各个方面，适合初学者和进阶用户学习。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

elasticsearch学习-基础篇

以下内容全部是来自https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html

乐观并发控制

通过version字段来解决更新丢失的问题

PUT /es_test/employee/2?version=2
{
  "first_name": "John2",
    "last_name": "Smith",
    "age": 30,
    "about": "I love to go rock climbing",
    "interests": [
      "sports",
      "music"
    ]
}

文档的整个更新和部分更新

整个更新

从旧文档构建 JSON
更改该 JSON
删除旧文档
索引一个新文档

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "I am starting to get the hang of this...",
  "date":  "2014/01/02"
}

更新部分文档

//这个version是用来防止 更新丢失 的，可以不要
POST /es_test/employee/8?version=6
{
   "doc":{
    "tags":"d"
  }
}

合并多条请求

直接通过匹配index->type->id

{
   "docs" : [
      {
         "_index" : "website",
         "_type" :  "blog",
         "_id" :    2
      },
      {
         "_index" : "website",
         "_type" :  "pageviews",
         "_id" :    1,
         "_source": "views"
      }
   ]
}

可以通过覆盖的方式

GET /website/blog/_mget
{
   "docs" : [
      { "_id" : 2 },
      { "_type" : "pageviews", "_id" :   1 }
   ]
}

//index 和 type都省略了
GET /website/blog/_mget
{
   "ids" : [ "2", "1" ]
}

bulk

测试环境
linux centOS7 4G 12线程

数据量	时间
1000	128ms
10000	2979ms
1000000	83161ms

一种

POST /_bulk
{ "delete": { "_index": "website", "_type": "blog", "_id": "123" }} 
{ "create": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "title":    "My first blog post" }
{ "index":  { "_index": "website", "_type": "blog" }}
{ "title":    "My second blog post" }
{ "update": { "_index": "website", "_type": "blog", "_id": "123", "_retry_on_conflict" : 3} }
{ "doc" : {"title" : "My updated blog post"} }

公用的index，type

POST /website/log/_bulk
{ "index": {}}
{ "event": "User logged in" }
{ "index": { "_type": "blog" }}
{ "title": "Overriding the default type" }

当我们早些时候在代价较小的批量操作章节了解批量请求时，您可能会问自己， “为什么 bulk API 需要有换行符的有趣格式，而不是发送包装在 JSON 数组中的请求，例如 mget API？” 。

为了回答这一点，我们需要解释一点背景：在批量请求中引用的每个文档可能属于不同的主分片，每个文档可能被分配给集群中的任何节点。这意味着批量请求 bulk 中的每个操作都需要被转发到正确节点上的正确分片。

如果单个请求被包装在 JSON 数组中，那就意味着我们需要执行以下操作：

将 JSON 解析为数组（包括文档数据，可以非常大）
查看每个请求以确定应该去哪个分片
为每个分片创建一个请求数组
将这些数组序列化为内部传输格式
将请求发送到每个分片
这是可行的，但需要大量的 RAM 来存储原本相同的数据的副本，并将创建更多的数据结构，Java虚拟机（JVM）将不得不花费时间进行垃圾回收。

相反，Elasticsearch可以直接读取被网络缓冲区接收的原始数据。它使用换行符字符来识别和解析小的 action/metadata 行来决定哪个分片应该处理每个请求。

这些原始请求会被直接转发到正确的分片。没有冗余的数据复制，没有浪费的数据结构。整个请求尽可能在最小的内存中处理。

GET /_search?timeout=10ms

应当注意的是 timeout 不是停止执行查询，它仅仅是告知正在协调的节点返回到目前为止收集的结果并且关闭连接。在后台，其他的分片可能仍在执行查询即使是结果已经被发送了。
使用超时是因为 SLA(服务等级协议)对你是很重要的，而不是因为想去中止长时间运行的查询

锁索引和多类型

/_search
在所有的索引中搜索所有的类型
/gb/_search
在 gb 索引中搜索所有的类型
/gb,us/_search
在 gb 和 us 索引中搜索所有的文档
/g*,u*/_search
在任何以 g 或者 u 开头的索引中搜索所有的类型
/gb/user/_search
在 gb 索引中搜索 user 类型
/gb,us/user,tweet/_search
在 gb 和 us 索引中搜索 user 和 tweet 类型
/_all/user,tweet/_search
在所有的索引中搜索 user 和 tweet 类型
##

分页

1-3页

GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10

在分布式系统中深度分页

理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页–结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。

分析器

字符过滤器

首先，字符串按顺序通过每个字符过滤器。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成 and。

分词器

其次，字符串被分词器分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。

token过滤器

最后，词条按顺序通过每个 token 过滤器。这个过程可能会改变词条（例如，小写化 Quick ），删除词条（例如，像 a，and，the 等无用词），或者增加词条（例如，像 jump 和 leap 这种同义词）。

GET _analyze
{
  "analyzer": "standard",

  "text": ["my name is ii"]
  
}

映射

{
  "gb": {
    "tweet": { 
      "properties": {
        "tweet":            { "type": "string" },
        "user": { 
          "type":             "object",
          "properties": {
            "id":           { "type": "string" },
            "gender":       { "type": "string" },
            "age":          { "type": "long"   },
            "name":   { 
              "type":         "object",
              "properties": {
                "full":     { "type": "string" },
                "first":    { "type": "string" },
                "last":     { "type": "string" }
              }
            }
          }
        }
      }
    }
  }
}

Lucene 不理解内部对象。 Lucene 文档是由一组键值对列表组成的。为了能让 Elasticsearch 有效地索引内部类，它把我们的文档转化成这样：

{
    "tweet":            [elasticsearch, flexible, very],
    "user.id":          [@johnsmith],
    "user.gender":      [male],
    "user.age":         [26],
    "user.name.full":   [john, smith],
    "user.name.first":  [john],
    "user.name.last":   [smith]
}
内部域 可以通过名称引用（例如， first ）。为了区分同名的两个域，我们可以使用全 路径 （例如， user.name.first ） 或 type 名加路径（ tweet.user.name.first ）。

注意
在前面简单扁平的文档中，没有 user 和 user.name 域。Lucene 索引只有标量和简单值，没有复杂数据结构。

内部对象数组编辑
最后，考虑包含 内部对象的数组是如何被索引的。 假设我们有个 followers 数组：

{
    "followers": [
        { "age": 35, "name": "Mary White"},
        { "age": 26, "name": "Alex Jones"},
        { "age": 19, "name": "Lisa Smith"}
    ]
}
这个文档会像我们之前描述的那样被扁平化处理，结果如下所示：

{
    "followers.age":    [19, 26, 35],
    "followers.name":   [alex, jones, lisa, smith, mary, white]
}
{age: 35} 和 {name: Mary White} 之间的相关性已经丢失了，因为每个多值域只是一包无序的值，而不是有序数组。这足以让我们问，“有一个26岁的追随者？”

查询

GET /_search
{
    "query": {
        "match_all": {}
    }
}

GET /_search
{
    "query": {
        "match": {
            "tweet": "elasticsearch"
        }
    }
}

组合查询

{
    "bool": {
        "must":     { "match": { "title": "how to make millions" }},
        "must_not": { "match": { "tag":   "spam" }},
        "should": [
            { "match": { "tag": "starred" }},
            { "range": { "date": { "gte": "2014-01-01" }}}
        ]
    }
}
提示
如果没有 must 语句，那么至少需要能够匹配其中的一条 should 语句。但，如果存在至少一条 must 语句，则对 should 语句的匹配没有要求。

如果我们不想因为文档的时间而影响得分，可以用 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" }} 
        }
    }
}

gt
大于

gte
大于等于

lt
小于

lte
小于等于

通过将 range 查询移到 filter 语句中，我们将它转成不评分的查询，将不再影响文档的相关性排名。由于它现在是一个不评分的查询，可以使用各种对 filter 查询有效的优化手段来提升性能。

所有查询都可以借鉴这种方式。将查询移到 bool 查询的 filter 语句中，这样它就自动的转成一个不评分的 filter 了。

如果你需要通过多个不同的标准来过滤你的文档，bool 查询本身也可以被用做不评分的查询。简单地将它放置到 filter 语句中并在内部构建布尔逻辑：

{
    "bool": {
        "must":     { "match": { "title": "how to make millions" }},
        "must_not": { "match": { "tag":   "spam" }},
        "should": [
            { "match": { "tag": "starred" }}
        ],
        "filter": {
          "bool": { 
              "must": [
                  { "range": { "date": { "gte": "2014-01-01" }}},
                  { "range": { "price": { "lte": 29.99 }}}
              ],
              "must_not": [
                  { "term": { "category": "ebooks" }}
              ]
          }
        }
    }
}
拷贝为 CURL在 SENSE 中查看 


将 bool 查询包裹在 filter 语句中，我们可以在过滤标准中增加布尔逻辑

通过混合布尔查询，我们可以在我们的查询请求中灵活地编写 scoring 和 filtering 查询逻辑。

constant_score查询

尽管没有 bool 查询使用这么频繁，constant_score 查询也是你工具箱里有用的查询工具。它将一个不变的常量评分应用于所有匹配的文档。它被经常用于你只需要执行一个 filter 而没有其它查询（例如，评分查询）的情况下。

可以使用它来取代只有 filter 语句的 bool 查询。在性能上是完全相同的，但对于提高查询简洁性和清晰度有很大帮助。


{
    "constant_score":   {
        "filter": {
            "term": { "category": "ebooks" } 
        }
    }
}

验证查询

GET /es_test/employee/_validate/query
{
  "query": {
    "match": {
      "about.keyword": "测试呢"
    }
  }
}

排序

多级排序编辑
假定我们想要结合使用 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 值完全相同时才会按照第二个条件进行排序，以此类推。

多级排序并不一定包含 _score 。你可以根据一些不同的字段进行排序，如地理距离或是脚本计算的特定值。

多值排序

一种情形是字段有多个值的排序， 需要记住这些值并没有固有的顺序；一个多值的字段仅仅是多个值的包装，这时应该选择哪个进行排序呢？

对于数字或日期，你可以将多值字段减为单值，这可以通过使用 min 、 max 、 avg 或是 sum 排序模式 。 例如你可以按照每个 date 字段中的最早日期进行排序，通过以下方法：

"sort": {
    "dates": {
        "order": "asc",
        "mode":  "min"
    }
}

Bouncing Results

想象一下有两个文档有同样值的时间戳字段，搜索结果用 timestamp 字段来排序。由于搜索请求是在所有有效的分片副本间轮询的，那就有可能发生主分片处理请求时，这两个文档是一种顺序，而副本分片处理请求时又是另一种顺序。

这就是所谓的 bouncing results 问题: 每次用户刷新页面，搜索结果表现是不同的顺序。让同一个用户始终使用同一个分片，这样可以避免这种问题，可以设置 preference 参数为一个特定的任意值比如用户会话ID来解决。

游标

//第一次
GET /es_test/employee/_search?scroll=1s
{
    "query": { "match_all": {}},
    "sort" : ["_doc"], 
    "size":  10000
}

//第二次
GET /_search/scroll
{
    "scroll":"1m",
    "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAADyzFm4teVJpYWtjU1hhOXY2a1dzQjBZd1EAAAAAAAA8tBZuLXlSaWFrY1NYYTl2NmtXc0IwWXdRAAAAAAAAPLIWbi15Umlha2NTWGE5djZrV3NCMFl3UQAAAAAAADy1Fm4teVJpYWtjU1hhOXY2a1dzQjBZd1EAAAAAAAA8thZuLXlSaWFrY1NYYTl2NmtXc0IwWXdR"
}

创建索引

PUT /my_index
{
    "settings": { ... any settings ... },
    "mappings": {
        "type_one": { ... any mappings ... },
        "type_two": { ... any mappings ... },
        ...
    }
}

如果你想禁止自动创建索引，你可以通过在 config/elasticsearch.yml 的每个节点下添加下面的配置：

action.auto_create_index: false

删除索引

用以下的请求来 删除索引:

DELETE /my_index
你也可以这样删除多个索引：

DELETE /index_one,index_two
DELETE /index_*
你甚至可以这样删除 全部 索引：

DELETE /_all
DELETE /*

对一些人来说，能够用单个命令来删除所有数据可能会导致可怕的后果。如果你想要避免意外的大量删除, 这个设置使删除只限于特定名称指向的数据, 而不允许通过指定 _all 或通配符来删除指定索引库。你同样可以通过 Cluster State API 动态的更新这个设置。
你可以在你的 elasticsearch.yml 做如下配置：

action.destructive_requires_name: true

索引设置（setting）

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
}

配置分析器

standard 分词器，通过单词边界分割输入的文本。
standard 语汇单元过滤器，目的是整理分词器触发的语汇单元（但是目前什么都没做）。
lowercase 语汇单元过滤器，转换所有的语汇单元为小写。
stop 语汇单元过滤器，删除停用词–对搜索相关性影响不大的常用词，如 a ， the ， and ， is

PUT /spanish_docs
{
    "settings": {
        "analysis": {
            "analyzer": {
                "es_std": {
                    "type":      "standard",
                    "stopwords": "_spanish_"
                }
            }
        }
    }
}

该分析器不是全局的，是属于索引spanish_docs的

自定义分析器


PUT /my_index
{
    "settings": {
        "analysis": {
            //自定义 字符过滤器
            "char_filter": { ... custom character filters ... },
            //自定义 分词器
            "tokenizer":   { ...    custom tokenizers     ... },
            //自定义token过滤器
            "filter":      { ...   custom token filters   ... },
            //分析器
            "analyzer":    { ...    custom analyzers      ... }
        }
    }
}

PUT /my_index
{
    "settings": {
        "analysis": {
            //字符过滤器
            "char_filter": {
                "&_to_and": {
                    "type":       "mapping",
                    "mappings": [ "&=> and "]
            }},
            //token过滤器
            "filter": {
                "my_stopwords": {
                    "type":       "stop",
                    "stopwords": [ "the", "a" ]
            }},
            //分析器
            "analyzer": {
                "my_analyzer": {
                    "type":         "custom",
                    "char_filter":  [ "html_strip", "&_to_and" ],
                    "tokenizer":    "standard",
                    "filter":       [ "lowercase", "my_stopwords" ]
            }}
}}}

//指定分析器
GET /es_a/_analyze
{
  "analyzer": "yzz_analyzer", 
  "text": [" & and hhh "]
}

类型

在lucen中类型在一个索引中是全局的，字段必须唯一，不能模棱两可

技术上讲，多个类型可以在相同的索引中存在，只要它们的字段不冲突（要么因为字段是互为独占模式，要么因为它们共享相同的字段）。

重要的一点是: 类型可以很好的区分同一个集合中的不同细分。在不同的细分中数据的整体模式是相同的（或相似的）。

类型不适合完全不同类型的数据。如果两个类型的字段集是互不相同的，这就意味着索引中将有一半的数据是空的（字段将是稀疏的），最终将导致性能问题。在这种情况下，最好是使用两个单独的索引

动态映射

当 Elasticsearch 遇到文档中以前未遇到的字段，它用 dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射。

有时这是想要的行为有时又不希望这样。通常没有人知道以后会有什么新字段加到文档，但是又希望这些字段被自动的索引。也许你只想忽略它们。如果Elasticsearch是作为重要的数据存储，可能就会期望遇到新字段就会抛出异常，这样能及时发现问题。

幸运的是可以用 dynamic 配置来控制这种行为，可接受的选项如下：

true
动态添加新的字段–缺省
false
忽略新的字段
strict
如果遇到新字段抛出异常
配置参数 dynamic 可以用在根 object 或任何 object 类型的字段上。你可以将 dynamic 的默认值设置为 strict , 而只在指定的内部对象中开启它, 例如：

PUT /my_index
{
    "mappings": {
        "my_type": {
            "dynamic":      "strict", 
            "properties": {
                "title":  { "type": "string"},
                "stash":  {
                    "type":     "object",
                    "dynamic":  true 
                }
            }
        }
    }
}

动态映射

# 关闭日期自检
PUT /my_index
{
    "mappings": {
        "my_type": {
            "date_detection": false
        }
    }
}

PUT /my_index
{
    "mappings": {
        "my_type": {
            "dynamic_templates": [
                { "es": {
                      "match":              "*_es", 
                      "match_mapping_type": "string",
                      "mapping": {
                          "type":           "string",
                          "analyzer":       "spanish"
                      }
                }},
                { "en": {
                      "match":              "*", 
                      "match_mapping_type": "string",
                      "mapping": {
                          "type":           "string",
                          "analyzer":       "english"
                      }
                }}
            ]
}}}

缺省映射

通常，一个索引中的所有类型共享相同的字段和设置。 default 映射更加方便地指定通用设置，而不是每次创建新类型时都要重复设置。 default 映射是新类型的模板。在设置 default 映射之后创建的所有类型都将应用这些缺省的设置，除非类型在自己的映射中明确覆盖这些设置。

PUT /my_index
{
    "mappings": {
        "_default_": {
            "_all": { "enabled":  false }
        },
        "blog": {
            "_all": { "enabled":  true  }
        }
    }
}

索引重建

通过reindex函数来操作

POST _reindex
{
  "source": {
    "index": "es_test"
  },
  "dest": {"index": "es_yzz"}
}

索引迁移

POST /_aliases
{
    "actions": [
        { "remove": { "index": "my_index_v1", "alias": "my_index" }},
        { "add":    { "index": "my_index_v2", "alias": "my_index" }}
    ]
}

参考文章

https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html