我是弹性的新手，并开始将我的数据库表同步到弹性索引中。我开始使用表 ID(UUID) 作为弹性 id，但我开始怀疑从长远来看这在性能或灵活性方面是否是一个错误？任何建议将不胜感激。
最佳答案
我认为这种方法实际上应该是最佳实践。当您从(更改的)数据库更新 ES 索引中的数据时，您可以直接寻址文档。
使用 _bulk 更新 API 对我们来说非常有效，它需要每个项目有一个显式 ID。
对于数据库端的每次更改，我们都会将更改通知排入队列，更改的对象会以 JSON 序列化并以更大批量的方式异步发送到 ES。 这带来了巨大的性能差异。另一方面，搜索性能并不取决于 _id AFAIK 的长度，即使您通过 _id 查找时也是如此。所以你的数据库 UUID 应该没问题。特别是由于 _id 可以是字母数字，因此它们不仅仅限于数字。
通过 _id 在 ES 结果和您的记录系统之间建立 1:1 关系(我假设这就是您的数据库的用途)对于透明度目的也是有利的。无论如何，您都希望将数据库 ID 存储为某个字段，最好是建立索引，至少可以帮助您了解该文档的来源。
因此，您最好立即使用内置的 _id 字段以及数据库提供的数据，而不是创建自己的 ID 字段。
关于elasticsearch - 我应该使用数据库 ID 作为弹性 ID，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52710918/