Elasticsearch:通过例子快速入门

Elasticsearch 是业界最流行的开源企业搜索引擎,应用广泛。 在我们的手机里的 App 背后的搜索引擎好多都是 Elasticsearch,比如我们熟知的抖音,滴滴,美团,携程,点评,银行 app,保险,证券,交友,健康宝等等。如果你想初步了解 Elasticsearch,请阅读我之前的文章 “Elasticsearch 简介”。 我们还学习了如何在 Python 中使用 Elasticsearch。 索引 laptops-demo 已创建并填充了一些示例数据,本文中的查询将基于这些数据。 如果你还没有读过这篇文章,建议先读一读。 但是,如你已经对 Elasticsearch 有所了解,则可以毫无问题地继续阅读本文。

安装

如果你还没有安装好自己的 Elasticsearch 及 Kibana,请参考如下的两篇文章来进行安装:

针对一些还没有对 Elasticsearch 及 Kibana 有所认识的开发者来说,我强烈建议参考文章 “Elasticsearch:如何在 Docker 上运行 Elasticsearch 8.x 进行本地开发” 来进行一键安装。我们先不考虑安全的问题。请参考文章中的 “使用 Docker Compose 运行 Elasticsearch 和 Kibana” 章节来进行一键安装 Elasticsearch 及 Kibana。

准备数据

我们有如下的两种方法写入数据: 

1)针对有一定 Python 开发经验的开发者来说,你可以参考文章 “Elasticsearch:关于在 Python 中使用 Elasticsearch 你需要知道的一切 - 8.x” 把我们所需要的数据写入到 Elasticsearch 中。

2)在 Kibana 的 Dev Tools 中打入如下的命令:

PUT laptops-demo
{
  "settings": {
    "index": {
      "number_of_replicas": 1
    },
    "analysis": {
      "filter": {
        "ngram_filter": {
          "type": "edge_ngram",
          "min_gram": 2,
          "max_gram": 15
        }
      },
      "analyzer": {
        "ngram_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "ngram_filter"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "id": {
        "type": "long"
      },
      "name": {
        "type": "text",
        "analyzer": "standard",
        "fields": {
          "keyword": {
            "type": "keyword"
          },
          "ngrams": {
            "type": "text",
            "analyzer": "ngram_analyzer"
          }
        }
      },
      "brand": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "price": {
        "type": "float"
      },
      "attributes": {
        "type": "nested",
        "properties": {
          "attribute_name": {
            "type": "text"
          },
          "attribute_value": {
            "type": "text"
          }
        }
      }
    }
  }
}

我们到地址 https://github.com/liu-xiao-guo/py-elasticsearch8 下载 laptops_demo.json 文件。然后在电脑上打入如下的命令:

curl -s -H "Content-Type: application/x-ndjson" -XPOST "http://localhost:9200/_bulk" --data-binary "@laptops_demo.json"

上面的有些字段的类型可能对初学的开发者并不熟悉。我们先可以不管这些。在我的这篇文章 “Elastic:开发者上手指南” 中的很多文章都有介绍。

 这样我们就完成了数据的写入部分了。我们可以通过如下的命令来查看文档的个数:

GET laptops-demo/_count
{
  "count": 200,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  }
}

Dev Tools 操作

我们在 Dev Tools 中可以向 Elasticsearch 发送 REST API 请求并完成我们许多的指令。

创建一个索引

我们可以使用如下的命令来创建一个索引:

PUT /test-index

你只能运行此命令一次,否则,你将看到资源已存在的错误。 请注意,前导正斜杠 (/) 是可选的,你可以省略它并且结果相同。

检查集群中的索引

 我们可以通过如下的命令来检查集群中的索引:

GET _cat/indices

更新索引的设置

我们可以通过如下命令来更新一个索引的设置:

PUT test-index/_settings
{
  "settings": {
    "number_of_replicas": 2
  }
}

你需要指定 _settings 端点,否则你将看到使用现有名称创建索引的相同错误。

删除索引

我们通过如下的命令来删除一个索引:

DELETE test-index

针对文档的创建(create)、读取(read)、更新(update)和删除(delete)这些 CRUD 操作的基本 Elasticsearch 查询。

在 Elasticsearch 中,索引就像一张表,文档就像一行数据。 但是,与 MySQL 等关系型数据库中的列式数据不同,Elasticsearch 中的数据是 JSON 对象。

创建一个文档

PUT test-index/_doc/1
{
  "name": "John Doe"
}

如果索引尚不存在,此查询将自动创建索引。 此外,还会创建一个带有 name 字段的新文档。

读取一个文档

GET test-index/_doc/1

更新一个文档

通过如下的命令添加一个叫做 age 的字段:

POST test-index/_update/1
{
  "doc": {
    "age": 30
  }
}

请注意,你必须使用 POST 命令来更新文档。 要更新的字段在 doc 字段中指定。更新完后,我们可以使用如下的命令来进行查看:

GET test-index/_doc/1
{
  "_index": "test-index",
  "_id": "1",
  "_version": 2,
  "_seq_no": 1,
  "_primary_term": 1,
  "found": true,
  "_source": {
    "name": "John Doe",
    "age": 30
  }
}

