У Льоні сьогодні
📢
Канал в Telegram @leonid_today
🦣
@leonid_today@shevtsov.me в Федиверсі
11.08.2026
_id в OpenSearch - не так ефективно, як можна подумати
В продовження теми того, що розуміння однієї бази даних не завжди переноситься на іншу.
В OpenSearch (чи ElasticSearch, бо одно й те саме) в кожного документа є ідентифікатор - _id. Наче зрозуміле явище, за ним ми швидко знаходимо та змінюємо документи. Так саме як в PostgreSQL, наприклад.
Але. Якщо вам раптом захочеться відсортувати за _id, то виявиться, що прямої можливості це зробити в OpenSearch немає. Словник того не підтримує. Та тому для виконання запиту з "sort": "_id" база завантажить всі ID в памʼять. Цей маневр називається field data.
З мільйонами документів в індексі ця fielddata займатиме гігабайт RAM, а то й більше — саме так я про неї й дізнався. Та дуже дивно було, що саме _id, з усіх полів, спричиняє такі витрати.
Що робити натомість? Можна дублювати _id всередині документу. Можна сортувати за якимсь іншим полем. Зокрема, якщо задачею сортування є стабільність видачі (бо навіщо ще сортувати за ID?) - то в пошуку є спеціальне поле _shard_doc як раз для такої потреби.
Власне, в останніх версіях OpenSearch навіть є налаштування indices.id_field_data.enabled: false - воно примусово заборонить створення fielddata з _id. Тож то й таке.