Elasticsearch：使用 _update_by_query 更新文档

已于 2022-12-22 09:13:20 修改
阅读量7.7k 收藏 13
点赞数 2
分类专栏： Elastic Elasticsearch 文章标签： elasticsearch 大数据
于 2020-04-16 19:37:40 首次发布
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/ubuntutouch/article/details/105564270
版权
Elastic 同时被 2 个专栏收录
1335 篇文章 842 订阅
订阅专栏
Elasticsearch
876 篇文章 566 订阅
订阅专栏

在很多的情况下，我们我们想更新我们所有的文档：

  • 添加一个新的 field 或者是一个字段变成一个 multi-field
  • 用一个值更新所有的文档，或者更新复合查询条件的所有文档

在今天的文章中，我们来讲一下 _update_by_query 的这几个用法。

准备数据

我们来创建一个叫做 twitter 的索引：

PUT twitter
{
  "mappings": {
    "properties": {
      "DOB": {
        "type": "date"
      },
      "address": {
        "type": "keyword"
      },
      "city": {
        "type": "text"
      },
      "country": {
        "type": "keyword"
      },
      "uid": {
        "type": "long"
      },
      "user": {
        "type": "keyword"
      },
      "province": {
        "type": "keyword"
      },
      "message": {
        "type": "text"
      },
      "location": {
        "type": "geo_point"
      }
    }
  }
}

我们使用如下的 bulk API 来把数据导入：

POST _bulk
{ "index" : { "_index" : "twitter", "_id": 1} }
{"user":"张三","message":"今儿天气不错啊，出去转转去","uid":2,"city":"北京","province":"北京","country":"中国","address":"中国北京市海淀区","location":{"lat":"39.970718","lon":"116.325747"}, "DOB":"1980-12-01"}
{ "index" : { "_index" : "twitter", "_id": 2 }}
{"user":"老刘","message":"出发，下一站云南！","uid":3,"city":"北京","province":"北京","country":"中国","address":"中国北京市东城区台基厂三条3号","location":{"lat":"39.904313","lon":"116.412754"}, "DOB":"1981-12-01"}
{ "index" : { "_index" : "twitter", "_id": 3} }
{"user":"李四","message":"happy birthday!","uid":4,"city":"北京","province":"北京","country":"中国","address":"中国北京市东城区","location":{"lat":"39.893801","lon":"116.408986"}, "DOB":"1982-12-01"}
{ "index" : { "_index" : "twitter", "_id": 4} }
{"user":"老贾","message":"123,gogogo","uid":5,"city":"北京","province":"北京","country":"中国","address":"中国北京市朝阳区建国门","location":{"lat":"39.718256","lon":"116.367910"}, "DOB":"1983-12-01"}
{ "index" : { "_index" : "twitter", "_id": 5} }
{"user":"老王","message":"Happy BirthDay My Friend!","uid":6,"city":"北京","province":"北京","country":"中国","address":"中国北京市朝阳区国贸","location":{"lat":"39.918256","lon":"116.467910"}, "DOB":"1984-12-01"}
{ "index" : { "_index" : "twitter", "_id": 6} }
{"user":"老吴","message":"好友来了都今天我生日，好友来了,什么 birthday happy 就成!","uid":7,"city":"上海","province":"上海","country":"中国","address":"中国上海市闵行区","location":{"lat":"31.175927","lon":"121.383328"}, "DOB":"1985-12-01"}

把一个字段变为 multi-field

在上面，我们有意识地把 city 字段设置为 text，但是在实际的应用中 city 一般来说是 keyword 类型。比如我们想对 city 这个字段来进行 aggregation。那么我们该如何纠正这个错误呢？我们需要把我们之前的 index 删除，并使用新的 mapping 再次重建吗？这在我们的实际的是使用中可能并不现实。这是因为你的数据可能是非常大的，而且这种改动可能会造成很多的问题。那么我们该如何解决这个问题呢？

