El uso de UUID en Mongo es ciertamente posible y está razonablemente bien respaldado. Por ejemplo, los documentos de Mongo enumeran los UUID como una de las opciones comunes para _id campo.
Consideraciones
- Rendimiento – Como mencionan otras respuestas, los puntos de referencia muestran que los UUID causan una caída en el rendimiento de las inserciones. En el peor de los casos medidos (pasando de 10 millones a 20 millones de documentos en una colección), son alrededor de 2 a 3 veces más lentos:la diferencia entre insertar 2000 (UUID) y 7500 (ObjectID) documentos por segundo. Esta es una gran diferencia, pero su importancia depende completamente de su caso de uso. ¿Va a insertar por lotes millones de documentos a la vez? Para la mayoría de las aplicaciones que he creado, el caso común es insertar documentos individuales. Los mismos puntos de referencia muestran que, para ese patrón de uso, la diferencia es mucha más pequeño (6250 -frente a 7500; ~20%). No es insignificante... pero tampoco impactante.
- Portabilidad – Muchas otras plataformas de base de datos tienen una buena compatibilidad con UUID, por lo que se mejoraría la portabilidad. Alternativamente, dado que los UUID son más grandes (más bits), es posible volver a empaquetar un ObjectID en la "forma" de un UUID. Este enfoque no es tan bueno como la portabilidad directa, pero le brinda una forma de "asignar" entre ObjectID y UUID existentes.
- Descentralización – Uno de los grandes puntos de venta de los UUID es que son universalmente únicos. Esto hace que sea práctico generarlos en cualquier lugar, de forma descentralizada (en contraste, por ejemplo, con un valor de incremento automático, que requiere una fuente de verdad centralizada para determinar el valor "siguiente"). Por supuesto, los ID de objetos de Mongo también ofrecen este beneficio. La diferencia es que los UUID se basan en un estándar de más de 15 años y son compatibles con (¿casi?) todas las plataformas, idiomas, etc. Esto los hace muy útiles si alguna vez necesita crear entidades (o específicamente, conjuntos de relacionados entidades) en sistemas desarticulados, sin interactuar con la base de datos. Puede crear un conjunto de datos con ID y claves externas en su lugar, luego escribir el gráfico completo en la base de datos en algún momento en el futuro sin conflicto. Aunque esto también es posible con Mongo ObjectID, encontrar código para generarlos/trabajar con el formato a menudo será más difícil.
Correcciones
Contrariamente a algunas de las otras respuestas:
- Los UUID tienen compatibilidad nativa con Mongo – Puedes usar el
UUID()funcione en Mongo Shell exactamente de la misma manera que usaríaObjectID(); para convertir una cadena UUID en un objeto BSON equivalente. - Los UUID no son especialmente grandes – Cuando se codifica utilizando el subtipo binario
0x04son 128 bits, en comparación con los 96 bits de los ObjectID. (Si se codifican como cadenas, lo harán ser bastante derrochador, ocupando alrededor de 288 bits). - Los UUID pueden incluir una marca de tiempo – Específicamente, UUIDv1 codifica una marca de tiempo con 60 bits de precisión, en comparación con los 32 bits de los ObjectID. Esto es más de 6 órdenes de magnitud más de precisión, por lo que nanosegundos en lugar de segundos. En realidad, puede ser una forma decente de almacenar marcas de tiempo creadas con más precisión que la que admiten los objetos de fecha Mongo/JS, sin embargo...
- La compilación en
UUID()La función solo genera UUID v4 (aleatorios), por lo que, para aprovechar esto, debe apoyarse en su aplicación o controlador Mongo para la creación de ID. - A diferencia de los ID de objetos, debido a la forma en que se dividen los UUID, la marca de tiempo no ofrece un orden natural. Esto puede ser bueno o malo dependiendo de su caso de uso. (Los nuevos estándares pueden cambiar esto; consulte la actualización de 2021 a continuación).
- Incluir marcas de tiempo en sus identificaciones a veces es una mala idea. Terminas filtrando el tiempo creado de los documentos en cualquier lugar donde se exponga una identificación. (Por supuesto, los ObjectID también codifican una marca de tiempo, por lo que esto también es cierto en parte para ellos).
- Si hace esto con UUID v1 (que cumplen con las especificaciones), también está codificando parte de la dirección MAC del servidor, lo que puede potencialmente utilizarse para identificar la máquina. Probablemente no sea un problema para la mayoría de los sistemas, pero tampoco es ideal. (Los nuevos estándares pueden cambiar esto; consulte la actualización de 2021 a continuación).
- La compilación en
Conclusión
Si piensa en su Mongo DB de forma aislada, los ObjectID son la opción obvia. Funcionan bien desde el primer momento y son un valor predeterminado perfectamente capaz. El uso de UUID en su lugar sí agregue algo de fricción, tanto al trabajar con los valores (necesidad de convertir a tipos binarios, etc.) como en términos de rendimiento. Si este pequeño inconveniente vale la pena tener un formato de identificación estandarizado realmente depende de la importancia que le dé a la portabilidad y sus opciones de arquitectura.
¿Va a sincronizar datos entre diferentes plataformas de bases de datos? ¿Migrará sus datos a una plataforma diferente en el futuro? ¿Necesita generar identificaciones fuera la base de datos, en otros sistemas o en el navegador? Si no ahora en algún momento en el futuro? Los UUID pueden valer la pena.
Actualización de agosto de 2021
El IEFT publicó recientemente un borrador de actualización de la especificación UUID que introduciría algunas versiones nuevas del formato.
Específicamente, UUIDv6 y UUIDv7 se basan en UUIDv1, pero cambian los fragmentos de marca de tiempo para que los bits se organicen de más significativos a menos significativos. Esto le da a los valores resultantes un orden natural que (más o menos) refleja el orden en que fueron creados. Las nuevas versiones también excluyen los datos derivados de la dirección MAC de los servidores, lo que aborda una crítica de larga data de los UUID v1.
Llevará tiempo que estos cambios lleguen a las implementaciones, pero (en mi humilde opinión) modernizan y mejoran significativamente el formato.
