Должен ли я использовать идентификаторы базы данных в качестве эластичных идентификаторов

Question

Я новичок в эластичном и начинаю синхронизировать свои таблицы базы данных в эластичные индексы.Я начал с использования идентификатора таблицы (UUID) в качестве эластичного идентификатора, но я начинаю задаваться вопросом, является ли это ошибкой с точки зрения производительности или гибкости в долгосрочной перспективе?Любой совет будет оценен.

Answer 1

Я думаю, что этот подход должен быть лучшей практикой.Когда вы обновляете данные в своем индексе ES из (измененной) БД, вы можете обратиться к документу напрямую .

Для нас отлично работает _bulk API обновления, для которого требуется явный идентификатор для элемента.

При каждом изменении на стороне БД мы ставим в очередь уведомления об изменениях, измененный объект сериализуется JSON и отправляется в ES асинхронно и большими партиями., То, что имеет огромное значение для производительности. Производительность поиска , с другой стороны, не зависит от длины _id AFAIK, даже если вы посмотрите на _id.Так что ваш БД UUID должен быть просто в порядке.Тем более, что _id s могут быть буквенно-цифровыми, они не ограничиваются только числами.

Наличие отношения 1: 1 через _id между результатом ES и вашей системой записи (я предполагаю, что это то, что ваша БДдля) выгодно также в целях прозрачности.В любом случае вы хотите сохранить идентификатор базы данных в виде некоторого поля, по крайней мере, идеально проиндексированного, чтобы помочь вам понять, откуда пришел этот документ .

Таким образом, вместо создания собственногоПоле ID, вы также можете сразу использовать встроенное поле _id вместе с данными, предоставленными БД.

Answer 2

Хорошо, поэтому между этими двумя ответами кажется, что он будет работать нормально, пока используемый идентификатор достаточно уникален, чтобы обеспечить хороший баланс в эластичности.