Jak indeksować UUID w Postgres?

Jestem nowy w PostgreSQL i trochę nowy w bazach danych w ogóle. Czy istnieje ustalony sposób indeksowania wartości UUID w Postgres? Jestem podzielony między używaniem mieszania i używania trie, chyba że jest już coś wbudowanego, z którego korzysta automatycznie. Cokolwiek użyję, będzie obsługiwać ogromne ilości danych.

Rodzina operatorów SP-GiST „text_ops” indeksuje za pomocą trie. Ponieważ identyfikatory UUID są dość długie i bardzo odmienne, brzmią atrakcyjnie, nawet jeśli przeprowadzałbym tylko pełne wyszukiwania.

Istnieje również opcja skrótu. Hashing to O (1) i nie będę musiał robić żadnych porównań poza równością, oczywiście, ale ponieważ UUID są dość długie, obawiam się, że generowanie z nich skrótów zmarnowałoby dużo czasu.

A może jest to coś, co zbytnio zależy od systemu i specyfiki?

Wolę używać bigserial w większości przypadków, ale powiedziano mi używać UUID do tego. Potrzebujemy UUID, ponieważ możemy mieć wiele serwerów korzystających z różnych baz danych, więc nie ma gwarancji, że będziemy mieć unikalne biginty. Możemy zastosować inną sekwencję (i seed) dla każdego serwera, ale nadal nie jest tak elastyczny jak UUID. Na przykład nie bylibyśmy w stanie migrować wpisów bazy danych z jednego serwera na inny bez konwersji wszędzie identyfikatorów i ich odniesień.

postgresql index uuid

— sudo
źródło

Uważam, że „stowarzyszona baza danych” to modne hasło dla Twojej sytuacji. I tak, UUID są rozwiązaniem tego problemu. To był właśnie powód, dla którego dziesiątki lat temu wynaleziono UUID: do udostępniania danych między systemami rozproszonymi bez scentralizowanej koordynacji.

— Basil Bourque

Kilka miesięcy później: „Federalna baza danych”, o której wspomniał Basil Bourque, jest tym, o co nam chodzi. Mamy nie tylko wiele serwerów, ale także klientów (które można uznać za więcej części stowarzyszonej bazy danych), którzy tworzą identyfikatory w trybie offline. Dlatego używamy UUID.

— sudo,

Odpowiedzi:

Użyj wbudowanego uuidtypu danych PostgreSQL i utwórz na nim zwykły indeks b-drzewa.

Nie trzeba robić nic specjalnego. Spowoduje to optymalny indeks, a także zapisze uuidpole w tak zwartej formie, jak jest to obecnie praktyczne.

(Indeksy Hash w PostgreSQL przed wersją 10 nie były odporne na awarie i były naprawdę historyczną relikwią, która i tak zwykle działała nie lepiej niż b-drzewo. Unikaj ich. Na PostgreSQL 10 zostały one zabezpieczone przed awarią i miały trochę wprowadzone ulepszenia wydajności, więc możesz je rozważyć).

Jeśli z jakiegoś powodu nie możesz użyć tego uuidtypu, zwykle tworzysz b-drzewo na reprezentacji tekstowej lub, najlepiej, byteareprezentacji UUID.

— Craig Ringer
źródło

Podczas gdy stwierdzenie dotyczące hashindeksów w porównaniu b-treez powszechnym przekonaniem, uważam, że warto byłoby cytować źródła takiego twierdzenia.

— Volte

Począwszy od PostgreSQL 10, hashindeksy są teraz odporne na awarie. To powiedziawszy, hashindeksy mogą być używane tylko z =, więc jeśli potrzebujesz innych operatorów, b-treenadal jest preferowane.

— rintaun

Z moich doświadczeń hashwynika , że kilka lat później nie było dużo szybsze niż b-treenawet w Postgresie 10. Ale ponieważ indeksy skrótów zajmują o wiele mniej miejsca na dysku niż b-drzewo, może być szybsze w konfiguracji, w której duże indeksy stają się problem, który moim zdaniem nie dotyczył mnie. Cóż, teraz uważam, że mogę bezpiecznie używać ich w wersji 10.

— sudo

Istnieje kilka dobrych poprawek dotyczących udoskonaleń indeksu skrótu w wersji 10 i 11: rhaas.blogspot.com/2017/09/… - amitkapila16.blogspot.com/2017/03/…

— Glenn Morton

W PostgreSQL brakuje indeksów skrótu. PostgreSQL wie, że potrzebuje indeksów skrótów i że jego kod dla indeksów skrótów jest stary i spleśniały, ale nie usuwają go, ponieważ czekają, aż ktoś przyjdzie i przejdzie indeksowanie skrótów. Zobacz ten wątek:

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

— derekm
źródło

Tak, dostaję ostrzeżenie, gdy próbuję użyć indeksu skrótu. „Bardzo zniechęcony” czy coś takiego.

— sudo,

Indeksy skrótów działają dobrze w PostgreSQL w niektórych okolicznościach, ale ostatnio odkryłem, że spowodowały, że moje zapytania nie zwróciły żadnych wyników, gdy próbowałem zoptymalizować za pomocą indeksów skrótu dla wbudowanych kluczy danych typu UUID podstawowego i obcego. Indeksy mieszające mają naprawdę zalety, jeśli tylko działały dla wszystkich typów danych, a deweloperzy PostgreSQL wiedzą o tym, są zbyt leniwi, aby sami to naprawić, i utrzymują swój kod tak, jakby modlili się do / o swoje ewentualne Zbawiciel.

— derekm

Ktoś uratował indeksy skrótów, zgaduję, ponieważ odgrywają kluczową rolę w partycjonowaniu danych, na których Pg10 koncentruje się: wiki.postgresql.org/wiki/... Ale wciąż nie dają ci wszystkiego, co widziałem teoretycznie przydatne w klasie baz danych uczelni;)

— sudo