Elasticsearch 快速开始

头像
波罗学
    阅读 16 分钟
    2

    前言

    本文非完全直译译文，主要参考的的是 elasticsearch 6.5 版的官网文档 Getting Started，可以把这篇文章理解为个人学习笔记，我力求详略得当吧。

    文末会附上 Getting Started 阅读梳理的思维导图。

    为了能更加轻松地进入 elasticsearch 的世界，本文将先从基础角度给介绍了 es 的使用。

    什么是 elasticsearch

    Elasticsearch 是一款开源的全文搜索与分析引擎，它拥有高扩展、大容量数据的存储和处理特性，有着近乎实时的处理效果。elasticsearch 的使用场景还是比较多的，比如 APP 的搜索服务、ELK 实现日志收集与分析、BI 商业智能等。

    本文会逐步引导大家进入 elasticsearch 的世界，初步窥探它的使用。相关内容涉及如下：

    • 了解 elasticsearch 的一些基础但非常核心的概念，比如集群、节点、索引、分片和副本；
    • 学会 elasticsearch 安装与启动，同时为了便于测试，顺带也介绍了 Kibana 的安装启动；
    • 探索集群，介绍集群涉及的一些基础操作，比如健康状态检查、集群节点检查，索引创建等；
    • 更新数据，包括如何进行文档替换、更新，以及如何进行删除，最后通过批处理可以将多个操作组合起来；
    • 数据探索，主要是与搜索和聚合分析相关，介绍了常用的一些搜索 API、Query DSL 和聚合 API 的使用；

    整体上的内容还是比较多的。

    了解一些基础概念

    Elasticsearch 中有一些基础但很核心的概念需要我们提前了解，它们对我们的学习将起到很大帮助。

    具体是哪些概念呢？

    • 近实时
    • 集群
    • 节点
    • 索引
    • 类型
    • 文档
    • 分片副本

    下面我们将逐一介绍。

    近实时

    什么是近实时？

    它表示一个文档从被索引（存储使文档可搜索）到真正能被搜索之间有一个短暂的延迟，而非实时，这个延迟默认是 1 秒。当然，默认延迟可以修改的。

    集群

    集群是节点的集合。

    集群实现了在多节点上进行大容量数据存储和搜索的能力。每个集群都拥有唯一名称，而节点正是根据集群的名称决定是否加入某个集群。不同环境的集群的名称不能相同，如开发、测试、线上三套环境，集群可分别命名为 logging-dev、logging-test、logging-prod。

    节点

    节点，集群组成的一部分，负责具体的事务处理，比如数据存储、文档索引、搜索执行等。节点也有唯一个名称，如果没有指定将随机生成。

    节点可通过配置集群名称，指定加入哪个集群，节点默认的集群名称是 elasticsearch。如果我们在一个网络环境下启动多个节点，并且它们之间可以相互发现，就将会自动组织一个名称为 elasticsearch 的集群。

    索引

    索引是一系列相似文档的集合，例如，我们把客户信息存放到一个索引，订单信息存储到另一个索引中。索引可通过名称识别，名称必须小写。当操作文档时，我们需要通过索引名称指定。

    索引的数量，集群中并没有限制定义索引的数量。

    类型

    elasticsearch 6.0 已丢弃功能，不具体介绍了。

    有一点需要注意，为与老版本兼容，该功能暂未彻底移除，当前一个索引仍可设置类型，但当前只能指定一个类型。一般情况下，我们设置一个固定 type 即可，比如 _doc。

    文档

    被索引的基础信息单元，比如一个客户、一件产品、或是一笔订单。文档可用 JSON 形式表示，它是一种非常普遍的数据交换格式。索引中，我们可以存放任意数量的文档。

    分片与副本

    分片和副本是 elasticsearch 非常核心的概念。

    我们知道，elasticsearch 存储的数据量能突破单个硬件的限制，数据处理速度有着近实时的水平。这些都和分片和副本有着很大关系。

    分片实现了索引文档分散分布，并且每个切片都是功能完善的，索引是独立的，可能分布在集群中的任意节点。分片的重要性主要体现在使 elasticsearch 存储容量的水平扩展和分布式并行处理都成为了现实。

    副本提高了 elasticsearch 的容错能力。网络环境下，异常随时可能发生，比如一些节点或分片从网络中消失。一旦设置了副本，索引就会同时拥有主分片和副本分片。一旦某个分片发生异常，还有其他分片可替代。而且，副本也可以提高请求的处理速度，一个分片上的副本可同时并行处理多个请求。

    一句话简述，每个索引可以由多个分片组成，而每个分片也可以拥有多个副本。

    介绍完了核心概念，是否已经开始蠢蠢欲动了？开始安装自己的集群吧。

    安装与启动

    本节主要介绍 elasticsearch 的安装。另外，由于要使用 kibana 的 devtools 控制台，将也会介绍下 kibana 的安装。

    安装 elasticsearch

    首先安装依赖，elasticsearch 是 Java 开发，6.5 版依赖 Java 8，建议安装 Oracle JDK 1.8.0_131。Java 安装完成后，就可以开始安装 elasticsearch 了。

    简单起见，我们只介绍二进制包的安装。

    安装过程仅仅三步搞定！

    $ curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.4.tar.gz
