我应该使用数据库ID作为弹性ID吗？

Question

我对弹性很陌生，并开始将我的数据库表同步为弹性索引。首先，我使用表ID(UUID)作为弹性id，但我开始怀疑，从长期来看，这是性能上的错误还是灵活性上的错误？如有任何建议，将不胜感激。

Answer 1

我认为这种做法实际上应该是一种最佳做法。当从(已更改的) DB更新ES索引中的数据时，可以直接对文档进行处理。

对于我们来说，使用_bulk更新API非常有用，它要求每个项都有一个明确的id。

在DB端的每一个更改上，我们都对更改通知进行排队，更改的对象将获得JSON序列化，并异步地并以更大的批次发送到ES。这在性能上产生了巨大的变化。另一方面，搜索性能并不取决于_id AFAIK的长度，即使当您通过_id查找时也是如此。所以你的DB UUID应该很好。特别是由于_ids可以是字母数字，它们不仅限于数字。

通过_id在ES结果和记录系统之间保持1:1的关系(我假设这就是您的数据库的目的)也有利于透明性。在任何情况下，您都希望将数据库ID存储为某些字段，最理想的情况是索引，以帮助您了解该文档的来源。

因此，与其创建您自己的ID字段，不如立即使用内置的_id字段和数据库提供的数据。