经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 程序设计 » Elasticsearch » 查看文章
elasticsearch6.7 05. Document APIs（10）Reindex API
来源：cnblogs　　作者：说_不_得　　时间：2019/4/15 9:10:34　　对本文有异议

9、REINDEX API

Reindex要求为源索引中的所有文档启用_source。

reindex 不会配置目标索引，不会复制源索引的设置。你需要在reindex之前先指定mapping，分片数量，副本数量等选项。

_reindex最常用的一种方式是复制一个索引。下例会将twitter索引中的文档复制到new_twitter索引中：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter"
  8.   }
  9. }

返回结果：

  1. {
  2.   "took" : 147,
  3.   "timed_out": false,
  4.   "created": 120,
  5.   "updated": 0,
  6.   "deleted": 0,
  7.   "batches": 1,
  8.   "version_conflicts": 0,
  9.   "noops": 0,
  10.   "retries": {
  11.     "bulk": 0,
  12.     "search": 0
  13.   },
  14.   "throttled_millis": 0,
  15.   "requests_per_second": -1.0,
  16.   "throttled_until_millis": 0,
  17.   "total": 120,
  18.   "failures" : [ ]
  19. }

和 _update_by_query API 一样，_reindex从原索引获取快照，但它的目标索引必须是不同的索引，所以不太可能发生版本冲突。dest元素可以向 index API 一样配置，控制乐观锁。例如，省略version_type（和上述一样）或者将其设置为internal，会导致Elasticsearch草率地将文档转储到目标索引，从而恰巧覆盖具有相同type和id的文档：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter",
  8.     "version_type": "internal"
  9.   }
  10. }

设置version_type为external会使Elasticsearch保存源文档的version，创建任何不存在目标索引的文档，并更新任何源文档version比目标文档version要大的文档：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter",
  8.     "version_type": "external"
  9.   }
  10. }

设置op_type为create 会导致 _reindex仅在目标索引中创建缺少的文档。索引已存在的文档都会导致版本冲突：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter",
  8.     "op_type": "create"
  9.   }
  10. }

默认的版本冲突会导致_reindex 进程终止，你可以在请求体中设置"conflicts": "proceed"来指示_reindex继续处理版本冲突之后的文档。请务必注意，其他错误类型的处理不受“conflict”参数的影响。当请求体中设置"conflicts": "proceed"时，_reindex进程将继续发生版本冲突并返回遇到的版本冲突数：

  1. POST _reindex
  2. {
  3.   "conflicts": "proceed",
  4.   "source": {
  5.     "index": "twitter"
  6.   },
  7.   "dest": {
  8.     "index": "new_twitter",
  9.     "op_type": "create"
  10.   }
  11. }

你可以通过在source字段内添加type字段或query字段来限制文档。如下例仅会将索引twitter中的kimchy复制到索引new_twitter中：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter",
  5.     "type": "_doc",
  6.     "query": {
  7.       "term": {
  8.         "user": "kimchy"
  9.       }
  10.     }
  11.   },
  12.   "dest": {
  13.     "index": "new_twitter"
  14.   }
  15. }

可以在source字段中同时列出type和index，允许在一个请求中复制大量数据。下例会复制来自twitter索引和blog索引的_doc 类型和post类型的文档：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": ["twitter", "blog"],
  5.     "type": ["_doc", "post"]
  6.   },
  7.   "dest": {
  8.     "index": "all_together",
  9.     "type": "_doc"
  10.   }
  11. }

Reindex API 不会处理ID冲突，以最后写入的文档为准，但reindex的顺序通常是不可预测，因此依赖此行为并不是一个好主意。应该使用脚本确保ID是唯一的。

也可以限制复制文档的数量。下例仅仅从twitter索引复制一个文档到new_twitter索引：

  1. POST _reindex
  2. {
  3.   "size": 1,
  4.   "source": {
  5.     "index": "twitter"
  6.   },
  7.   "dest": {
  8.     "index": "new_twitter"
  9.   }
  10. }