$ tar -xvf elasticsearch-6.5.4.tar.gz
$ cd elasticsearch-6.5.4/bin
$ ./elasticsearch -d # -d 表示后台启动

    安装启动完成后，可通过访问 localhost:9200 确认下实例运行是否正常。

    如果想了解 Mac 的 homebrew 安装或 windows 下的 MSI Installer Package 安装，可自行阅读官方文档。

    安装 kibana

    Kibana 的安装与 elasticsearch 的不同，需要区别不同的平台系统。本节将介绍 Mac 与 Linux 下的安装，它们都可以通过下载对应系统的 tar 包完成。

    Linux 系统，我们以 Linux x86_64 为例。安装命令如下：

    $ wget https://artifacts.elastic.co/downloads/kibana/kibana-6.5.4-linux-x86_64.tar.gz
$ shasum -a 512 kibana-6.5.4-linux-x86_64.tar.gz 
$ tar -xzf kibana-6.5.4-linux-x86_64.tar.gz
$ cd kibana-6.5.4-linux-x86_64/
$ ./bin/kibana

    MacOS 系统，安装命令如下：

    $ curl -O https://artifacts.elastic.co/downloads/kibana/kibana-6.5.4-darwin-x86_64.tar.gz
$ shasum -a 512 kibana-6.5.4-darwin-x86_64.tar.gz 
$ tar -xzf kibana-6.5.4-darwin-x86_64.tar.gz
$ cd kibana-6.5.4-darwin-x86_64/ 
$ ./bin/kibana

    如果希望 kibana 在后台运行，可以通过 nohup 实现。完成后，访问 localhost:5601 下确认状态，它会默认连接本地启动的 elasticsearch 集群。

    好吧！我还是不想介绍 Windows 下的安装。

    多节点集群

    如果希望启动一个多节点集群，我们可以修改下启动命令，在本地同时启动两个节点，集群名称相同情况下，它们将会自动组织成一个新的集群。命令如下：

    $ ./bin/elasticsearch -Ecluster.name=cluster_dev -Epath.data=cluster_node01 -Enode.name=node01 -Ehttp.port=9200 -d
$ ./bin/elasticsearch -Ecluster.name=cluster_dev -Epath.data=cluster_node02 -Enode.name=node02 -Ehttp.port=9201 -d

    启动成功后，可以进入 kibana 的 devtool 执行 _cat/nodes?v，输出如下：

    ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           29          75   6    3.31                  mdi       -      node01