我们可以更新一个已有的字段,比如:

POST test-index/_update/1
{
  "doc": {
    "name": "liuxg"
  }
}

我们再次查询:

GET test-index/_doc/1
{
  "_index": "test-index",
  "_id": "1",
  "_version": 3,
  "_seq_no": 2,
  "_primary_term": 1,
  "found": true,
  "_source": {
    "name": "liuxg",
    "age": 30
  }
}

删除一个文档

DELETE test-index/_doc/1

现在我们对 Elasticsearch 索引和文档的 CRUD 操作有了一些感受。 我们可以看到,编写 Elasticsearch 查询就像使用 GET、POST、PUT 和 DELETE 方法发出 RESTful API 请求一样。 但是,主要区别在于我们可以将 JSON 对象传递给 GET 方法,这在常规 REST GET 方法中是不允许的。

查询索引

要检查索引中的所有文档,请运行以下命令:

GET laptops-demo/_search

它是以下的简短版本:

GET laptops-demo/_search
{
  "query": {
    "match_all": {}
  }
}

从上面我们可以看出来有 200 个文档被搜索到了。你应该能够看到从 JSON 文件添加的所有文档。 现在索引和文档都准备好了,我们可以开始搜索了。

我们已经知道如何检查索引中的所有文档。 默认情况下,返回所有可能难以阅读的字段。 要仅显示特定字段,我们可以指定 _sources 关键字:

GET laptops-demo/_search
{
  "query": {
    "match_all": {}
  },
  "_source": ["name"]
}

如果你根本不想看到来源,你可以将 _source 设置为 false:

GET laptops-demo/_search
{
  "query": {
    "match_all": {}
  },
  "_source": false
}

事实上,在最新的 Elasticsearch 发布版中,我们更倾向于如下的一种方式来获取我们想要的字段:

GET laptops-demo/_search
{
  "fields": [
    "name",
    "price"
  ], 
  "query": {
    "match_all": {}
  },
  "_source": false
}

我们使用 fields 来指定想要返回的字段。

顾名思义,match_all 匹配所有内容。 要根据某些条件进行搜索,我们可以使用匹配关键字。 例如,要搜索名称中包含 Apple 的所有笔记本电脑:

GET laptops-demo/_search
{
  "query": {
    "match": {
      "name": "Apple"
    }
  }
}

从上面的映射我们知道,name 字段是一个 text 字段,会被解析。 简单来说,分析就是将文本字符串小写,拆分成t oken,去掉标点符号。 你可以在此链接上阅读有关分析的更多信息。

要查看如何分析文本,我们可以使用 _analyze 端点:

GET laptops-demo/_analyze
{
  "text": "Apple MackBook!",
  "analyzer": "standard"
}

这里我们使用 standard 分析器,如上所述,它将小写文本,将其拆分为标记并删除标点符号:

{
  "tokens": [
    {
      "token": "apple",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "mackbook",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

更多关于 Elasticsearch analyzer 的文章,请阅读 “Elasticsearch: analyzer”。

由于我们在索引的设置中定义了一个特殊的分析器 ngram_analyzer ,让我们使用这个分析器来分析我们的文本,看看我们会得到什么:

GET laptops-demo/_analyze
{
  "text": "Apple MackBook!",
  "analyzer": "ngram_analyzer"
}

我们可以看到生成了一堆N-gram:

{
  "tokens": [
    {
      "token": "ap",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "app",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "appl",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "apple",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "ma",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mac",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mack",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mackb",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mackbo",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mackboo",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "mackbook",
      "start_offset": 6,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

这些 N-grams 对于输入即搜索或自动完成很有用,让我们尝试通过部分输入进行搜索:

GET laptops-demo/_search
{
  "query": {
    "match": {
      "name.ngrams": "Appl"
    }
  }
}

在此查询中,你还可以获得所有 Apple 笔记本电脑。 如果你在 name 字段而不是 name.ngrams 字段中按 Appl 搜索,你将找不到任何内容,因为 name 字段由standard 分析器分析,因此没有 N-gram。

你可能想知道 name 字段和 name.ngrams 字段之间的关系是什么。 嗯,这就是所谓的多字段(multi-fields),就是为了不同的目的,用不同的方式索引同一个字段。 由于始终分析文本字段,因此我们经常为其添加一些额外的字段。 例如,keyword 类型字段通常被添加到文本字段中。 keyword 类型意味着文本将按原样处理,不会被分析。 同一字段的多个字段可以用不同的分析器进行分析。 在本文中,使用 standard 分析器分析 name 字段,使用自定义 ngram_analyzer 分析 name.ngrams 字段,这在不同情况下很有用。

我们已经学习了如何使用匹配查询来搜索文本字段。 还有 long、float 等其他类型的字段,这些字段类似于文本字段的关键字类型,不做分析。 如果我们不想在搜索中分析查询输入,我们可以使用 term 查询:

GET laptops-demo/_search
{
  "query": {
    "term": {
      "name.keyword": {
        "value": "Apple MacBook Model 131"
      }
    }
  }
}

通过这个查询,我们得到了名字恰好是 “Apple MacBook Model 131” 的笔记本电脑。 如果我们将查询中的任何单词更改为小写或删除任何单词,我们将一无所获。 这是因为,对于 term 查询,我们按原样搜索查询字符串,不会对其进行分析。  Elasticsearch 搜索引擎中存储的文本字段数据不是原始字符串,而是上面用分析器演示的一堆 token。这种搜索也通常被称之为精确匹配。

如果我们想搜索多个值(原样),我们可以使用 terms 查询。 例如,如果我们要搜索 id 为 1、10 和 100 的笔记本电脑:

GET laptops-demo/_search
{
  "query": {
    "terms": {
      "id": [
        1,
        10,
        100
      ]
    }
  }
}

我们可以使用 range 查询来搜索包含具有给定范围的术语的文档。 例如,让我们搜索价格在 10,000 到 20,000 Kr 之间的笔记本电脑。

GET laptops-demo/_search
{
  "query": {
    "range": {
      "price": {
        "gte": 10000,
        "lte": 20000
      }
    }
  }
}

我们已经知道如何通过 ID 更新和删除单个文档。 有时我们需要更新或删除许多满足某些条件的文件。 在这种情况下,我们可以使用 update_by_query 和 delete_by_query:

POST laptops-demo/_update_by_query
{
  "script": {
    "source": "ctx._source.price += params.increase",
    "lang": "painless",
    "params" : {
      "increase" : 2000
    }    
  },
  "query": {
    "match": {
      "brand": "Apple"
    }
  }
}

在此示例中,我们将所有 Apple 笔记本电脑的价格提高 2,000 Kr。

关键点:

  • 在 query 部分,我们使用常规搜索查询来查找需要更新的文档。
  • 在script 部分,我们指定如何处理查询找到的结果。 在这里,我们正在进行脚本更新。
  • lang 指定要使用的语言。 在 Elasticsearch 中,默认的脚本语言称为 painless,我会说这是一个奇怪的名字。 由于它是要使用的默认语言,因此你可以省略此字段。
  • params 指定将在脚本中使用的参数。
  • source 指定要运行的源代码。 源码中 ctx 为上下文数据,ctx._source.price 代表查询到的每个文档的 price 字段。

更多关于脚本的学习,你可以参考文章 “Elastic:开发者上手指南” 中的 “Painless 编程” 部分。

对于delete_by_query,就简单多了,因为我们不需要指定源代码来运行。 让我们删除 id 为 1、11、111 的笔记本电脑,仅用于演示目的。

POST laptops-demo/_delete_by_query
{
  "query": {
    "terms": {
      "id": [
        1,
        11,
        111
      ]
    }
  }
}

默认情况下,查询结果按相关性得分降序排列。 我们也可以按照我们指定的一些字段对结果进行排序。 例如,让我们搜索所有 Apple MacBook 并按价格降序对结果进行排序:

GET laptops-demo/_search
{
  "query": {
    "match": {
      "name": "Apple MacBook"
    }
  },
  "sort": [
    {
      "price": {
        "order": "desc"
      }
    }
  ]
}

sort 字段需要一个对象列表,这意味着我们可以按多个字段排序。

让我们检查一个更高级的排序示例。 让我们将 Apple 笔记本电脑放在其他品牌之前,然后按 price 升序排列。 为了这个排序目的,我们需要写一些 painless 脚本:

GET laptops-demo/_search
{
  "sort": [
    {
      "_script": {
        "type": "number",
        "script": {
          "lang": "painless",
          "source": """
              if (doc['brand.keyword'].value == 'Apple') {
                return 1;
              } else {
                return 0;
              }
            """
        },
        "order": "desc"
      }
    },
    {
      "price": {
        "order": "asc"
      }
    }
  ]
}

_script 关键字指定我们将按脚本返回的结果排序。 注意,我们不能直接按布尔条件排序,而是需要将布尔结果转化为数值,然后再按它们排序。 type 字段指定从脚本返回的结果的类型,这里我们希望返回一个 number。

在 source 字段指定的 painless 脚本中,doc 变量包含了当前文档的所有字段。 对于常规字段,可以通过 doc['fieldname'].value 访问该值。 对于 keyword 等多字段,可以通过 doc['fieldname.keyword'].value 访问值。

到目前为止,我们只使用了一个查询。 如果我们希望文档满足多个条件,我们可以使用 bool 查询,它使用一个或多个布尔子句构建,包括 must、should、filter 和 must_not。 这就是 Elasticsearch 查询可能变得非常复杂的地方。

默认情况下,Elasticsearch 按相关性分数对匹配结果进行排序,相关性分数衡量每个文档与查询的匹配程度。 相关性分数是一个正浮点数,在搜索 API 的 _score 元数据字段中返回。 _score 越高,文档越相关。 每种查询类型都会以不同方式计算相关性分数。 布尔子句可以在所谓的查询或过滤器上下文中运行。

查询上下文:

  • must:子句(query)必须出现在匹配的文档中,并将有助于得分。
  • should:子句(query)应该出现在匹配的文档中,也就是说它实际上可能出现也可能不出现。 我们可以通过 minimum_should_match 字段指定应该出现多少个 should 子句,如下所示。

must 和 should 查询在查询上下文中执行。 除了决定文档是否匹配之外,查询子句还在 _score 元数据字段中计算相关性分数。

过滤器上下文:

  • filter:子句(query)必须出现在匹配的文档中。 但是,与 must 不同的是,查询的分数将被忽略。
  • must_not:子句(查询)不得出现在匹配文档中。

filter 和 must_not 查询在过滤器上下文中执行,其中忽略评分并考虑缓存子句,这可以使以后使用相同子句的搜索更快。

作为演示,让我们找到满足以下条件的 Apple 笔记本电脑:

  • brand 字段必须包含“Apple”。
  • name 应包含 “MacBook” 或 “Pro”,或两者(如果有)。
  • price 不得低于 5,000 Kr 或高于 50,000 Kr。
  • memory 必须是 8GB。

这是要使用的查询:

GET laptops-demo/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "brand": "Apple"
        }
      },
      "should": [
        {
          "match": {
            "name": "MacBook"
          }
        },
        {
          "match": {
            "name": "Pro"
          }
        }
      ],
      "must_not": {
        "range": {
          "price": {
            "gt": 50000,
            "lt": 5000
          }
        }
      },
      "filter": {
        "nested": {
          "path": "attributes",
          "query": {
            "bool": {
              "must": [
                {
                  "match": {
                    "attributes.attribute_name": "memory"
                  }
                },
                {
                  "match": {
                    "attributes.attribute_value": "16GB"
                  }
                }
              ]
            }
          }
        }
      },
      "minimum_should_match": 1
    }
  }
}

这个演示可能看起来很愚蠢,因为我们在文档中没有很多字段。 在实际情况下,一个文档中可以有几十个字段,布尔查询可以变得非常强大。 本例中使用的 nested 查询将在稍后介绍。简单一句话,如果是针对一个数组来进行查询,需要同时满足其中的两个及以上的属性的查询,我们需要使用到 nested 数据类型。比如,我们需要查询 attribute 的名称为 memory,并且它的值也为 16G,那么我们在这种情况下需要使用到 nested 数据类型。需要特别指出的是 nested 目前在 Kibana 中支持的不是很好。不能使用 nested 字段来进行可视化。

到目前为止,我们还没有解释 laptops-demo 索引的属性字段。 attributes 字段的特殊之处在于它是一个 nested 字段,包含 attribute_name 和 attribure_value 字段作为子字段。 nested 类型是对象数据类型的特殊版本,它允许对象数组以一种可以彼此独立查询的方式进行索引。 我们应该始终为 nested 字段创建映射,如本例所示,因为 Elasticsearch 没有内部对象的概念。 因此,它将对象层次结构扁平化为字段名称和值的简单列表。 如果你查询展平的对象,你将得不到预期的结果。

要查询 nested 字段,我们可以使用 nested 查询。 让我们找出内存为 16GB 的所有笔记本电脑:

GET laptops-demo/_search
{
  "query": {
    "nested": {
      "path": "attributes",
      "query": {
        "bool": {
          "must": [
            { "match": { "attributes.attribute_name": "memory" }},
            { "match": { "attributes.attribute_value":  "16GB" }} 
          ]
        }
      }
    }
  }
}

关键点:

  • nested 关键字指定我们正在查询 nested 字段。
  • path 指定 nested 字段的名称,在本例中为 attributes。
  • bool 表示我们正在使用布尔查询,因为我们希望 attribute_name 和 attribute_value 字段都满足某些条件。
  • must 表示子查询必须全部出现在文档中。
  • match 表示全文搜索,因为 attribute_name 和 attribute_value 字段都是文本字段。 如果其中一些不是文本字段,我们需要使用 term、terms 或 range 查询。

Elasticsearch 不仅仅是一个搜索引擎,它还提供了非常强大的分析功能。 在 Elasticsearch 中,分析通常是通过 aggregations 来完成的,聚合将我们的数据汇总为指标、统计数据或其他分析。

你可以通过指定搜索 API 的 aggs 参数来运行聚合作为搜索的一部分。 最常见的聚合类型是 terms 聚合,它是一种基于多桶值的聚合,其中桶(bucket)是动态构建的 —— 每个唯一值一个。 请注意,此处的术语字段与查询中使用的字段不同。 terms in aggs 表示聚合方法是多桶聚合,而 terms in query 表示返回在给定字段中包含一个或多个确切术语的文档。 terms 查询与 term 查询相同,只是你可以搜索多个值。

让我们计算每个品牌的产品数量。 请注意,术语聚合应该是 keyword 类型的字段或任何其他适合桶聚合的数据类型,例如离散数值。

GET laptops-demo/_search
{
  "aggs": {
    "brand-count-agg": {
      "terms": {
        "field": "brand.keyword"
      }
    }
  }
}

默认情况下,搜索结果显示在聚合结果之前,这会使后者难以阅读。 如果我们只想看到聚合结果,我们将 size 设置为 0,这意味着不会显示任何查询结果。

GET laptops-demo/_search
{
  "size":0,
  "aggs": {
    "brand-count-agg": {
      "terms": {
        "field": "brand.keyword"
      }
    }
  }
}

我们也可以在聚合前指定搜索条件。 例如,我们只统计价格超过 20,000 Kr 的笔记本电脑。

GET laptops-demo/_search
{
  "size": 0,
  "aggs": {
    "brand-count-agg": {
      "terms": {
        "field": "brand.keyword"
      }
    }
  },
  "query": {
    "range": {
      "price": {
        "gte": 20000
      }
    }
  }
}

当你有更多要求时,聚合可能会变得复杂。 可以基于多个字段进行聚合,通过正则表达式过滤值,写一些脚本在聚合前转换数据等。如果你想有更高级的聚合,可以查看官方文档。更多关于聚合的文章,请参阅文章  “Elastic:开发者上手指南” 中的 “Aggregations” 章节。

我们在本文中介绍了很多关于 Elasticsearch 的内容。 如果你已经了解了基本知识和查询,那么你可以开始在工作中编写自己的查询。 但是,还有很多东西需要学习,本文无法涵盖。 这篇文章的目的是给大家一个大概的介绍,如何在不同的场合使用 Elasticsearch 查询,让大家可以快速上手或初步对 Elasticsearch 有所了解。 我希望你喜欢这篇文章。

相关推荐

AgentHack Shanghai|基于阿里云AI搜索 Elasticsearch x Qoder 构建AI Agent应用

2026年12月12日,Elastic社区、阿里云与Qoder联合举办AgentHack实战活动,聚焦AI编程、搜索检索与智能体工具链融合。参赛者将使用唯一指定工具QoderCN,在一天内完成从需求分析到可演示原型的构建,结合阿里云AI搜索或Elastic生态实现真实场景应用。活动提供技术工作坊、导师答疑及1个月QoderCN专业版会员,鼓励展示数据检索、工具调用与任务闭环的完整链路。参赛者可基于阿里云Elasticsearch、ElasticCloud或自部署环境,打造企业知识问答、业务分析等智能体原型,

Elastic 中国社区官方博客 1429

Elastic 线下 Meetup 将于 2026 年 12 月 19 号下午在西安举行

2026年12月19日,Elastic、阿里云与新智锦绣联合举办西安站ElasticMeetup。活动聚焦Elasticsearch向量搜索、AI Agents构建及企业级知识引擎演进,特邀刘晓国、陈星宇、孔祥超等专家分享技术前沿实践。内容涵盖语义搜索、智能诊断、云原生管控与大模型时代搜索架构升级,助力开发者掌握企业级AI应用落地核心能力。

Elastic 中国社区官方博客 1290

Elastic 线下 Meetup 将于 2026 年 11 月 28 号下午在杭州举行

2026年11月28日,杭州阿里云谷园区将举办AI搜索技术盛会。活动汇聚Elastic社区首席布道师刘晓国、中国电子云高斌、阿里云汤祯捷及预言家科技欧阳楚才等专家,聚焦Elasticsearch向量搜索、AI Agents构建、本体智能体上下文引擎与电商智能导购系统,探讨AgenticSearch 2.0、多模态检索与企业级智能搜索演进。现场设茶歇、合影与抽奖,报名成功后请扫码入群。

Elastic 中国社区官方博客 1076

Elastic:如何成为一名 Elastic 认证工程师,Elastic 认证分析师及 Elastic 认证可观测性工程师

Elasticsearch 无疑是是目前世界上最为流行的大数据搜索引擎。根据 DB - Engines 的统计,Elasticsearch 雄踞排行榜第一名,并且市场还在不断地扩大:能够成为一名 Elastic 认证工程师也是很多开发者的梦想。这个代表了 Elastic 的最高认证,在业界也得到了很高的认知度。得到认证的工程师,必须除了具有丰富的 Elastic Stack 知识,而且必须有丰富的操作及有效的解决问题的能力。拥有这个认证证书,也代表了个人及公司的荣誉。针对个人的好处是,你可以..

Elastic 中国社区官方博客 2万+

Elastic:开发者上手指南

你们好,我是Elastic的刘晓国。如果大家想开始学习Elastic的话,那么这里将是你理想的学习园地。在我的博客几乎涵盖了你想学习的许多方面。在这里,我来讲述一下作为一个菜鸟该如何阅读我的这些博客文章。我们可以按照如下的步骤来学习:1)Elasticsearch简介:对Elasticsearch做了一个简单的介绍2)Elasticsearch中的一些重要概念:cluster,n..........................................................