你可以指定设置sort参数指定排序规则。sort会降低scroll的效率，但是有时候必须使用。如果可以的话，最好限制size的大小。下例会从twitter索引中复制10000个文档到new_twitter索引：

  1. POST _reindex
  2. {
  3.   "size": 10000,
  4.   "source": {
  5.     "index": "twitter",
  6.     "sort": { "date": "desc" }
  7.   },
  8.   "dest": {
  9.     "index": "new_twitter"
  10.   }
  11. }

可以使用_source参数过滤字段，例如，可以使用source 从twitter索引中过滤一部分字段，如下所示：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter",
  5.     "_source": ["user", "_doc"]
  6.   },
  7.   "dest": {
  8.     "index": "new_twitter"
  9.   }
  10. }

_redix和_update_by_query一样也支持脚本，它可以修改一个文档，但和_update_by_query有区别，这个script仅允许修改文档的metadata：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter",
  8.     "version_type": "external"
  9.   },
  10.   "script": {
  11.     "source": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
  12.     "lang": "painless"
  13.   }
  14. }

和_update_by_query一样，你可以设置ctx.op改变在目标索引执行的操作：

  • noop
    • 设置 ctx.op = "noop"，如果你的script确定文档不需要索引到目标索引。这个空操作将会反映到响应体的noop计数器。
  • delete
    • 设置ctx.op = "delete"，如果你的script确定必须要从目标索引中删除文档。删除操作会反映到响应体的deleted计数器。

设置ctx.op为其他值会导致错误。

你甚至可以改变如下的元数据，但一定要小心地操作：

  • _id
  • _type
  • _index
  • _version
  • _routing
  • _parent

设置_version =null或者从ctx中清空它，等价于没有在index 请求中发送version参数。不管目标索引文档的版本或者你在_reindex请求中指定的版本类型是什么，它都会导致目标索引的文档被覆盖。

默认情况下，如果_reindex查询到一个指定了routing参数的文档，在新文档中也会保留该参数，除非你在script中改变它。你可以在dest字段设置routing从而改变这个设置：

  • keep
    • 文档的路由值在新索引中保持不变。这是默认值。
  • discard
    • 原索引中文档的routing值在新索引中变为null
  • =<some text>
    • 文档的路由值在新索引中变为指定值。

例如，你可以使用以下请求从源索引中复制所有公司名是cat的文档到目标索引，并且指定它们的routing值都是cat：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "source",
  5.     "query": {
  6.       "match": {
  7.         "company": "cat"
  8.       }
  9.     }
  10.   },
  11.   "dest": {
  12.     "index": "dest",
  13.     "routing": "=cat"
  14.   }
  15. }

默认，_reindex每次scroll查询的文档数是1000。你可以在source元素中使用size参数改变这个大小：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "source",
  5.     "size": 100
  6.   },
  7.   "dest": {
  8.     "index": "dest",
  9.     "routing": "=cat"
  10.   }
  11. }

你也可以指定pipeline参数使用Ingest Node节点特性：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "source"
  5.   },
  6.   "dest": {
  7.     "index": "dest",
  8.     "pipeline": "some_ingest_pipeline"
  9.   }
  10. }

9.1 从远程重建索引（Reindex from Remote）

reindex支持从远程的集群中获取源索引数据：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "remote": {
  5.       "host": "http://otherhost:9200",
  6.       "username": "user",
  7.       "password": "pass"
  8.     },
  9.     "index": "source",
  10.     "query": {
  11.       "match": {
  12.         "test": "data"
  13.       }
  14.     }
  15.   },
  16.   "dest": {
  17.     "index": "dest"
  18.   }
  19. }

host参数必须包含协议，主机和端口（例如：https://otherhost:9200）和可选路径（例如https://otherhost:9200/proxy）。username和 password是可选的，当Elasticsearch节点需要basic auth时会使用它们。使用基本身份验证时务必使用https，否则密码将以纯文本格式发送。有一系列设置可用于配置https连接的行为。