127.0.0.1           33          75   6    3.31                  mdi       *      node02

    我们将会看到集群中已经有了两个节点。

    探索集群

    经历了前面几步，elasticsearch 集群已经安装完成，但我们要如何与它交流呢？其实，elasticsearch 已经提供了一套全面且功能强大的 REST API，用于与集群交互。REST API 涉及功能包括：

    • 检查集群、节点和索引的健康情况、状态以及统计信息；
    • 管理集群、节点、索引和元数据；
    • 针对索引的增删改查以及搜索 API；
    • 高级搜索功能，比如分页、排序、过滤、脚本处理、聚合等；

    本节我们将简单介绍上面提到的部分 API。

    集群健康检查

    健康检查可以让我们了解集群当前状态，可通过 _cat API 实现。

    示例如下：

    GET /_cat/health?v

    输出结果：

    epoch      timestamp cluster     status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1565884060 23:47:40  cluster_dev green           2         2     22  21    0    0        0             0                  -                100.0%

    输出结果显示，集群名称为 cluster_dev，状态是 green，当前集群有 2 个节点。

    先重点讲讲 green 究竟代表什么意思？

    首先，green 表示的是集群的状态，对应字段名称是 status，共有三种状态，分别是 green、yellow 和 red。

    • Green 表示集群运行完全正常（主分片和副本分片都运行正常）；
    • Yellow 表示所有主分片可用，但副本没有完全分配；
    • Red 部分数据完全不可用，即无论主分片和副本都非正常运作；

    当集群状态是 red 时，仍然可以接收处理搜索请求，但我们需要立刻修复它。

    查看集群节点

    通过 _cat/nodes，可以列出当前集群下的所有节点，前面在启动一个多节点集群时，我们已经过了使用该 API，不多介绍了。

    列出所有索引

    _cat/indices?v 能列出集群中的所有索引。说明一下，indices 是 index 的复数形式。

    GET _cat/indices

    输出如下：

    health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   us_tweet WXkAeMEvR0eukVOFOM1q3w   5   0          6            0     15.7kb         15.7kb
green  open   gb_user  pbOu0n0XQ96mouQ642eutQ   5   0          1            0      5.7kb          5.7kb
green  open   us_user  idxuhX0LQlekzfbjd6kB5w   5   0          1            0      5.7kb          5.7kb
green  open   gb_tweet SJTleUerT5CaO9Sl-JwIQg   5   0          6            0     15.7kb         15.7kb

    我的本地集群经常拿来测试，所以这里会看到已经有很多 index，对于你刚搭建好的集群，输出肯定就是空的。

    创建索引

    接下来，我们学习下如何创建索引，直接看示例吧。尝试创建一个名为 "customer" 的索引，如下：

    PUT customer?pretty

    PUT 加上索引名称即可。 customer 索引成功创建后，查看下集群当前索引列表，如下：

    GET _cat/indices

    输出结果如下：

    health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