Elastic 中国社区官方博客 17万+

Elastic:培训视频 - ​在生产环境中配置 Fleet Server 和 Elastic Agent 之间的安全

在这篇文章中,我将会把我写的有些内容录制成视频,供大家参考。希望对大家有所帮助。优酷的视频频道地址在这里。Elastic 简介及Elastic Stack 安装:优酷,腾讯 Elastic Stack docker 部署:优酷,腾讯 Elasticsearch中的一些重要概念(Cluster/Shards/Replica/Document/Type/Index):优酷,腾讯 开始使用El...............

Elastic 中国社区官方博客 1万+

Elasticsearch 简介

Elasticsearch是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch是由Elastic公司创建并开源维护的。它的开源代码位于https://github.com/elastic/elasticsearch。同时,Elastic公司也拥有Logstash及Kibana开源项目。这个三个开源项目组合在一起,就形成了 ELK软件栈。他们三个共同形成了一个强大的...

Elastic 中国社区官方博客 17万+

Kibana 中的人工智能连接器:你的 agent 可调用的 90 多个数据源

Elastic推出Kibana内置的90+人工智能连接器,支持Slack、GitHub、Confluence、PagerDuty等平台,让agent在推理中自动调用外部数据源,无需编写集成代码。通过身份验证中继服务,agent可安全访问个人或组织数据,快速关联告警与背景信息(如变更记录、讨论串、文档),显著缩短故障排查时间。结合ElasticCloud Trial,用户可即刻体验完整功能。

