¿Cómo debo indexar un UUID en Postgres?

Soy nuevo en PostgreSQL y algo nuevo en las bases de datos en general. ¿Existe una forma establecida de cómo debemos indexar los valores de UUID en Postgres? Estoy dividido entre usar hashing y usar un trie, a menos que ya haya algo incorporado que use automáticamente. Lo que sea que use va a manejar grandes cantidades de datos.

La familia de operadores SP-GiST "text_ops" indexa utilizando un trie. Debido a que los UUID son bastante largos y muy diferentes, suenan atractivos a pesar de que solo haría búsquedas de concordancia completa.

También hay una opción de hash. El hash es O (1), y no tendré que hacer ninguna comparación además de la igualdad, por supuesto, pero debido a que los UUID son bastante largos, me temo que generar hashes de ellos perdería mucho tiempo.

¿O es algo que depende demasiado del sistema y del uso específico?

Prefiero usar bigserial en la mayoría de los casos, pero me han dicho que use uuid para esto. Necesitamos uuid porque podríamos tener múltiples servidores usando diferentes bases de datos, por lo que no hay garantía de que tengamos bigints únicos. Podríamos usar una secuencia diferente (y semilla) para cada servidor, pero aún no es tan flexible como los UUID. Por ejemplo, no podríamos migrar las entradas de la base de datos de un servidor a otro sin convertir las ID y sus referencias en todas partes.

postgresql index uuid

— sudo
fuente

Creo que "base de datos federada" es la palabra de moda para su situación. Y sí, los UUID son la solución para eso. Esa fue la razón por la cual los UUID se inventaron hace décadas: para compartir datos entre sistemas distribuidos sin coordinación centralizada.

— Basil Bourque

Meses después: De hecho, la "base de datos federada" que Basil Bourque mencionó es lo que buscamos. No solo tenemos varios servidores, sino que también tenemos clientes (que pueden considerarse como más partes de la base de datos federada) que crean ID sin conexión. Es por eso que usamos UUID.

— sudo

Respuestas:

Utilice el uuidtipo de datos incorporado de PostgreSQL y cree un índice b-tree regular en él.

No hay necesidad de hacer nada especial. Esto dará como resultado un índice óptimo y también almacenará el uuidcampo en una forma tan compacta como sea práctica en la actualidad.

(Los índices de hash en PostgreSQL anteriores a la versión 10 no eran a prueba de fallos y en realidad eran una reliquia histórica que tendía a funcionar mejor que un árbol b de todos modos. Evítelos. En PostgreSQL 10 se hicieron a prueba de choques y tuvieron algunos mejoras de rendimiento realizadas, por lo que es posible que desee considerarlas).

Si por alguna razón no pudiera usar el uuidtipo, generalmente crearía un árbol b en la representación de texto o, preferiblemente, una bytearepresentación del uuid.

— Craig Ringer
fuente

Si bien la declaración con respecto a los hashíndices versus b-treees una creencia común, creo que sería útil citar fuentes para tal afirmación.

— Volte

A partir de PostgreSQL 10, los hashíndices ahora son seguros. Dicho esto, los hashíndices solo se pueden usar =, por lo que si necesita otros operadores, b-treeaún es preferible.

— rintaun

Un par de años más tarde, en mi experiencia, hashno ha sido mucho más rápido que b-tree, incluso en Postgres 10. Pero dado que los índices hash ocupan mucho menos espacio en disco que b-tree, podría ser más rápido en una configuración donde los índices grandes se convierten en un problema, que siento que no ha sido el caso para mí. Bueno, estaré atento ahora que realmente puedo usarlos de forma segura en v10.

— sudo

Hay algunas buenas críticas sobre las mejoras de rendimiento del

— Glenn Morton

Faltan índices de hash en acción en PostgreSQL. PostgreSQL sabe que necesita índices hash, y que el código para los índices hash es antiguo y mohoso, pero no lo eliminan porque están esperando que alguien venga y revisen la indexación hash. Ver este hilo:

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

— derekm
fuente

Sí, recibo una advertencia cuando intento usar un índice hash. "Muy desanimado" o algo así.

— sudo

Los índices de hash funcionan bien en PostgreSQL en algunas circunstancias, pero recientemente descubrí que causaban que mis consultas no arrojasen resultados cuando intenté optimizar con índices de hash en claves primarias y externas de tipo de datos UUID incorporadas. Realmente hay beneficios para los índices hash, si solo funcionaran para todos los tipos de datos, y los desarrolladores de PostgreSQL lo saben, son demasiado vagos para arreglarlo ellos mismos, y mantienen su código situado como si rezaran por / para su eventual salvador.

— derekm

Alguien ha rescatado los índices hash, supongo que porque juegan un papel crítico en la partición de datos, en lo que Pg10 se ha centrado: wiki.postgresql.org/wiki/… Pero todavía no te dan todo lo que he visto teóricamente útil en la clase de base de datos de la universidad;)

— sudo