一种办法是在不删除之前索引的情况下，我们把city变成为一个 mulit-field 的字段，这样它既可以是一个 keyword 的类型，也可以同样是一个 text 类型的字段。为此，我们来修改 twitter 的 mapping:

PUT twitter/_mapping
{
  "properties": {
    "DOB": {
      "type": "date"
    },
    "address": {
      "type": "keyword"
    },
    "city": {
      "type": "text",
      "fields": {
        "keyword": {
          "type": "keyword",
          "ignore_above": 256
        }
      }
    },
    "country": {
      "type": "keyword"
    },
    "uid": {
      "type": "long"
    },
    "user": {
      "type": "keyword"
    },
    "province": {
      "type": "keyword"
    },
    "message": {
      "type": "text"
    },
    "location": {
      "type": "geo_point"
    }
  }
}

请注意在上面，我们把 city 的字段变为一个 mult-field 的字段。即便我们已经把 mapping 修改了，但是我们的索引并没有把我们的 message 字段进行分词。为了达到这个目的，我们可以进行如下的操作：

POST twitter/_update_by_query

经过上面的操作后，message 字段将会被重新被索引，并可以被我们搜索。

GET twitter/_search
{
  "query": {
    "match": {
      "city.keyword": "北京"
    }
  }
}

上面显示的结果为：

  "hits" : {
    "total" : {
      "value" : 5,
      "relation" : "eq"
    },
    "max_score" : 0.21357408,
    "hits" : [
      {
        "_index" : "twitter",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 0.21357408,
        "_source" : {
          "user" : "张三",
          "message" : "今儿天气不错啊，出去转转去",
          "uid" : 2,
          "city" : "北京",
          "province" : "北京",
          "country" : "中国",
          "address" : "中国北京市海淀区",
          "location" : {
            "lat" : "39.970718",
            "lon" : "116.325747"
          },
          "DOB" : "1980-12-01"
        }
      },
   ...
}

当然由于这个字段变为 multi-field 的字段，它含有 city.keyword，我们可以对它进行聚合搜索：

GET twitter/_search
{
  "size": 0,
  "aggs": {
    "city_distribution": {
      "terms": {
        "field": "city.keyword",
        "size": 5
      }
    }
  }
}

上面我们对 city 进行统计，上面显示结果为：

  "aggregations" : {
    "city_distribution" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "北京",
          "doc_count" : 5
        },
        {
          "key" : "上海",
          "doc_count" : 1
        }
      ]
    }
  }

如果我们不修改 city 为 multi-field，我们将不能对这个字段进行统计了。

增加一个新的字段

同样我们可以通过 script 的方法来为我们的 twitter 增加一个新的字段，比如：

POST twitter/_update_by_query
{
  "script": {
    "source": "ctx._source['contact'] = \"139111111111\""
  }
}

通过上面的方法，我们把所有的文档都添加一个新的字段 contact，并赋予它一个同样的值：

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

上面的命令显示结果：

  "hits" : {
    "total" : {
      "value" : 6,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "twitter",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "uid" : 2,
          "country" : "中国",
          "address" : "中国北京市海淀区",
          "province" : "北京",
          "city" : "北京",
          "DOB" : "1980-12-01",
          "contact" : "139111111111",
          "location" : {
            "lon" : "116.325747",
            "lat" : "39.970718"
          },
          "message" : "今儿天气不错啊，出去转转去",
          "user" : "张三"
        }
      },
  ...
}

从上面我们可以看出来，有增加一个新的字段 contact。

修改已有的字段

假如我们想对所有在北京的文档里的 uid 都加1，那么我么有通过如下的方法：

POST twitter/_update_by_query
{
  "query": {
    "match": {
      "city.keyword": "北京"
    }
  },
  "script": {
    "source": """
       if(ctx._source.containsKey("content")) {
          ctx._source.content_length = ctx._source.content.length();
       } else {
          ctx._source.content_length = 0;
       }
       ctx._source['uid'] += params['one']";
    """
    "params": {
      "one": 1
    }
  }
}

