Найбільш ефективний тип стовпців UUID

15

Для зберігання 128-бітного UUID існує кілька варіантів зберігання:

байт [16]
два стовпчики bigint / long (64 біт)
стовпець CHAR (36) - 32 шістнадцяткових цифр + 4 тире.
стовпець бази даних UUID, якщо db підтримує його

З точки зору індексації, хто з них є найбільш ефективним? Якщо db не підтримує виділений тип uuid, який із 1, 2, 3 є найкращими кандидатами?

— Влад Михальча
джерело

1

Це трохи "це залежить" - багато специфіки реалізації.

— Крейг Рінгер

2

Я б ніколи не вибрав 3: ніколи не зберігайте щось у 36 байтах, коли це можна зробити в 16. Я використовую raw(16)в Oracle і uuidв PostgreSQL.

— Colin 't Hart

1

чим простіше, тим краще.

— akuzminsky

uuid>> bytea>> textз CHECKобмеженням> varchar(36)>> char(36). Дивіться: dba.stackexchange.com/a/89433/3684 та dba.stackexchange.com/a/115316/3684 .

— Ервін

15

Виділений uuidтип - найкраща ставка для PostgreSQL. Важко сказати, що з іншими БД - це не неможливо, щоб хтось застосував uuidтип, який зберігається менш ефективно, ніж простий тип байтів.

Знову в PostgreSQL byteaбуло б розумним способом зберігання UUID, якщо у вас не було такого uuidтипу. Для інших БД це залежить від того, як вони зберігають двійкові дані.

Де можливо, я настійно уникаю використання шістнадцяткових тире. Це менш ефективне порівняння, сортування та зберігання.

Тож справді "не (2) чи (3)". Колись. Використовуйте (4) там, де підтримується, (1) в іншому випадку.

— Крейг Рінгер
джерело

Варто зазначити, що тип UUID PostgreSQL не підтримується в масивах, або це було виправлено? postgresql.org/message-id/…

— Крістоф Руссі

@ChristopheRoussy Це з 2013 року. Це був незначний нагляд. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Крейг Рінгер

3

У черговому порядку: 4,1,2,3 Не використовуйте UUID в якості кластеризованого ключа, якщо ви використовуєте SQL-сервер, оскільки він не лише погано фрагментується, кластерний ключ використовується у всіх некластеризованих індексах, і ви додаєте ці байти до кожен індексний рядок Фрагментацію можна пом'якшити, використовуючи NEWSEQUENTIALID, але, як правило, віддають перевагу ідентичності bingint для Вашого кластеру клавіш над GUID, щоб запобігти здуття в інших індексах.

Різниця між вибором від 1 до 2 залежатиме від того, наскільки ефективніше база даних обробляє два стовпчики основних типів у фіксованому масиві одного стовпця. Це повинно бути досить простим для тестування за допомогою фіктивних даних. Подивіться на швидкість ваших запитів, а також на розмір індексів та даних. Малий + швидкий - найкраще!

— GilesDMiddleton
джерело

1

Варто припустити, що будь-який тип даних, що підтримується, краще оптимізується у продукті, ніж усе, що можна скласти як клієнт цього продукту. Після цього все, що має найменший байт, так що ви отримуєте максимум рядків на сторінці.

— Майкл Грін
джерело

Щоправда, але чи важливий лише розмір байта? Чи не впливає тип алгоритму індексації?

— Влад Міхалча

@Vlad Я використовую SQL Server. Усі типи даних AFAIK обробляються однаково при побудові B-дерева (або хеш-індексу для пам'яті 2104). Є вагомі причини, щоб це було максимально вузьким.

— Майкл Грін