Estoy creando una BD en PostgreSQL y tengo que decidir usar el pseudo tipo SERIAL or UUID version 4 como clave primaria para una tabla que va a ser muy grande y por eso quiero particionarla lógicamente por año usando herencia, pero leí que hay controversias en usar UUID como PK. Que recomienda prof?
Si vas a particionar por fecha, no tiene nada que ver el tipo de la clave primaria. Particiona por el campo que tiene la fecha y ya está. La decisión de usar BIGSERIAL o UUID es ortogonal.
En cuanto a usar SERIAL o UUID, la diferencia en espacio puede resultar importante a gran escala: el UUID que se almacena ocupa 16 bytes, y un BIGSERIAL ocupa 8. Aunque el espacio en disco sea barato, cuando haces consultas que involucran esos campos, hay que leer y comparar los valores. Eso cuesta más tiempo de CPU y RAM: si los índices se hacen tan grandes que no caben en memoria, perdiste.
El UUID tiene una «presentación» visual tal que sirve como «código para entregar» y no revela ningún orden implícito. No es lo mismo poner Código de Cliente 42 que Código de Cliente 11c0f127-0f1c-4eab-aa82-2cc78f67ed72. El segundo es completamente opaco, y así deberían ser las claves primarias sintetizadas.
Así mismo, el UUID tiene la garantía de unicidad en la creación, mientras que con un BIGSERIAL necesitas una secuencia. Consultar la secuencia para tomar el siguiente número compite con otros procesos; generar un UUID no. Si el sistema es masivamente concurrente, podría ser mejor usar UUIDs en lugar de BIGSERIAL. No es un argumento suficientemente fuerte porque son muy pocos los sistemas masivamente concurrentes que tengan problemas como ese.
Los BIGSERIAL son simples números, con sus ventajas y desventajas. Para el humano es más fácil hacer «debugging» cuando las claves son números. Al mismo tiempo es fácil asociar orden implícito usando esa secuencia, que en realidad no tiene nada que ver con la naturaleza de los datos. Más de un desubicado piensa que el serial de la tabla Factura es el número de factura, pero no es, y hay otro campo que lo tiene y ¿por qué no lo usaste de clave primaria natural?
La clave primaria natural tiene que provenir de los datos reales (número de factura, número de parte, placa del carro, coordenadas del objeto, etc.). Si la fila no tiene una clave primaria natural, sintetizarla con UUID puede ser más fácil por su opacidad, que forzar usar números.
No tengo una preferencia particular. Te diría que uses UUID cuando lo necesites (ausencia de clave primaria natural, que deba mostrarse al usuario final), y (BIG)SERIAL el resto del tiempo.
Es probable que el tiempo de CPU adicional necesario para calcular el UUID sea más o menos equivalente al tiempo esperando por I/O para obtener el siguiente número de la secuencia, así que el desempeño debe ser similar. El espacio si te va a costar, así que no lo desperdicies si no lo necesitas.
En cuanto a usar SERIAL o UUID, la diferencia en espacio puede resultar importante a gran escala: el UUID que se almacena ocupa 16 bytes, y un BIGSERIAL ocupa 8. Aunque el espacio en disco sea barato, cuando haces consultas que involucran esos campos, hay que leer y comparar los valores. Eso cuesta más tiempo de CPU y RAM: si los índices se hacen tan grandes que no caben en memoria, perdiste.
El UUID tiene una «presentación» visual tal que sirve como «código para entregar» y no revela ningún orden implícito. No es lo mismo poner Código de Cliente 42 que Código de Cliente 11c0f127-0f1c-4eab-aa82-2cc78f67ed72. El segundo es completamente opaco, y así deberían ser las claves primarias sintetizadas.
Así mismo, el UUID tiene la garantía de unicidad en la creación, mientras que con un BIGSERIAL necesitas una secuencia. Consultar la secuencia para tomar el siguiente número compite con otros procesos; generar un UUID no. Si el sistema es masivamente concurrente, podría ser mejor usar UUIDs en lugar de BIGSERIAL. No es un argumento suficientemente fuerte porque son muy pocos los sistemas masivamente concurrentes que tengan problemas como ese.
Los BIGSERIAL son simples números, con sus ventajas y desventajas. Para el humano es más fácil hacer «debugging» cuando las claves son números. Al mismo tiempo es fácil asociar orden implícito usando esa secuencia, que en realidad no tiene nada que ver con la naturaleza de los datos. Más de un desubicado piensa que el serial de la tabla Factura es el número de factura, pero no es, y hay otro campo que lo tiene y ¿por qué no lo usaste de clave primaria natural?
La clave primaria natural tiene que provenir de los datos reales (número de factura, número de parte, placa del carro, coordenadas del objeto, etc.). Si la fila no tiene una clave primaria natural, sintetizarla con UUID puede ser más fácil por su opacidad, que forzar usar números.
No tengo una preferencia particular. Te diría que uses UUID cuando lo necesites (ausencia de clave primaria natural, que deba mostrarse al usuario final), y (BIG)SERIAL el resto del tiempo.
Es probable que el tiempo de CPU adicional necesario para calcular el UUID sea más o menos equivalente al tiempo esperando por I/O para obtener el siguiente número de la secuencia, así que el desempeño debe ser similar. El espacio si te va a costar, así que no lo desperdicies si no lo necesitas.
Liked by:
Carlos Torres