...
green  open   customer 71RYoldbQ6uXMo56t4bSog   5   1          0            0      1.1kb           460b
...

    customer 成功创建，包含 5 个主分片和 1 个副本分片，索引中当前的文档数量为 0，索引状态为 green。

    索引的状态和集群一样，也是 green、yellow 和 red 这 3 个值，并且含义与集群状态类似。green 是全功能正常，yellow 表示副本未完全分配，red 表示部分主分片不可用。我们可以测试一下，停止集群中的一个节点，这时 customer 的状态将会马上切换为 yellow 状态。

    索引和查询文档

    在 elasticsearch 中，"索引" 这个名词常常会搞晕我们。一般讲到索引，主要是指它的名词含义，比如我们说，创建一个 customer 索引。但有时，它又是动词，比如我们在增加和更新文档时，常会说索引一个文档，在这种情况下，可以把它理解为存储文档并使其可搜索。

    那如何索引一个文档呢？比如，索引一个 ID 为 1 的 customer 文档到 customer 索引中，如下。

    PUT /customer/_doc/1?pretty
{
  "name": "John Doe"
}

    响应返回：

    {
  "_index" : "customer",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

    结果表明，我们已经成功创建一个 ID 为 1 的文档。从这里也能看出，在索引一个文档之前，并不要求我们明确创建索引 customer，如果 customer 索引不存在，elasticsearch 将会自动帮助我们创建索引。

    检索刚才索引的文档。

    GET /customer/_doc/1?pretty

    响应如下：

    {
  "_index" : "customer",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "found" : true,
  "_source" : { "name": "John Doe" }
}

    found 字段表明，我们已经成功检索到了一个 ID 为 1 的文档。_source 中的内容是检索文档的完整内容。

    删除索引

    让我们删除掉刚刚创建的索引。

    DELETE /customer?pretty

    如此，我们就成功删除了之前创建的 customer。如果不确定，可以使用 GET _cat/indices 检查下。

    文档 API

    回顾下前面介绍的那些 API，我们重新再走一遍。

    PUT /customer
PUT /customer/_doc/1
{
  "name": "John Doe"
}
GET /customer/_doc/1
DELETE /customer

    仔细观察上面的命令，你可能会发现一个比较通用的模式，如下：

    <HTTP Verb> /<Index>/<Type>/<ID>

    这个模式在 elasticsearch 中非常普遍，记住它，这将对 elasticsearch 学习之旅将会非常有帮助。

    更新数据

    区别于传统关系型数据库的实时性特点，elasticsearch 是近实时的，也就是说，在文档被 create/update/delete 与搜索结果中出现之间将会有 1 秒的延迟。

    文档替换

    创建和替换文档本质上都属于索引文档，因而，我们之前用来创建文档的命令同样适用于文档替换。

    因为 customer 索引重建过，我们重新创建一个 ID 为 1 的文档。如下：

    PUT /customer/_doc/1?pretty
{
  "name": "John Doe"
}

    同样的命令即可实现文档更新，我们只需要传递不同的文档内容即可，如下：

    PUT /customer/_doc/1?pretty
{
  "name": "Jane Doe"
}

    将 ID 为 1 的文档中 name 由 Johh Doe 更新为 Jane Doe。如果指定 ID 文档不存在，将会创建新的文档，否则更新当前文档。

    比如，ID 为 2 的文档不存在，通过如下命令创建。

    PUT /customer/_doc/2?pretty
{
  "name": "Jane Doe"
}

    索引文档时，ID 不是必须的，如果不指定，elasticsearch 会自动为这个文档指定一个随机的 ID，并作为响应的一部分返回给你。

    示例如下：

    POST /customer/_doc?pretty
{
  "name": "Jane Doe"
}

    这种情况下，我们需要使用 POST 代替 PUT 提交请求。

    响应结果：

    {
  "_index": "customer",
  "_type": "_doc",
  "_id": "Z-RnpGwBe6KTDC6t3MGV",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

    上面可以看到 elasticsearch 为我们生成的文档 ID，Z-RnpGwBe6KTDC6t3MGV。

    更新文档

    说完文档的索引和替换，我们再来谈谈文档的更新。提前说明，elasticsearch 并非真的去更新文档，它的更新操作与替换类似，包含删除旧文档和索引新文档两个操作。

    示例演示，更新前面创建的 ID 为 1 的文档，更新 name 字段为 Jane Doe。

    POST /customer/_doc/1/_update?pretty
{
  "doc": { "name": "Jane Doe" }
}

    示例 2，更新 name 为 Jane Doe 的同时，增加一个字段 age。

    POST /customer/_doc/1/_update?pretty
{
  "doc": { "name": "Jane Doe", "age": 20 }
}

    示例 3，使用脚本更新文档，比如将 ID 为 1 的文档的字段 age 加 5。

    POST /customer/_doc/1/_update?pretty
{
  "script": "ctx._source.age += 5"
}

    上面的例子，ctx._source 表示的是我们将要更新的文档。这里是通过指定 ID 的方式查询要更新的文档，elasticsearch 也可以像 SQL 一样，通过复杂查询实现更新。

    删除文档

    删除文档最简单直接，HTTP 方法换成 DELETE，指定文档 ID 即可。如下：

    DELETE /customer/_doc/2?pretty

    和更新类似，删除也可以根据查询结果执行删除，API 是 _delete_by_query。如果是删除索引中的所有文档，直接删除索引更直接点。

    批处理

    经过前面的学习，我们已经了解了 elasticsearch 一些基础 API 的使用，如文档的索引、更新、删除。这一小节介绍一个新的 API，_bulk API，它支持将多个操作打包成一个请求，实现批处理。这样可以更加高效的执行操作，也能减少网络传递次数。

    一个快速入门案例，如下：

    POST /customer/_doc/_bulk?pretty
{"index":{"_id":"1"}}
{"name": "John Doe" }
{"index":{"_id":"2"}}
{"name": "Jane Doe" }

    索引了 2 个文档，一个文档 ID 1，name 为 John Doe，另一个文档 ID 2，name 为 Jane Doe。

    再看一个案例，如下：

    POST /customer/_doc/_bulk?pretty
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}

    批处理包含 2 个操作，更新 ID 为 1 文档的 name 字段和删除 ID 为 2 的文档。

    批处理中的一个操作失败并不会导致整个 bulk API 处理失败，如果一个操作失败，剩下来的其他操作仍会继续执行。bulk API 处理完成后，响应结果中会包含每个操作的处理结果。

    数据探索

    本节内容主要涉及两个方面：搜索与分析。

    数据

    搜索分析不可缺少数据，我们将使用 elastic 官方提供的数据样本，相对而言，应该比自己的生成更符合真实场景。

    一个文档，示例如下：

    {
    "account_number": 0,
    "balance": 16623,
    "firstname": "Bradshaw",
    "lastname": "Mckenzie",
    "age": 29,
    "gender": "F",
    "address": "244 Columbus Place",
    "employer": "Euron",
    "email": "bradshawmckenzie@euron.com",
    "city": "Hobucken",
    "state": "CO"
}

    官方的数据是用工具随机生成的，工具地址。有兴趣，可以设置自己的数据生成规则。

    开始数据加载之前，要先下载数据，下载地址。

    $ wget https://raw.githubusercontent.com/elastic/elasticsearch/master/docs/src/test/resources/accounts.json

    下载完成后，执行如下命令加载数据：

    $ curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/_doc/_bulk?pretty&refresh" --data-binary "@accounts.json"

    查看索引信息

    $ curl "localhost:9200/_cat/indices?v"

    响应如下：

    health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   bank  FFcSux-ETmmUlMJNBCEyqA   5   1       1000            0      957kb        482.3kb

    可以看出，我们已经为 bank 成功索引了 1000 个文档。

    搜索 API

    开始尝试一些简单的搜索。有两种基本的搜索方式：

    • URI Search，通常 URI 参数指定搜索参数。
    • Request Body，在请求内容包含在请求体中发送。

    相对而言，Request Body 方式更灵活，包含了全部的搜索支持。而 URI Search 主要在测试时使用，比较方便。

    搜索请求通过 _search 执行。一个示例，通过搜索返回 bank 索引中的所有文档。

    GET /bank/_search?q=*&sort=account_number:asc&pretty

    URI Search 方式实现搜索，通过 q=* 执行匹配全部文档，sort=account_number:asc 指定排序方式。

    响应如下：

    {
  "took" : 63,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1000,
    "max_score" : null,
    "hits" : [ {
      "_index" : "bank",
      "_type" : "_doc",
      "_id" : "0",
      "sort": [0],
      "_score" : null,
      "_source" : {"account_number":0,"balance":16623,"firstname":"Bradshaw","lastname":"Mckenzie","age":29,"gender":"F","address":"244 Columbus Place","employer":"Euron","email":"bradshawmckenzie@euron.com","city":"Hobucken","state":"CO"}
    }, ...
    ]
  }
}

    结果中的各个参数函数如下：

    • took 表示搜索执行时间
    • timed_out 搜索是否超时
    • _shards 多少分片参与搜索，以及成功与失败的情况如何。
    • hits 搜索结果
    • hits.total 匹配搜索条件的文档数量
    • hits.hits.sort 排序
    • hits.hits._score 和 max_score，相关度得分，指定排序，字段会被忽略。

    通过 Reuqest Body 方式执行与上面相同的操作，如下：

    GET /bank/_search
{
  "query": { "match_all": {} },
  "sort": [
    { "account_number": "asc" }
  ]
}

    我们下面主要介绍 Request Body 的使用，毕竟它更加强大。

    DSL 介绍

    DSL，全称 Domain Special Language, 即特定领域语言，elasticsearch 制定了一套 JSON 风格的 DSL 语言。它支持的功能非常全面，刚学习它时，会让我们产生一种恐惧，因为它真的很难。我们可以先从一些简单的例子看起。

    查询所有文档，如下：

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

    解剖下请求体。query 定义查询语句，match_all 就是我们将会执行的查询语句，表示匹配索引中的所有文档。

    执行上面的查询语句默认只会返回 10 条文档，我们可以通过指定 size 参数改变默认获取文档数量。如下：

    GET /bank/_search
{
  "query": { "match_all": {} },
  "size": 1
}

    通过 from 和 size 可以实现分页效果，如下：

    GET /bank/_search
{
  "query": { "match_all": {} },
  "from": 10,
  "size": 10
}

    from 用于指定文档偏移的开始位置，相当于 SQL 中的 offset。

    文档默认根据搜索相关度得分排序，不过我们这里是默认匹配全部，所以文档的相关度得分都是1。除了相关度排序，还可以按其他字段，比如 balance 字段。如下：

    GET /bank/_search
{
  "query": { "match_all": {} },
  "sort": { "balance": { "order": "desc" } }
}

    搜索查询语句

    继续看下搜索返回文档字段，默认情况下，搜索将会返回文档的所有字段内容。我们可通过 _source 指定只返回部分内容。

    GET /bank/_search
{
  "query": { "match_all": {} },
  "_source": ["account_number", "balance"]
}

    如此，搜索将只返回 account_number 和 balance 两个字段。 了解的 SQL 的朋友可以将其与 SELECT 指定列类比。

    继续看查询部分吧！

    前面，通过 match_all 查询匹配了全部文档。现在，我们再引入一个新的查询语句，match，它是基于一个字段的查询。

    查询 account_number 为 20 的文档。示例如下：

    GET /bank/_search
{
  "query": { "match": { "account_number": 20 } }
}

    查询 address 包含 mill 的文档。示例如下：

    GET /bank/_search
{
  "query": { "match": { "address": "mill" } }
}

    查询 address 包含 mill 或 lane 的文档。示例如下：

    GET /bank/_search
{
  "query": { "match": { "address": "mill lane" } }
}

    match 基于分词查询，2 个查询单词是 or 的关系。如果我们就要搜索 "mill lane" 呢？ 这时可以使用 match_pharse。示例如下：

    查询 address 包含 "mill lane" 的文档。示例如下：

    GET /bank/_search
{
  "query": { "match_phrase": { "address": "mill lane" } }
}

    继续介绍 bool 查询，它允许我们将上面这些基础查询组合形成一个复合查询。比如，查询同时包含 "mill" 和 "jane" 的文档。

    示例如下：

    GET /bank/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "address": "mill" } },
        { "match": { "address": "lane" } }
      ]
    }
  }
}

    例子中的 bool must 表示文档必须同时满足两个 must 条件。如果是只要满足一个条件即可，我们可以使用 bool should，示例如下：

    GET /bank/_search
{
  "query": {
    "bool": {
      "should": [
        { "match": { "address": "mill" } },
        { "match": { "address": "lane" } }
      ]
    }
  }
}

    如果要求两者必须不满足，我们可以使用 bool must_not，示例如下：

    GET /bank/_search
{
  "query": {
    "bool": {
      "must_not": [
        { "match": { "address": "mill" } },
        { "match": { "address": "lane" } }
      ]
    }
  }
}

    bool 查询中还可以将上面的这几种查询同时组合起来，同时包含 must、must_not 和 should。

    示例如下：

    GET /bank/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "age": "40" } }
      ],
      "must_not": [
        { "match": { "state": "ID" } }
      ]
    }
  }
}

    注意一点，如果是 must、must_not 和 should 组合时，should 就缺少了必须满足一个才算匹配的限制，这时，我们可以通过 minimum_should_match 指定 should 匹配个数。

    更复杂的，bool 查询中还可以包含其他的 bool 查询。这里先不介绍了。

    过滤语句

    谈到过滤之前，我们就不得不提文档相关度评分，相关度评分是用于衡量搜索语句与文档的匹配程度的一个指标。前面已经提过的查询语句都会参与到这个指标的计算。

    但有时，查询仅仅是为了过滤一些不满足条件的文档，我们并不希望它们也参与到相关度评分的计算中，由此，我们并引入了 filter。

    前面介绍的 bool 查询中便支持 filter 功能。它可以在不影响相关度评分的情况下，实现文档过滤。如下：

    GET /bank/_search
{
  "query": {
    "bool": {
      "must": { "match_all": {} },
      "filter": {
        "range": {
          "balance": {
            "gte": 20000,
            "lte": 30000
          }
        }
      }
    }
  }
}

    bool 查询中包含了 must 和 filter 两部分。filter 部分通过 range query 实现只查询 blanace 满足指定区间的文档，must 中的 match_all 实现全部文档返回。

    除了上面介绍的查询，如 match_all、match、bool、range，elasticsearch 还有很多其它查询可用，这里不详细介绍了。只要掌握了前面的知识，我们已经完全可以照猫画虎。

    聚合功能

    利用 elasticsearch 的聚合能力，我们可以实现分组统计，可以和 SQL 的 GROUP BY 分组和聚合函数类比。搜索和聚合都是通过 _search 请求实现，同一个请求可同时处理搜索与聚合的请求。这样也可以帮助我们节省必要的网络带宽。

    一个例子，按银行卡账号状态（即 state）分组。默认是返回 top 10。如下：

    GET bank/_search
{
  "size": 0,
  "aggs": {
    "group_by_state": {
      "terms": {
        "field": "state.keyword"
      }
    }
  }
}

    如何 SQL 呢？如下：

    SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC LIMIT 10;

    响应如下：

    {
  "took": 29,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped" : 0,
    "failed": 0
  },
  "hits" : {
    "total" : 1000,
    "max_score" : 0.0,
    "hits" : [ ]
  },
  "aggregations" : {
    "group_by_state" : {
      "doc_count_error_upper_bound": 20,
      "sum_other_doc_count": 770,
      "buckets" : [ {
        "key" : "ID",
        "doc_count" : 27
      }, {
        "key" : "TX",
        "doc_count" : 27
      }, {
        "key" : "AL",
        "doc_count" : 25
      }, {
        "key" : "MD",
        "doc_count" : 25
      }, {
        "key" : "TN",
        "doc_count" : 23
      }, {
        "key" : "MA",
        "doc_count" : 21
      }, {
        "key" : "NC",
        "doc_count" : 21
      }, {
        "key" : "ND",
        "doc_count" : 21
      }, {
        "key" : "ME",
        "doc_count" : 20
      }, {
        "key" : "MO",
        "doc_count" : 20
      } ]
    }
  }
}

    从上面可以看出，ID 为 Idaho 的数量为 27，紧接着是 TX 数量 27，然后是 AL 共 25 个。上面设置 size 为 0，是为隐藏搜索结果内容，仅仅显示聚合结果。

    我们可以在前面的聚合结果的基础上，计算 top 10 的账户余额平均值。如下：

    GET /bank/_search
{
  "size": 0,
  "aggs": {
    "group_by_state": {
      "terms": {
        "field": "state.keyword",
        "order": {
          "average_balance": "desc"
        }
      },
      "aggs": {
        "average_balance": {
          "avg": {
            "field": "balance"
          }
        }
      }
    }
  }
}

    在 group_by_state 中加入子聚合 average_balance，同时在 group_by_state 中，通过 order 配置实现了按 balance 平均值大小排序的需求。

    下面这个例子演示了如何按年龄区间分组，比如 20-29、30-39 和 40-49，并在基础上，继续按性别分组。最后，计算各个分组 balance 的平均值。

    GET /bank/_search
{
  "size": 0,
  "aggs": {
    "group_by_age": {
      "range": {
        "field": "age",
        "ranges": [
          {
            "from": 20,
            "to": 30
          },
          {
            "from": 30,
            "to": 40
          },
          {
            "from": 40,
            "to": 50
          }
        ]
      },
      "aggs": {
        "group_by_gender": {
          "terms": {
            "field": "gender.keyword"
          },
          "aggs": {
            "average_balance": {
              "avg": {
                "field": "balance"
              }
            }
          }
        }
      }
    }
  }
}

    例子中有两个分组 group_by_age 和 group_by_gener 以及一个聚合计算 average_balance。

    总的来说，上面的例子还是比较循环渐进的。但主要还是集中在使用层面，并没有太多细节的介绍。如果想了解更多与聚合相关的内容，可自行查询官方文档。

    总结

    Elasticsearch 可以说是一款即简单又复杂的产品。本文只是简单介绍了它的一些基础，并初步体验了下它的使用。到此，仅仅算是开启了一扇门，elasticsearch 的使用远没有那么简单。

    再接再厉吧！朋友！

    附录

    Getting Started

    Basic Concepts

    Installation

    Exploring Your Cluster

    Modify Your Data

    Exploring Your Data

    波罗学的公众号

    elasticsearch
    波罗学
    775 声望42 粉丝
    « 上一篇
    Go 译文之如何使用反射
    下一篇 »
    Go 回答之如何阅读 Go 源码

    引用和评论

    推荐阅读
    头像
    从 HTTP 角度看 Go 如何实现文件提交

    波罗学赞 1阅读 2.2k

    头像
    查询性能提升 10 倍、存储空间节省 65%，Apache Doris 半结构化数据分析方案及典型场景

    SelectDB技术团队赞 1阅读 350

    头像
    Elasticsearch 8.x 重要变化（qbit）

    qbit阅读 590

    头像
    关于 Elasticsearch 同义词的困惑（qbit）

    qbit阅读 355评论 1

    头像
    Elasticsearch搭建、结合spring boot、简单示例

    LLL_赞 1阅读 333

    头像
    Docker如何修改Elasticsearch容器的密码

    Smoke阅读 288

    头像
    阿里云Elasticsearch AI搜索实践

    阿里云大数据AI阅读 272

    0 条评论
    得票最新