Elastic 中国社区官方博客 229

更少的位数,相同的召回率:DiskBBQ 更保守的自动校准扫描

Elasticsearch 现在在成本模型中将文档位数的权重提高至原来的三倍,因此 DiskBBQ 会先尝试预处理和更深层的重排序,再增加一个比特,使量化向量在保持相同召回率的同时维持较小的体积。

Elastic 中国社区官方博客 278

对 OpenTelemetry Kafka 接收器的两项改动,避免一个缓慢的租户拖住其他租户

Elastic通过两项改进解决OpenTelemetry Kafka接收器中的“吵闹邻居”问题:一是为每个Kafka分区引入独立工作单元,实现租户间分区隔离;二是添加租户限流处理器,动态限制各租户在共享发送队列中的槽位占用,防止慢租户阻塞其他租户。结合max_in_flight配置提升单分区吞吐量与内存控制,确保记录不丢失、投递至少一次,同时保障多租户环境下稳定高效的数据处理。

Elastic 中国社区官方博客 335

三次模型调用,占据 92% 的等待时间:使用 OpenTelemetry 实现人工智能 agent 可观测性

使用OpenTelemetry追踪LangChain购物助手,发现92%耗时源于三次模型调用。虽将比较模型替换为更便宜的版本后,成本降低76%-83%,但四成问题响应变慢。通过追踪数据定位瓶颈,结合ES|QL分析词元用量与费用,验证了成本优化但延迟未改善。借助Elastic AI Agent建议,进一步测试return_direct=True以跳过冗余调用,实现性能与成本双赢。可观测性助力精准决策,确保答案正确、响应高效。

