Як слід індексувати UUID в Postgres?

Я новачок у PostgreSQL і дещо новий в базах даних взагалі. Чи існує усталений спосіб, як слід індексувати значення UUID у Postgres? Я розділений між використанням хешування та використанням трие, якщо тільки в ньому вже є щось вбудоване, яке воно використовує автоматично. Що б я не використовував, буде обробляти величезну кількість даних.

Родина операторів SP-GiST "text_ops" індексує за допомогою трие. Оскільки UUID досить довгі і дуже відрізняються, ці звуки привабливі, хоча я б коли-небудь робив повні результати пошуку.

Також є хеш-варіант. Хешинг - це O (1), і мені не потрібно робити ніяких порівнянь, окрім рівності, звичайно, але оскільки UUID є досить довгим, я боюся, що генерування хешей з них не витратить багато часу.

Або це щось, що занадто багато залежить від системи та специфіки використання?

Я вважаю за краще скористатися bigserial у більшості випадків, але мені сказали використовувати uuid для цього. Нам потрібен uuid, оскільки у нас може бути декілька серверів, що використовують різні бази даних, тому немає гарантії, що у нас будуть унікальні bigints. Ми можемо використовувати різну послідовність (та насіннєву) для кожного сервера, але вона все ще не така гнучка, як UUID. Наприклад, ми не змогли би перенести записи бази даних з одного сервера на інший без перетворення ідентифікаторів та їх посилань скрізь.

postgresql index uuid

— судо
джерело

Я вважаю, що "об'єднана база даних" є модним словом для вашої ситуації. І так, UUID - це рішення для цього. Саме з цієї причини UUID були винайдені десятиліттями тому: для обміну даними між розподіленими системами без централізованої координації.

— Василь Бурк

Місяці пізніше: Дійсно, "ми створили" федеральну базу даних "Василя Бурка - це те, для чого ми йдемо. Ми не тільки маємо декілька серверів, але і у нас є клієнти (які можна розглядати як більшу частину федеральної БД), які створюють ідентифікатори і в режимі офлайн. Ось чому ми використовуємо UUID.

— судо

Відповіді:

Використовуйте вбудований uuidтип даних PostgreSQL та створіть на ньому звичайний b-tree індекс.

Не потрібно нічого особливого робити. Це призведе до отримання оптимального показника, а також збереже uuidполе в такому компактному вигляді, як це є в даний час.

(Хеш-індекси в PostgreSQL до версії 10 не були безпечними для збоїв і справді були історичною реліквією, яка, як правило, не краще, ніж b-дерево. Уникайте їх. На PostgreSQL 10 вони були безпечними для аварій і мали деякі Поліпшення продуктивності зроблено, щоб ви могли їх врахувати.)

Якщо з якоїсь причини ви не могли використовувати uuidтип, ви, як правило, створили б-дерево на текстовому поданні або, переважно, byteaподання uuid.

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

Хоча твердження щодо hashіндексів порівняно b-treeє загальноприйнятою думкою, я думаю, було б корисно навести джерела для такого твердження.

— Вольте

Станом на PostgreSQL 10, hashіндекси тепер безпечні для збоїв. Однак, hashіндекси можна використовувати лише з =, тому якщо вам потрібні інші оператори, b-treeвсе-таки краще.

— rintaun

Через пару років, за моїм досвідом, це hashбуло не набагато швидше, ніж b-treeнавіть у Postgres 10. Але оскільки хеш-індекси займають набагато менше місця на диску, ніж b-tree, це може бути швидше в налаштуваннях, коли великі індекси стають проблема, яка, на мою думку, не стосується мене. Ну я буду стежити за тим, що я можу їх безпечно використовувати в v10.

— судо

Є кілька корисних записів на покращення рівня хеш-індексу в v10 та v11: rhaas.blogspot.com/2017/09/… - amitkapila16.blogspot.com/2017/03/…

— Гленн Мортон

Індекси хешу відсутні в дії в PostgreSQL. PostgreSQL знає, що йому потрібні хеш-індекси, і що це код для хеш-індексів є старим і запліснявленим, але вони не видаляють його, тому що вони чекають, коли хтось прийде і перегляне хеш-індексацію. Дивіться цю тему:

http://www.postgresql.org/message-id/4407.1115698257@sss.pgh.pa.us

— дерекм
джерело

Так, я отримую попередження, коли намагаюся використовувати хеш-індекс. "Сильно обескуражений" чи щось таке.

— судо

Індекси хешу добре працюють у PostgreSQL за певних обставин, але я нещодавно виявив, що вони викликали, що мої запити не дають результатів, коли я спробував оптимізувати хеш-індекси на вбудованих первинних та зовнішніх ключах даних UUID. Істинські індекси справді є корисними, якщо тільки вони працювали для всіх типів даних, і PostgreSQL розробники знають це, вони просто ліниві, щоб виправити це самі, і вони зберігають свій код так, як ніби вони моляться / за їхнє можливе рятівник.

— дерекем

Хтось врятував хеш-індекси, я здогадуюсь, оскільки вони відіграють вирішальну роль у розділі даних, на який Pg10 зосередився: wiki.postgresql.org/wiki/… Але вони все ще не дають тобі всього, що я бачив теоретично корисно в класі баз даних коледжу;)

— судо