Как мне индексировать UUID в Postgres?

Я новичок в PostgreSQL и несколько новичок в базах данных в целом. Существует ли установленный способ индексации значений UUID в Postgres? Я разделен между использованием хеширования и использованием trie, если только у него уже нет чего-то встроенного, что он использует автоматически. Все, что я использую, будет обрабатывать огромные объемы данных.

Семейство операторов SP-GiST "text_ops" индексирует с помощью дерева. Поскольку UUID довольно длинные и очень разные, они звучат привлекательно, даже если бы я только когда-либо делал поиск по полному совпадению.

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

Или это слишком сильно зависит от системы и особенностей использования?

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

postgresql index uuid

— Судо
источник

Я считаю, что "федеративная база данных" - модное слово в вашей ситуации. И да, UUID являются решением для этого. Именно поэтому UUID были изобретены несколько десятилетий назад: для обмена данными между распределенными системами без централизованной координации.

— Василий Бурк

Месяцы спустя: «Федеративная база данных», созданная Бэзилом Бурком, - это то, к чему мы стремились. Мало того, что у нас есть несколько серверов, но у нас есть клиенты (которые можно рассматривать как дополнительные части федеративной БД), которые также создают идентификаторы в автономном режиме. Вот почему мы используем UUID.

— Судо

Ответы:

Используйте встроенный uuidтип данных PostgreSQL и создайте для него обычный индекс b-дерева.

Нет необходимости делать что-то особенное. Это приведет к оптимальному индексу, а также сохранит uuidполе в такой компактной форме, как это в настоящее время практично.

(Хеш-индексы в PostgreSQL до версии 10 не были безопасными при сбое и были действительно историческим пережитком, который в любом случае имел тенденцию работать не лучше, чем b-дерево. Избегайте их. В PostgreSQL 10 они были сделаны безопасными для сбоя и имели некоторые сделаны улучшения производительности, поэтому вы можете рассмотреть их.)

Если по какой-либо причине вы не можете использовать uuidтип, вы обычно создаете b-дерево в текстовом представлении или, предпочтительно, в byteaпредставлении uuid.

— Крейг Рингер
источник

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

— Volte

Начиная с 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

— derekm
источник

Да, я получаю предупреждение, когда пытаюсь использовать хэш-индекс. «Очень обескураженный» или что-то.

— Судо

Хеш-индексы хорошо работают в PostgreSQL при некоторых обстоятельствах, но недавно я обнаружил, что они заставляют мои запросы не возвращать результатов, когда я пытался оптимизировать с помощью хеш-индексов для встроенных UUID-типа данных первичных и внешних ключей. У хэш-индексов действительно есть свои преимущества, если они работают только со всеми типами данных, и разработчики PostgreSQL знают об этом, им просто лень самим это исправлять, и они держат свой код в таком положении, как будто они молятся за / за их возможное спаситель.

— Дерекм

Кто-то спас хэш-индексы, я полагаю, потому что они играют критическую роль в разделении данных, на чем Pg10 сосредоточился: wiki.postgresql.org/wiki/… Но они все еще не дают вам всего, что я видел теоретически полезно в классе базы данных колледжа;)

— sudo