Elastic 中国社区官方博客 405

Elasticsearch:稠密向量字段类型

dense_vector字段用于存储稠密向量,支持k近邻搜索(kNN),默认启用索引并使用余弦相似度。可接受浮点数数组或Base64编码字符串输入,支持自动量化(如int8、int4、bbq)以降低内存占用。通过index_options配置索引类型(如hnsw、bbq_disk),并可启用过采样与重新评分提升精度。向量默认不存储于_source中以节省空间,可通过fields或_source.exclude_vectors显式返回。支持bit向量及GPU加速索引,适用于高维向量场景。

Elastic 中国社区官方博客 289

使用 Qoder 将 CSV 文件导入 Elasticsearch

本文演示如何通过Qoder智能助手,仅用4轮对话,将IMDB电影数据CSV文件(10,178条)高效导入Elasticsearch。无需编写代码,Qoder自动完成依赖安装、连接配置、字段类型推断(text/keyword/double)、数据验证及导入,支持自定义映射与数据转换,耗时约30秒,显著简化数据导入流程。

Elastic 中国社区官方博客 246

两条规则,一次故障,一条告警:变点检测如何减少告警噪声

Elastic Carlos Crespo揭示了基于ES|QL规则的AI agent如何通过重运行查询验证告警真实性,实现从日志变化到重大事件告警的自动化。系统先通过变点检测识别规则行为突变,再由发现agent核实故障存在性、规模与影响范围,并合并同类信号以减少噪声。每条告警均附带可追溯的查询证据,确保结论可验证。最终生成的告警包含严重程度、置信度、受影响拓扑及量化指标,支持运维决策。该流程结合代码与模型分工,保障可靠性与可解释性,已在多场景测试中验证有效性。

Elastic 中国社区官方博客 333

把词向量“贴”在地球仪上:用球面视角看 Embedding 的真实几何

本文通过将归一化词向量投影至3D球面,利用slerp绘制大圆弧,以真实反映余弦相似度对应的测地线距离。相比传统PCA平面散点图,球面可视化避免几何扭曲,直观呈现词间语义关系。结合Plotly实现交互式“词语地球仪”,可旋转观察聚类、跨语言对齐(如“cat”与“猫”),并对比高维真值与降维后距离的失真。代码简洁(<200行),支持模型替换与扩展,揭示“向量相近”在球面上的真实形态。