在执行上面的命令后，我们进行查询：

GET twitter/_search
{
  "query": {
    "match": {
      "city.keyword": "北京"
    }
  }
}

显示结果：

  "hits" : {
    "total" : {
      "value" : 5,
      "relation" : "eq"
    },
    "max_score" : 0.24116206,
    "hits" : [
      {
        "_index" : "twitter",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 0.24116206,
        "_source" : {
          "uid" : 3,
          "country" : "中国",
          "address" : "中国北京市海淀区",
          "province" : "北京",
          "city" : "北京",
          "DOB" : "1980-12-01",
          "contact" : "139111111111",
          "location" : {
            "lon" : "116.325747",
            "lat" : "39.970718"
          },
          "message" : "今儿天气不错啊，出去转转去",
          "user" : "张三"
        }
      },
   ...
}

上面显示 city 为北京的所有的文档的 uid 的数值都被加1了。上面 _id 为1的原来的 uid 值为2，现在变为3。

没有动态mapping时，reindex索引

假设您创建了一个没有动态 mapping 的索引，将其填充了数据，然后添加了一个 mapping 值以从数据中获取更多字段：

PUT test
{
  "mappings": {
    "dynamic": false,   
    "properties": {
      "text": {"type": "text"}
    }
  }
}

POST test/_doc?refresh
{
  "text": "words words",
  "flag": "bar"
}

POST test/_doc?refresh
{
  "text": "words words",
  "flag": "foo"
}

PUT test/_mapping   
{
  "properties": {
    "text": {"type": "text"},
    "flag": {"type": "text", "analyzer": "keyword"}
  }
}

在上面我们创建一个叫做 test 的索引。首先它的动态 mapping 被禁止了，也就是在索引时凡是不在 mapping 定义的字段将被自动识别，它们仅仅存在于 source 里，我们不能对它进行搜索。为了纠正这个错误，我们在上面的最后一步尝试来修改它的 mapping 来解决这个问题。那么在新的 mapping 下，我们之前导入的文档能进行搜索吗？我们尝试如下的命令：

POST test/_search?filter_path=hits.total
{
  "query": {
    "match": {
      "flag": "foo"
    }
  }
}

我们尝试搜索所有 flag 中含有 foo 的文档，但是上面的返回结果是：

{
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    }
  }
}

那么问题出现在哪里呢？其实在我们修改完 mapping 以后，我们没有更新我们之前已经导入的文档。我们需要使用 _update_by_query 来做类似 reindex 的工作。我们使用如下的命令：

POST test/_update_by_query?refresh&conflicts=proceed

我们重新来搜索我们的文档：

POST test/_search?filter_path=hits.total
{
  "query": {
    "match": {
      "flag": "foo"
    }
  }
}

上面的查询显示的结果是：

{
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    }
  }
}

显然，在运行完 _update_by_query 后，我们可以找到我们的文档了。
 

针对大量数据的 reindex

上面所有的 _update_by_query 针对少量的数据还是很不错的。但是在我们的实际应用中，我们可能遇到很大的数据量，那么万一在 reindex 的过程中发生意外，那我们还需要从头开始吗？或者我们已经处理过的数据还需要再做一遍吗？一种通用的解决办法就是在我们的 mapping 中定义一个字段，比如叫做 flag，那么我们可以通过添加这个字段来跟踪我们的进度：

POST blogs_fixed/_update_by_query
{
  "query": {
    "range": {
      "flag": {
        "lt": 1
      }
    }
  },
  "script": {
    "source": "ctx._source['flag']=1"
  }
}

即使在 reindex 的过程已经失败了，我们再次运行上面的 _update_by_query 时，之前已经处理过的文件将不再被处理了。

_update_by_query 除了上面的用法之外，我们也可以结合 pipepline 来对我们的索引数据进行加工。详细的用法请参阅我之前的文章 “运用 Elastic Stack 分析 COVID-19 数据并进行可视化分析”。