远程主机必须要在elasticsearch.yaml使用reindex.remote.whitelist属性显式指定允许连接的白名单。它可以是一个逗号分隔的列表((e.g. otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*)。白名单忽略协议，仅仅使用端口和主机。例如：

  1. reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*"

必须将白名单配置在所有进行reindex的节点上。

这个特性可以和任何版本的远程集群交互。允许你从任何版本的Elasticsearch升级到当前版本。

要将查询发送到旧版的Elasticsearch，请将查询参数直接发送到远程主机。

从远程群集执行reindex 不支持手动或自动切片。

远程服务器使用一个最大值是100mb的缓冲区。如果远程索引包含非常大的文档，你需要使用一个更小的批量大小（每一批的数量不要超过缓冲区大小），下面的示例将批量大小设置为10：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "remote": {
  5.       "host": "http://otherhost:9200"
  6.     },
  7.     "index": "source",
  8.     "size": 10,
  9.     "query": {
  10.       "match": {
  11.         "test": "data"
  12.       }
  13.     }
  14.   },
  15.   "dest": {
  16.     "index": "dest"
  17.   }
  18. }

你也可以使用socket_timeout字段指定请求的套接字进行读取操作的超时时间，connect_timeout字段指定连接超时时间。默认都是30s。下例将套接字读取超时设置为一分钟，将连接超时设置为10秒：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "remote": {
  5.       "host": "http://otherhost:9200",
  6.       "socket_timeout": "1m",
  7.       "connect_timeout": "10s"
  8.     },
  9.     "index": "source",
  10.     "query": {
  11.       "match": {
  12.         "test": "data"
  13.       }
  14.     }
  15.   },
  16.   "dest": {
  17.     "index": "dest"
  18.   }
  19. }

9.2 url参数（URL Parameters）

参考上一节

9.3 配置SSL参数（Configuring SSL parameters）

略

9.4 响应体（Response body）

json响应如下：

  1. {
  2.   "took": 639,
  3.   "timed_out": false,
  4.   "total": 5,
  5.   "updated": 0,
  6.   "created": 5,
  7.   "deleted": 0,
  8.   "batches": 1,
  9.   "noops": 0,
  10.   "version_conflicts": 2,
  11.   "retries": {
  12.     "bulk": 0,
  13.     "search": 0
  14.   },
  15.   "throttled_millis": 0,
  16.   "requests_per_second": 1,
  17.   "throttled_until_millis": 0,
  18.   "failures": [ ]
  19. }
  • took
    • 整个操作耗费的毫秒数
  • timed_out
    • 如果在执行 reindex 操作时出现超时，那么这个标识将会返回 true
  • total
    • 成功执行操作的文档的数量
  • updated
    • 成功的更新了多少个文档
  • ceated
    • 成功的创建了多少个文档
  • deleted
    • 成功的删除了多少个文档
  • batches
    • 回滚数
  • verison_conflicts
    • 操作过程中出现版本冲突的数量
  • noops
    • 由于 ctx.op=noop 设置造成的忽略的文档数
  • retries
    • 重复尝试的次数，bulk 是批量更新操作重复尝试的次数，search 是查询的重复尝试次数
  • throthled_millis
    • requests_per_second 参数引起的请求等待时间
  • requests_per_second
    • 在操作过程中，每秒执行的请求数
  • throttled_until_millis
    • 执行reindex时这个值始终0，只在在调用Task API时该值才有意义，它表示下一次（自纪元以来）为了符合requests_per_second将再次执行请求的毫秒数。
  • failures
    • 执行失败的数组，包含在执行过程中任何不可恢复的错误。如果这个数组不是空的，那么请求会因为这些失败而中止。reindex 是使用批处理实现的，任何失败都会导致整个执行被中止。可以使用conflicts参数来防止reindex在版本冲突时造成操作中止。

9.5 结合 taskAPi 使用（Works with the Task API）

您可以使用 Task API 获取任何正在进行 update_by_query 请求的状态：

  1. GET _tasks?detailed=true&actions=*reindex