Elastic 中国社区官方博客 262

我们的 agent 技能如何调研、构建和测试完整的 Elastic 集成

作者:来自 Elastic我们让 agent 技能处理美国国家标准与技术研究院的国家漏洞数据库接口,得到了两个数据流和一个经过验证的通用表达式语言程序,并通过了流水线测试和系统测试。调研发现,一天中 78% 的通用漏洞与披露记录都是旧记录的重新发布,这一发现改变了设计。Elasticsearch 原生集成了业界领先的生成式人工智能工具和服务提供商。欢迎观看我们的网络研讨会,了解如何,或使用构建可用于生产环境的应用。要为你的使用场景构建最佳搜索解决方案,立即开始,或在你的上试用 Elastic。

Elastic 中国社区官方博客 130

基于 Elasticsearch 与 Jina AI 的全模态智能搜索实践:技术全解析

是一个结构清晰、覆盖全面且极具实操价值的开源项目。它不仅展示了Jina AI 多模态模型在非结构化数据表征上的强悍性能,也展现了在混合检索(BM25 + k-NN + RRF)以及多模态 RAG 架构上的工程实践。无论是准备构建企业级智能知识库、多媒体图库检索系统,还是探索音视频多模态推荐,该项目都提供了非常优秀的代码模版与架构参考。

Elastic 中国社区官方博客 208

你的日志早已写好告警:在 Elasticsearch 中生成 ES|QL 检测查询

Elastic Observability Labs展示如何基于OpenTelemetry日志自动生成精准的ES|QL检测查询。通过30个知识指标(27个推断、3个计算),生成10条查询,其中4条转化为Kibana告警规则。查询严格遵循三条提示词规则:精确匹配短语、不依赖log.level、仅在同文档中组合谓词。正常运行时匹配0条,故障期间捕获676条支付服务异常日志。查询随依赖知识失效自动停用,确保持续有效性。

Elastic 中国社区官方博客 685

基于 Jina OCR v1 与 Elasticsearch 的 PDF 智能混合检索与 RAG 系统实战指南

本文介绍开源项目jina-ocr-v1-pdf,基于JinaOCRv1高精度视觉解析与Elasticsearch的混合检索(RRF),构建端到端PDF智能问答系统。通过PyMuPDF渲染高清图像、并发OCR提取结构化文本(Markdown/HTML),结合自动切片向量化与BM25+语义检索融合,实现精准页码定位与上下文相关性提升。配合Streamlit前端与Kibana监控,支持企业级文档智能处理,有效解决扫描件、多栏、表格等复杂排版难题,为RAG应用提供高效、可扩展的技术范本。

Elastic 中国社区官方博客 555

Elastic Cloud 无服务器服务审计日志:将审计记录发送到可观测性或安全解决方案

ElasticCloud无服务器服务推出审计日志投递功能,支持将Elasticsearch与Kibana的活动日志(如索引变更、登录行为、数据访问)自动投递至同一组织内的可观测性或安全项目。附带8条告警规则和7个仪表板,涵盖凭据攻击检测、对象取证、数据访问追踪等场景。通过忽略筛选条件可降低存储成本,实现按需保留关键证据。支持跨项目日志聚合,助力安全与合规团队高效调查。立即免费试用14天,体验AI驱动的搜索与智能监控。

Elastic 中国社区官方博客 183

Elastic 在《Forrester Wave™:2026 年第四季度智能运维平台》报告中被评为强劲表现者

Elastic在《ForresterWave®:2026年第四季度智能运维平台》中被评为强劲表现者,获五项最高评分,涵盖算法可信度、可观测性即代码、AI技术栈、数据主权与定价透明度。其人工智能站点可靠性工程师以透明推理、完整上下文、持续学习和开放标准为核心,实现可验证排查、高效存储与跨环境兼容,助力团队信任AI、提升响应效率,推动智能运维迈向可验证、可进化的新阶段。

Elastic 中国社区官方博客 194

使用 OpenTelemetry 在 Elastic 中实现 Claude 平台的人工智能 agent 可观测性

Elastic与Claude平台集成,通过OpenTelemetry将AI agent追踪数据实时发送至Elastic,实现无代码观测。用户可在Kibana中查看模型请求、工具调用及上下文协议的完整交互轮次,包含耗时、词元计数与对话内容。支持服务清单、告警规则与SLO设置,结合SDK可实现跨服务追踪。免费云试用已开放,快速接入即可全面掌握Claude agent性能与成本。

Elastic 中国社区官方博客 894

三个区域、三个 Kibana、一个视图:跨集群搜索登陆 Elastic 合成监测

Elastic 9.5推出合成监测跨集群搜索功能,实现多集群监测器统一视图。无需复制数据,中央Kibana可实时查询远程集群的探测结果,展示状态、用户旅程、截图与证书,支持按远程集群筛选与分组。配置仍保留在原集群,仅提供只读访问,管理需返回源Kibana。适用于有状态部署,暂不支持无服务器服务。告警跨集群功能正在开发中。

