Elasticsearch同步数据库推荐/标准策略答案

【问题标题】：Elasticsearch sync database recommended / standard strategyElasticsearch同步数据库推荐/标准策略
【发布时间】：2023-03-29 21:20:01
【问题描述】：

我正在考虑为 Elasticsearch 维护索引的策略，我找到了一个 plugin，它可以很好地处理维护，但是我想与 Elasticsearch 更亲密一点，因为我真的很喜欢她和这个插件如果你明白我的意思，那会让游戏时间变得不那么亲密。

无论如何，如果我有一个更新频率相当高的数据集（比如 ~ 1 次更新 / 10 秒），我会遇到 Elasticsearch 的性能问题吗？当单行更改或需要完全重建索引时，是否可以进行部分索引更新？我计划实施的策略包括每当我对我的应用程序（python postgre）进行 CRUD 时修改索引，所以我不太关心的代码会有一些开销，只是性能。我的策略通用吗？

我使用了 Sphinx，它确实具有部分重新索引，它通过 cron 作业运行以保持同步，它在配置中定义的索引和 MySQL 表之间具有映射。这是 Sphinx 的推荐方法。有没有推荐的 Elasticsearch 方法？

【问题讨论】：

只是索引一个新文档（层次结构是索引/类型/文档）很好，应该没有恶意； rivers 的使用也很常见，例如jdbc river
rivers 现已弃用。

标签： elasticsearch

【解决方案1】：

有许多不同的策略来处理这个问题，没有简单的一刀切解决方案。

为了回答您的一些问题，首先，在 Elasticsearch/Lucene 中没有部分更新之类的东西。如果您更新文档中的单个字段，则整个文档都会被重写。在设计架构时，请注意这对性能的影响。但是，如果您更新单个文档，它应该可以立即使用。 Elasticsearch 是一个近乎实时的搜索引擎，您不必担心不断地重新生成索引。

对于您的写入负载一次更新/10 秒，默认性能设置应该没问题。事实上，对于 ES 来说，这是一个非常低的写入负载，它可以扩展得更高。例如，Netflix 在他们的一个集群中每分钟执行 700 万次更新。

就同步策略而言，我在"Keeping Elasticsearch in Sync" 上写了一篇深入的文章

【讨论】：