Перейти до вмісту

Запровадила впорядковані за часом ідентифікатори UUID v7 (PostgreSQL 18) як ключі сутностей, щоб зменшити фрагментацію індексів B‑tree та пришвидшити запити.

впорядковані за часом ключі, що тримають індекси компактними

Ситуація. Кожній сутності потрібен унікальний id, і за звичкою беруть випадковий UUID. Біда в тому, що випадкові id розлітаються по всьому B‑tree‑індексу. Вставки розпорошуються, індекс фрагментується, і зі зростанням таблиць за це платять і записи, і сканування діапазонів. На платформі, яка має й далі зростати, це повільний витік, якого краще не закладати від самого початку.

Завдання. Зберегти глобальну унікальність UUID, але позбутися фрагментації, яку спричиняє випадковість.

Дія. Стандартом став UUID v7, упорядкований за часом: старші біти — це мітка часу, тож нові рядки лягають в індекс по порядку, а не розлітаються по ньому, як дріб. У PostgreSQL 18 це є нативно — функція uuidv7(); її обгорнуто в невелику функцію uuid_generate_v7(), щоб той самий виклик коректно працював і на Azure Flexible Server, а потім зроблено значенням за замовчуванням для первинних ключів сутностей у всій схемі. Нічого екзотичного: таке рішення дешево ухвалити на початку й болісно впроваджувати заднім числом.

Результат. Id лишилися глобально унікальними, індекс перестав фрагментуватися, як це буває з випадковими UUID, а вставки в порядку часу й запити за діапазоном стали швидшими — рівномірно, на всіх таблицях, і більше ніхто не мусить про це думати. На додачу кожна сутність отримала ключ, за яким можна сортувати за часом, — задарма.

Одна частина довшого переліку — і він увесь на цьому сайті.

Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.

Переглянути весь перелік