Elastic 中国社区官方博客 384

Elastic 重大事件功能如何将 100 条日志样本转化为检测规则

本文介绍Elastic重大事件功能如何通过智能日志采样,从100份样本中提取27个知识指标(如服务、依赖关系、技术等),构建有证据支撑的日志源描述,进而生成精准检测规则。相比均匀采样易遗漏罕见故障信息,该系统采用三路分层采样(按实体筛选、多样性、随机)确保覆盖长尾模式,并通过循环迭代与去重机制提升准确性。知识指标可审核、手动保留或排除,支持持续接入。第二部分将基于这些指标生成可执行的查询,实现从“看到”到“检测”的跨越。

Elastic 中国社区官方博客 301

给海量查询“减负”:列式查询改写如何让检索更“省力”

Elasticsearch 9.5.0推出的列式查询改写技术,实现“零改造、高兼容、高精准”的查询优化。通过按需读取字段、谓词下推与嵌套扁平化,显著降低冗余读取与解码开销。基于1.8亿条日志的实测验证:16个用例命中数完全一致,核心时延持平,边界场景稳定,DSL语法兼容。系统自动降级兜底,确保功能可用。该技术特别适用于日志检索等海量数据场景,为集群性能提升提供开箱即用的底层支撑。

Elastic 中国社区官方博客 637

Elastic 如何帮助奥迪 Revolut F1® 车队在工程软件中找到关键信息

Elastic与奥迪RevolutF1®车队达成多年合作,将作为2026年美国大奖赛官方赛事合作伙伴,并自2027年起成为其官方搜索与可观测性供应商。通过Elastic技术栈(Logstash、Elasticsearch、Kibana),车队实现跨系统日志与遥测数据的统一视图,助力工程师在毫秒级内快速排查问题,提升软件可靠性。该合作不仅强化工程效率,更推动AI辅助诊断与决策支持,为赛车性能持续优化提供技术支撑。

Elastic 中国社区官方博客 218

5 分钟内将 56 页扫描文档转化为带引用的答案:面向搜索无法读取的文档的检索增强生成流水线

通过Elasticsearch与jina-ocr-v1结合,可将扫描版PDF(如56页植物指南)快速转化为可检索、可引用的知识库。该流程利用单一模型完成文档解析,输出结构化Markdown,再由Elasticsearch自动分块并生成嵌入向量,支持混合检索(关键词+语义)。用户以自然语言提问,系统返回带页码引用的答案及推荐商品,全程在统一平台内完成,无需自建流水线。

Elastic 中国社区官方博客 499

我们如何通过 70 多个拉取请求,将 OpenTelemetry Java agent 迁移到 invokedynamic

Elastic团队历时三年,将OpenTelemetry Java Agent从内联字节码插桩迁移至基于invokedynamic的类加载器隔离模式,支持100+插桩模块,提升可维护性与调试能力。相比此前三人团队的迁移,此次协作规模扩大,通过渐进式发布、运行时开关与自动化工具确保生产稳定。新架构实现插桩代码独立加载、兼容Java平台模块系统,并解决旧版本字节码兼容性问题。2026年7月,相关任务正式关闭,标志着迁移完成。

Elastic 中国社区官方博客 330

将 Elastic 引入 Claude:原因、方法与注意事项

Elastic发布Claude插件,将自身AI能力融入开发者工作流。从提交到上线仅用三周,但过程充满挑战:需绕过权限限制、调整版本管理策略(改用stable分支)、应对审核警告(如凭据提示、图标缺失等),且上线后无通知。插件首发于社区目录,需额外验证才能进入官方市场。作者强调,技术之外,与Anthropic团队的人际沟通是关键。经验表明,文档未覆盖的细节常需实战互动解决。欢迎开发者共享经验,共同推动生态发展。

Elastic 中国社区官方博客 117

告别繁琐控制台:Kabanos 如何将 MongoDB Compass 的易用性带入 Elasticsearch

Kabanos是一款专为macOS设计的本地优先桌面客户端,整合Elasticsearch与OpenSearch集群管理痛点。它结合MongoDB Compass式树状浏览与Kibana DevTools高效控制台,支持凭据安全加密、生产环境二次确认、只读模式及沙盒化架构,保障操作安全。内置查询库、自动化Routines与DryRun模式,提升运维效率。基于Electron与Zod校验,实现渲染层与网络请求隔离。快速上手:克隆仓库,启动Docker测试集群,运行pnpm dev即可使用。开源项目欢迎贡献,推

Elastic 中国社区官方博客 392
上一篇: Elasticsearch:关于在 Python 中使用 Elasticsearch 你需要知道的一切 - 8.x
下一篇: Elasticsearch:以更简单的方式编写具有逻辑条件的 Elasticsearch 查询 - query_string
Elastic 中国社区官方博客
Elastic 中国社区官方博客 企业官方账号 企业官方账号 领域专家: 大数据技术领域 领域专家: 大数据技术领域
博客等级 码龄12年 5万+粉丝 3111原创
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值