Интеграция UUID в Manticore Search: упрощение управления данными
Manticore Search версии 28.5.0 и новее представляет значительное обновление, позволяющее использовать UUID (универсальные уникальные идентификаторы) в качестве основного идентификатора документа. Это нововведение устраняет необходимость в поддержании сопоставления между UUID из основной базы данных и числовыми ID в Manticore, значительно упрощая управление данными для разработчиков.
Предыстория проблемы с идентификаторами
До версии Manticore Search 28.5.0 идентификатор документа представлял собой беззнаковое 64-битное число. Если в основной базе данных продукт уже имел UUID, например, 550e8400-e29b-41d4-a716-446655440000, который использовался в событиях, логах и ответах API, то при загрузке этого же товара в Manticore приходилось присваивать ему дополнительный числовой ID. Хотя UUID можно было сохранить как отдельный строковый атрибут, он не функционировал как основной идентификатор для таких операций, как UPDATE, REPLACE и DELETE, требующих числового id. Это создавало дополнительную нагрузку на хранение и синхронизацию данных.
Новые возможности с UUID в Manticore
Теперь RT-таблицы Manticore поддерживают UUID в качестве первичного ключа документа. Это означает, что разработчики могут использовать единый идентификатор для товаров или других сущностей как в основной базе данных, так и в Manticore Search, исключая необходимость в промежуточных таблицах соответствия.
Практическое применение и дальнейшие шаги
Для тех, кто готов внедрить эту функцию, процесс включает создание таблицы с поддержкой UUID, выполнение основных операций через SQL и JSON API, а также загрузку документов через интерфейс /bulk. Все примеры и инструкции рассчитаны на Manticore Search версии 28.5.0 или новее. Важно отметить, что сгенерированные Manticore UUID должны использоваться в последующих запросах, заменяя собой плейсхолдеры.
Очень интересно узнать, как теперь UUID будет влиять на производительность индексации и поиска, особенно при работе с очень большими объемами данных. Есть ли какие-то бенчмарки по сравнению с числовыми ID в плане скорости запросов? И как это нововведение отразится на управлении шардингом, станет ли оно проще или появятся новые нюансы?