Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
25.12.2025
Надгробки в базах даних
ОК, ще одна повʼязана ідея, з якою мені чомусь постійно доводиться стикатися останнім часом.
Річ у тім, що видалення з бази даних практично ніколи не вивільняє місце запису. Натомість запис помічається як видалений — утворюється так званий надгробок (tombstone). І тільки пізніше, окремою операцією очищення бази це місце буде дійсно вивільнено. Інколи таке очищення відбувається лише вручну… або за певної архітектури взагалі не є можливою.
Те ж саме стосується й редагування. Бо найчастіше редагування відбувається через “видалення” попередньої версії та дописування нової. Тим самим у нас теж зʼявляється надгробок. На то є кілька причин — в транзакційній базі головна причина те, що нам все одно треба зберігати й стару версію теж. Так само і в розподіленій базі.
От якщо взяти PostgreSQL, то надгробки видаляються операцією VACUUM. Яка може виконуватися й автоматично. Може, а якщо це не налаштовано, то цілком реально опинитися з табличкою, де мертвих записів на порядок більше, ніж живих.
В ElasticSearch все складніше; найкращій та рекомендований варіант — це просто видаляти весь застарілий індекс. Бо інакше його доведеться принаймні заморожувати на запис. Тому навіть використовується такий підхід, що оновлені документи пишуться в нові індекси, а не в один.
Інколи надгробки є більш… матеріальними, от в CouchDB їх роблять заради синхронізації видалень між вузлами. Та й взагалі будь-де синхронізація вимагає надгробків.
А інколи ми робимо їх самі - додаємо поле deleted_at.