返回值：

  1. {
  2.   "nodes" : {
  3.     "r1A2WoRbTwKZ516z6NEs5A" : {
  4.       "name" : "r1A2WoR",
  5.       "transport_address" : "127.0.0.1:9300",
  6.       "host" : "127.0.0.1",
  7.       "ip" : "127.0.0.1:9300",
  8.       "attributes" : {
  9.         "testattr" : "test",
  10.         "portsfile" : "true"
  11.       },
  12.       "tasks" : {
  13.         "r1A2WoRbTwKZ516z6NEs5A:36619" : {
  14.           "node" : "r1A2WoRbTwKZ516z6NEs5A",
  15.           "id" : 36619,
  16.           "type" : "transport",
  17.           "action" : "indices:data/write/reindex",
  18.           "status" : {    
  19.             "total" : 6154,
  20.             "updated" : 3500,
  21.             "created" : 0,
  22.             "deleted" : 0,
  23.             "batches" : 4,
  24.             "version_conflicts" : 0,
  25.             "noops" : 0,
  26.             "retries": {
  27.               "bulk": 0,
  28.               "search": 0
  29.             },
  30.             "throttled_millis": 0,
  31.             "requests_per_second": -1,
  32.             "throttled_until_millis": 0
  33.           },
  34.           "description" : "",
  35.           "start_time_in_millis": 1535149899665,
  36.           "running_time_in_nanos": 5926916792,
  37.           "cancellable": true,
  38.           "headers": {}
  39.         }
  40.       }
  41.     }
  42.   }
  43. }

status：这个对象包含了当前任务的实际状态。total 字段是本次操作需要重新索引的文档数。你可以通过 updated, created, and deleted 字段估计处理进度。当以上几个字段的和等于 total 字段时，请求就执行完毕了。

你可以使用 task id 查看某个任务。下例查看task id为 r1A2WoRbTwKZ516z6NEs5A：36619的任务信息：

  1. GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619

该 API 可以与wait_for_comletion=false集成使用，可以清晰的查看已完成任务的状态。如果任务已经完成，并且在其上设置了wait_for_completion=false，那么请求将会返回结果或是错误字段。此功能的代价是当wait_for_completion=false时会在.tasks/task/${taskId}目录下会创建文档。您可以根据需要删除该文档。

9.6 取消任务(Works with the Cancel Task API)

任何_update_by_query操作都可以通过task cancel API来取消，如：

  1. POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel

取消应该执行很快，但可能需要几秒钟。在此期间上面的 task status API将继续列出该任务，直到它完全被取消了。

9.7 阈值(Rethrottling)

在正在执行的请求中，requests_per_second的值可以在运行时通过_rethrotted API进行修改：

  1. POST _update_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1

可以使用tasks API找到任务ID。

和 requests_per_seconds 参数设置一样，rethrottling 参数可以是 - 1 (禁用限制)或是其他十进制数(如 1.7 或 12 )。rethrottling 参数能提高查询速度且会立即生效，但是降低速度必须等到当前操作执行完后才起作用。这可以防止滚动超时

9.7.1 重建索引以更改字段的名称

_reindex可用于构建具有重命名字段的索引副本。假设您创建一个包含如下所示文档的索引：

  1. POST test/_doc/1?refresh
  2. {
  3.   "text": "words words",
  4.   "flag": "foo"
  5. }

但你不喜欢flag ，并希望用tag替换它。可以如下创建另一个索引：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "test"
  5.   },
  6.   "dest": {
  7.     "index": "test2"
  8.   },
  9.   "script": {
  10.     "source": "ctx._source.tag = ctx._source.remove(\"flag\")"
  11.   }
  12. }

查询新的文档：

  1. GET test2/_doc/1

响应结果：

  1. {
  2.   "found": true,
  3.   "_id": "1",
  4.   "_index": "test2",
  5.   "_type": "_doc",
  6.   "_version": 1,
  7.   "_seq_no": 44,
  8.   "_primary_term": 1,
  9.   "_source": {
  10.     "text": "words words",
  11.     "tag": "foo"
  12.   }
  13. }

9.8 切片 (slicing)

Reindex 支持 sliced scroll 来使 reindex 操作并行进行。这能提高效率并且提供了一种将请求分解为较小的部分的便捷方式。

