Come devo indicizzare un UUID in Postgres?

Sono nuovo di PostgreSQL e in qualche modo nuovo per i database in generale. Esiste un modo consolidato per indicizzare i valori UUID in Postgres? Sono diviso tra l'uso dell'hash e l'uso di un trie, a meno che non ci sia già qualcosa di incorporato che utilizza automaticamente. Qualunque cosa io utilizzi, gestirà enormi quantità di dati.

La famiglia di operatori SP-GiST "text_ops" si indicizza usando un trie. Poiché gli UUID sono piuttosto lunghi e molto diversi, sembrano interessanti anche se farei sempre e solo ricerche complete.

C'è anche un'opzione hash. Hashing è O (1), e ovviamente non avrò bisogno di fare paragoni oltre all'uguaglianza, ma poiché gli UUID sono piuttosto lunghi, temo che la generazione di hash da loro perderebbe molto tempo.

O è qualcosa che dipende troppo dal sistema e dalle specifiche?

Preferirei usare bigserial nella maggior parte dei casi, ma mi è stato detto di usare uuid per questo. Abbiamo bisogno di uuid perché potremmo avere più server che utilizzano database diversi, quindi non c'è garanzia che avremo origini univoche. Potremmo usare una sequenza (e seed) diversa per ciascun server, ma non è ancora flessibile come gli UUID. Ad esempio, non saremmo in grado di migrare le voci del database da un server all'altro senza convertire gli ID e i loro riferimenti ovunque.

postgresql index uuid

— sudo
fonte

Credo che "database federato" sia la parola d'ordine per la tua situazione. E, sì, gli UUID sono la soluzione per questo. Questa è stata la vera ragione per cui gli UUID sono stati inventati decenni fa: per condividere dati tra sistemi distribuiti senza coordinamento centralizzato.

— Basil Bourque,

Mesi dopo: In effetti, il "database federato" che Basil Bourque ha creato è ciò che stiamo cercando. Non solo disponiamo di più server, ma abbiamo client (che possono essere considerati più parti del DB federato) che creano ID anche offline. Ecco perché usiamo gli UUID.

— sudo,

Risposte:

Utilizzare il uuidtipo di dati incorporato di PostgreSQL e creare un normale indice b-tree su di esso.

Non è necessario fare nulla di speciale. Ciò si tradurrà in un indice ottimale e memorizzerà il uuidcampo in una forma così compatta come è attualmente pratica.

(Gli indici di hash in PostgreSQL prima della versione 10 non erano sicuri per gli incidenti ed erano in realtà una reliquia storica che tendeva comunque a non funzionare meglio di un albero b. Evitali. Su PostgreSQL 10 sono stati resi sicuri dagli incidenti miglioramenti delle prestazioni apportati, quindi potresti volerli considerare.)

Se per qualche motivo non fosse possibile utilizzare il uuidtipo, in genere si creerebbe un b-tree sulla rappresentazione del testo o, preferibilmente, una bytearappresentazione dell'UUID.

— Craig Ringer
fonte

Mentre l'affermazione relativa agli hashindici contro b-treeè una credenza comunemente ritenuta, penso che sarebbe utile citare le fonti per tale affermazione.

— Volte,

A partire da PostgreSQL 10, gli hashindici sono ora a prova di crash. Detto questo, gli hashindici possono essere utilizzati solo con =, quindi se hai bisogno di altri operatori, b-treeè comunque preferibile.

— rintaun

Un paio d'anni dopo, nella mia esperienza, hashnon è stato molto più veloce di b-tree, anche in Postgres 10. Ma poiché gli indici hash occupano molto meno spazio su disco rispetto a b-tree, potrebbe essere più veloce in una configurazione in cui i grandi indici diventano un problema, che ritengo non sia stato il caso per me. Bene, terrò d'occhio ora che posso effettivamente usarli in modo sicuro in V10.

— sudo,

Ci sono alcuni commenti positivi

— Glenn Morton

Gli indici hash mancano in azione in PostgreSQL. PostgreSQL sa che ha bisogno di indici di hash e che il suo codice per gli indici di hash è vecchio e ammuffito, ma non lo rimuovono perché stanno aspettando che qualcuno arrivi e revisionino l'indicizzazione di hash. Vedi questa discussione:

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

— derekm
fonte

Sì, ricevo un avviso quando provo a utilizzare un indice hash. "Altamente scoraggiato" o qualcosa del genere.

— sudo,

Gli indici hash funzionano bene in PostgreSQL in alcune circostanze, ma di recente ho scoperto che le mie query non restituivano risultati quando ho provato a ottimizzare con gli indici hash sul tipo di dati UUID incorporato chiavi primarie ed esterne. Ci sono davvero vantaggi per gli indici di hash, se solo funzionassero per tutti i tipi di dati, e gli sviluppatori PostgreSQL lo sanno, sono troppo pigri per risolverli da soli e mantengono il loro codice situato come se pregassero / per il loro eventuale salvatore.

— Derekm,

Qualcuno ha salvato gli indici di hash, immagino perché svolgono un ruolo critico nel partizionamento dei dati, su cui Pg10 si è concentrato: wiki.postgresql.org/wiki/… Ma ancora non ti danno tutto ciò che ho visto teoricamente utile nella classe del database del college;)

— sudo