更多阅读 “Elasticsearch: Reindex 接口”。

参考：

【1】Update By Query API | Elasticsearch Guide [8.5] | Elastic

Elastic 中国社区官方博客
关注
  • 2
    点赞
  • 踩
  • 13
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
专栏目录
博客
Elastic 将于 2024 年 5 月 25 日在上海举行线下 Meetup
05-13 717
讲师：阿里云技术专家 — 善仁(贾新禹)阿里云 Elasticsearch Serverless 技术负责人，15 年加入阿里后专注于搜索工程领域，擅长平台化和产品化，主导了阿里集团内多个搜索产品建设，服务了内外部大量客户。议题介绍：介绍阿里云 Elasticsearch Serverless 架构及其优势，并以淘宝母婴订单数据为例，展示如何快速将数据从数据库实时同步至 ES Serverless 中，并通过 Kibana 展示订单大盘进行运营分析。
博客
Elasticsearch：ES|QL 动手实践
11-14 1722
在我之前的文章 “”，我对 Elasticsearch 的最新查询语言 ES|QL 做了一个简单的介绍。在今天的文章中，我们详细来使用一些例子来展示 ES|QL 强大的搜索与分析功能。
博客
Elastic：如何成为一名 Elastic 认证工程师，Elastic 认证分析师及 Elastic 认证可观测性工程师
10-28 2万+
Elasticsearch 无疑是是目前世界上最为流行的大数据搜索引擎。根据 DB - Engines 的统计，Elasticsearch 雄踞排行榜第一名，并且市场还在不断地扩大：能够成为一名 Elastic 认证工程师也是很多开发者的梦想。这个代表了 Elastic 的最高认证，在业界也得到了很高的认知度。得到认证的工程师，必须除了具有丰富的 Elastic Stack 知识，而且必须有丰富的操作及有效的解决问题的能力。拥有这个认证证书，也代表了个人及公司的荣誉。针对个人的好处是，你可以..
博客
Elastic：开发者上手指南
02-25 14万+
你们好，我是Elastic的刘晓国。如果大家想开始学习Elastic的话，那么这里将是你理想的学习园地。在我的博客几乎涵盖了你想学习的许多方面。在这里，我来讲述一下作为一个菜鸟该如何阅读我的这些博客文章。我们可以按照如下的步骤来学习：1)Elasticsearch简介：对Elasticsearch做了一个简单的介绍2)Elasticsearch中的一些重要概念:cluster, n..........................................................
博客
Elastic：培训视频 - ​在生产环境中配置 Fleet Server 和 Elastic Agent 之间的安全
01-06 1万+
在这篇文章中，我将会把我写的有些内容录制成视频，供大家参考。希望对大家有所帮助。优酷的视频频道地址在这里。Elastic 简介及Elastic Stack 安装：优酷，腾讯 Elastic Stack docker 部署：优酷，腾讯 Elasticsearch中的一些重要概念（Cluster/Shards/Replica/Document/Type/Index）：优酷，腾讯 开始使用El...............
博客
Elasticsearch 简介
08-08 16万+
Elasticsearch是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch是由Elastic公司创建并开源维护的。它的开源代码位于https://github.com/elastic/elasticsearch。同时，Elastic公司也拥有Logstash及Kibana开源项目。这个三个开源项目组合在一起，就形成了 ELK软件栈。他们三个共同形成了一个强大的...
博客
如何在创建之前检测 Elasticsearch 将使用哪个索引模板
05-13 646
Elasticsearch 提供两种类型的索引模板：旧（legacy）索引模板和可组合 (composable) 索引模板。 Elasticsearch 7.8 中引入的可组合模板旨在替换旧模板，两者仍然可以在 Elasticsearch 8 中使用。本文探讨了这些模板之间的差异以及它们的交互方式。 特别是，我们将重点关注如何在创建索引时检测将使用哪个模板。 让我们首先了解如何创建不同类型的索引模板。
博客
使用 AI Assistant for Observability 和组织的运行手册增强 SRE 故障排除
05-11 1002
​可观测性 AI 助手可帮助用户使用自然语言界面探索和分析可观测性数据，利用自动函数调用来请求、分析和可视化数据，将其转换为可操作的可观测性。 该助手还可以建立一个由 Elastic Learned Sparse EncodeR (ELSER) 提供支持的知识库，以提供来自私人数据的附加上下文和建议，以及使用 RAG（检索增强生成）的大型语言模型 (LLM)。 Elastic 的 Stack — 作为一个向量数据库，具有开箱即用的语义搜索以及 LLM 集成和可观测性解决方案的连接器 — 是一个完美的工具包
博客
Elasticsearch：RBAC 和 RAG - 最好的朋友
05-10 932
检索增强生成 (RAG) 通过提供额外的上下文或信息来增强大型语言模型 (LLM) 的知识，从而提高响应质量。尽管 LLMs 拥有令人印象深刻的能力，但也有其局限性，例如无法在培训后保留新信息以及对不熟悉的主题产生错误答案的倾向。为了克服这些限制，专有的、相关的和更新的数据可以与提示相结合，从而为 LLM 奠定基础，并导致更准确和用户友好的响应。有关 RAG 的详细信息，。RBAC -ole-asedccessontrol，基于角色的访问控制。
博客
将本地托管模型与 Elastic AI Assistant 结合使用的好处
05-10 910
当今公共部门组织利用生成式人工智能解决安全挑战的一种方式。凭借其筛选大量数据以发现异常模式的能力，生成式人工智能现在在帮助团队保护其组织免受网络威胁方面发挥着关键作用。它还可以帮助安全专业人员提高技能并弥补知识差距。通过处理复杂的数据分析并将原始数据转化为有用的见解，生成式人工智能使团队能够专注于规划他们的响应，而不仅仅是管理数据。Elastic AI Assistant 集成到 Elastic Security 中，可以快速识别、分析和响应潜在威胁，减少误报的可能性。它与各种被称为。
博客
Elastic 基于 RAG 的 AI 助手：利用 LLM 和私有 GitHub 问题分析应用程序问题
05-09 960
作为 SRE，分析应用程序比以往更加复杂。你不仅必须确保应用程序以最佳状态运行以确保良好的客户体验，而且还必须了解某些情况下的内部工作原理以帮助排除故障。分析基于生产的服务中的问题是一项团队运动。它需要 SRE、DevOps、开发和支持才能找到根本原因并进行潜在的补救。如果它有影响，那就更糟了，因为这是一场与时间的赛跑。无论情况如何，都有大量信息需要消耗和处理。这不仅包括客户正在经历的情况，还包括有助于提供最合适解决方案的内部数据。
博客
介绍适用于 Node.js 的 Elastic OpenTelemetry 发行版
05-09 809
我们很高兴地宣布推出的 alpha 版本。该发行版是 OpenTelemetry Node.js SDK 的轻量级包装，可以让你更轻松地开始使用 OpenTelemetry 来观察 Node.js 应用程序。
博客
Observability：监控与可观察性不同的 3 个原因
05-08 671
监控是收集、摄取和分析应用程序、基础设施和/或云遥测数据以评估系统运行状况的过程。监控依赖于指标，例如 CPU 或内存使用情况以及网络流量、日志和跟踪。这些数据使 IT 团队能够实时跟踪其基础设施和应用程序的性能和可用性。监控工具和平台可以提供仪表板和警报，并具有报告功能，以帮助 IT 团队监控组件、识别预测问题并解决给定环境中出现的问题。然而，监控工具传统上是孤立的，因此并不总是适合现代云架构和更大的环境。可观测性是一组实践和工具，使 IT 用户能够通过其生成的遥测和操作数据获得整个环境的整体视图。
博客
红帽为 Red Hat OpenShift AI 扩大与 Elasticsearch 向量数据库的合作
05-08 1059
红帽 OpenShift AI 是一个混合 MLOps 平台，它将 IT、数据科学和应用程序开发团队聚集在一起。它旨在简化生成式人工智能应用程序的开发和部署，提供针对分布式工作负载量身定制的全面基础设施堆栈。这包括训练、优化、微调和部署基础和预测人工智能模型。与模型构建者合作有助于提供对各种预构建模型的访问。开发人员和数据科学家可以在同一平台上协同工作，从而极大地增强协作。该平台促进端到端人工智能生命周期管理 —— 从模型开发和培训到部署、服务和持续监控。模型开发。
博客
Elasticsearch：使用 MongoDB connector 同步数据到 Elasticsearch
05-07 1903
MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。Elasticsearch 是一个高效强大的大数据搜索引擎。它的 Speed, Scale 及 Relevance 是很多数据库不具有的。通过 Elasticsearch 的高效搜索引擎，我们可以快速地搜索相关的内容，我们也可以使用 Kibana 所提供的可视化为数据提供洞
博客
Elastic 通过 AI 驱动的安全分析改变 SIEM 游戏
05-07 1036
​传统的安全信息与事件管理系统（SIEM）在很大程度上依赖屏幕背后的人类才能取得成功。警报、仪表盘、威胁猎杀以及在信号洪流中找到上下文，所有这些都需要大量的人力。搜索人工智能将颠覆这一旧模式，并将传统的 SIEM 替换为适用于现代安全运营中心的人工智能驱动的安全分析解决方案。想象一下，一个系统可以筛选所有的数据，忽略噪音并识别出关键信息，发现特定的攻击，并制定具体的修复措施。Elastic Search AI 平台支持的 Elastic Security 正在实现这一进化，用人工智能取代了配置、调查和响应
博客
Elasticsearch：理解人工智能相似性搜索
05-06 1159
我认为，知识检索和相似性搜索是企业成功实施人工智能的切入点。过去，关键词搜索对所有网站来说几乎是必须的，但我们很快会看到，知识检索将成为最基本的标准。当我尝试使用没有知识搜索功能的 API 文档时，我已经感到非常沮丧。我期待看到你利用知识检索和相似性搜索提出的新颖而惊人的想法。更多关于向量搜索的知识，请详细阅读专栏 “AI。
博客
Elasticsearch：如何使用 Java 对索引进行 ES|QL 的查询
05-05 1451
​在我之前的文章 “Elasticsearch：对 Java 对象的 ES|QL 查询”，我详细介绍了如何使用 Java 来对 ES|QL 进行查询。对于不是很熟悉 Elasticsearch 的开发者来说，那篇文章里的例子还是不能单独来进行运行。在今天的这篇文章中，我来详细地介绍如何把那个例子跑起来。更多关于 ES|QL 的动手实践，请阅读文章 “Elasticsearch：ES|QL 查询展示”。
博客
评估 Elasticsearch 中的标量量化
05-04 1333
​在 8.13 版本中，我们为 Elasticsearch 引入了标量量化功能。通过使用此功能，最终用户可以提供浮点向量，这些向量在内部作为字节向量进行索引，同时在索引中保留浮点向量，以便可选地重新评分。这意味着他们可以将索引内存需求降低四分之一，这是其主要成本。目前，这是一个可选择加入的功能，但我们认为与将向量索引为浮点数相比，这是一个更好的权衡。在 8.14 版本中，我们将使其成为默认设置。然而，在这样做之前，我们希望对质量影响进行系统评估。
博客
Elasticsearch：对 Java 对象的 ES|QL 查询
05-03 1037
ES|QL 是 Elasticsearch 引入的一种新的查询语言，它将简化的语法与管道操作符结合起来，使用户能够直观地推断和操作数据。官方 Java 客户端的新版本 8.13.0 引入了对 ES|QL 查询的支持，提供了一个新的 API，允许轻松执行查询，并自动将结果翻译为 Java 对象。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值