9.8.1 手动切片 (Manually slicing)

通过为每个请求提供切片 ID 和切片总数，手动将 _reindex 操作进行分解：

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "twitter",
  5.     "slice": {
  6.       "id": 0,
  7.       "max": 2
  8.     }
  9.   },
  10.   "dest": {
  11.     "index": "new_twitter"
  12.   }
  13. }
  14. POST _reindex
  15. {
  16.   "source": {
  17.     "index": "twitter",
  18.     "slice": {
  19.       "id": 1,
  20.       "max": 2
  21.     }
  22.   },
  23.   "dest": {
  24.     "index": "new_twitter"
  25.   }
  26. }

你可以这样验证上述 api 的结果：

  1. GET _refresh
  2. POST new_twitter/_search?size=0&filter_path=hits.total

返回如下的的结果：

  1. {
  2.   "hits": {
  3.     "total": 120
  4.   }
  5. }

9.8.2 自动切片 (Automatic slicing)

也可以让 _reindex 自动并行地滚动切片。使用 slices 指定要使用的切片数：

  1. POST _reindex?slices=5&refresh
  2. {
  3.   "source": {
  4.     "index": "twitter"
  5.   },
  6.   "dest": {
  7.     "index": "new_twitter"
  8.   }
  9. }

您可以通过下列语句验证运行结果：

  1. POST new_twitter/_search?size=0&filter_path=hits.total

返回如下的的结果：

  1. {
  2.   "hits": {
  3.     "total": 120
  4.   }
  5. }

slices 设置为 auto 将允许 ElasticSearch 选择要使用的切片数。此设置将使用一个分片一个切片，直至达到某个限制。如果存在多个源索引，它将根据具有最少分片的那个索引所拥有的分片数来作为切片数。

向_reindex 添加 slices 只会自动执行上一节中使用的手动过程，这意味着它有一些怪癖：

  • 您可以在 Tasks API 中查看这些请求。这些子请求是具有 slices 请求的任务的 “子 " 任务。
  • 仅使用 slices 获取请求的任务状态 (包含已完成切片的状态)。
  • 这些子请求可单独寻址，例如取消和重新限制。
  • 使用 slices 重新处理请求将按比例重新调整未完成的子请求。
  • 使用 slices 取消请求将取消每个子请求。
  • 由于 slices 的性质，每个子请求都不会获得完全均匀的文档部分。这些切片文档都会被处理，但某些切片可能比其他切片分到更大的文档。
  • 像 requests_per_second 这样的参数和带有 size 的 slices 请求 (按指定比例分配给每个子请求)。将其与上述关于分布不均匀的点相结合，您应该得出结论，使用 slices 的 size 可能不会删除指定大小的文档。
  • 每个子请求都会获得和源索引略有不同的快照，尽管这些快照几乎同时进行。

9.8.3 选择 slices 的数量（Picking the number of slices）

如果 slices 设置为 auto，elasticsearch 将会自动为大多数索引选择一个合理的数量。如果您设置手动切片或以其他方式来调整自动切片，请遵循以下准则：

当切片的数量等于索引的分片数时，查询性能最好。如果这个数量太大（如 500）, 请选择一个较小的数字，因为太多的切片会影响性能。设置高于分片数的切片通常不会提高效率反而会增加开销。

indexing 的性能与可用的切片数量呈正相关。

查询或索引是否是影响此时运行时性能的主要原因，这取决于reindexed时的文档和集群的资源。

9.9 重建更多的索引（ Reindexing many indices）

如果你有很多索引要重新索引，通常最好一次重新索引它们，而不是使用全局模式来获取许多索引。这样的话如果reindex时有任何错误，您可以通过删除部分已完成的索引，然后让该索引重新执行一次reindex，从而恢复之前的流程。它还使得流程的并行化非常简单：将索引列表拆分为reindex并并行运行每个列表。

One-off bash脚本似乎很适合这种操作：

  1. for index in i1 i2 i3 i4 i5; do
  2.   curl -HContent-Type:application/json -XPOST localhost:9200/_reindex?pretty -d'{
  3.     "source": {
  4.       "index": "'$index'"
  5.     },
  6.     "dest": {
  7.       "index": "'$index'-reindexed"
  8.     }
  9.   }'
  10. done

9.10 每日重复指数（ Reindex daily indices）

尽管有上述建议，您可以将_reindex与Painless结合使用新模板应用于现有文档以实现每日重建索引。

假设您的索引由以下文档组成：

  1. PUT metricbeat-2016.05.30/_doc/1?refresh
  2. {"system.cpu.idle.pct": 0.908}
  3. PUT metricbeat-2016.05.31/_doc/1?refresh
  4. {"system.cpu.idle.pct": 0.105}

metricbement- *索引的新模板已加载到Elasticsearch中，但它仅适用于新创建的索引。Painless 可用于reindex 已经存在的文档并应用于新模板。

下面的脚本从索引名称中提取日期，并创建一个在原索引上附加了-1的新的索引。下例将metricbeat-2016.05.31索引中的所有数据都重新编入metricbeat-2016.05.31-1索引中。

  1. POST _reindex
  2. {
  3.   "source": {
  4.     "index": "metricbeat-*"
  5.   },
  6.   "dest": {
  7.     "index": "metricbeat"
  8.   },
  9.   "script": {
  10.     "lang": "painless",
  11.     "source": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'"
  12.   }
  13. }

现在可以在* -1索引中找到先前metricbeat索引中的所有文档：

  1. GET metricbeat-2016.05.30-1/_doc/1
  2. GET metricbeat-2016.05.31-1/_doc/1

以前的方法还可以与更改字段名称结合使用，以仅将现有数据加载到新索引中，并根据需要重命名任何字段。

9.11 提取索引的随机子集（Extracting a random subset of an index）

_reindex可用于提取索引的随机子集以进行测试：

  1. POST _reindex
  2. {
  3.   "size": 10,
  4.   "source": {
  5.     "index": "twitter",
  6.     "query": {
  7.       "function_score" : {
  8.         "query" : { "match_all": {} },
  9.         "random_score" : {}
  10.       }
  11.     },
  12.     "sort": "_score"    【1】
  13.   },
  14.   "dest": {
  15.     "index": "random_twitter"
  16.   }
  17. }

【1】：_reindex默认按_doc排序，除非您将排序覆盖为_score，否则random_score将不起作用。

原文链接：http://www.cnblogs.com/wtc1994/p/10708497.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Elasticsearch热门文章

  • ES 14 - (底层原理) Elasticsearch内部如何处理不同type的数据
  • ES 15 - Elasticsearch中的数据类型 (text、keyword、date、geo等)
  • java中elasticsearch7.x关于nested类型的api使用，新增+更新
  • Elasticsearch 映射参数详解 fields
  • [Elasticsearch] ES聚合场景下部分结果数据未返回问题分析
  • ES 22 - Elasticsearch中如何进行日期(数值)范围查询
  • Elasticsearch查询之Term?Query示例解析
  • ElasticSearch 实现分词全文检索 - SpringBoot 完整实现 Demo 附源码【完结篇】
  • ElasticStack学习（十）：深入ElasticSearch搜索之QueryFiltering、多/单字符串的多字段查询
  • ElasticSearch7 设置外网访问

    • Elasticsearch推荐文章

  • 利用Elasticsearch实现地理位置、城市搜索服务
  • 日志采集/分析
  • ELKF（elasticsearch、logstash、kibana、filebeat）搭建及收集nginx日志特昂糖-
  • ElasticSearch性能原理拆解
  • Elasticsearch使用实战以及代码详解
  • 使用 Docker Compose V2 快速搭建日志分析平台 ELK (Elasticsearch、Logstash 和 Kibana)
  • 【解决方案】MySQL5.7 百万数据迁移到 ElasticSearch7.x 的思考
  • K8s部署轻量级日志收集系统EFK（elasticsearch + filebeat + kibana）
  • Docker下elasticsearch8部署、扩容、基本操作实战(含kibana)
  • Elasticsearch 保姆级入门篇

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号