¿Hay alguna ventaja en usar un _id personalizado para documentos en MongoDB?

Ventajas de generar tu propio _id s:

Puede hacerlos más amigables para los humanos, asignando números incrementales:1 , 2 , 3 , ...
O puede hacerlos más amigables para los humanos, usando cadenas aleatorias:t3oSKd9q

(Eso no ocupa demasiado espacio en la pantalla, se puede seleccionar de una lista y se puede copiar manualmente si es necesario. Sin embargo, debe hacerlo lo suficientemente largo para evitar colusiones).
Si utiliza cadenas generadas aleatoriamente, tendrán una distribución de fragmentación aproximadamente uniforme, a diferencia de los ObjectId estándar de mongo, que tienden a agrupar los registros creados aproximadamente al mismo tiempo en el mismo fragmento. (Si eso es útil o no realmente depende de su estrategia de fragmentación).
O puede generar su propio _id personalizado s que agruparán objetos relacionados en un fragmento, p. por propietario, región geográfica o una combinación. (Nuevamente, si eso es deseable o no depende de cómo pretenda consultar los datos y/o qué tan rápido los esté produciendo y almacenando. También puede hacer esto especificando una clave de fragmento, en lugar del _id sí mismo. Consulte la discusión a continuación).

Ventajas de usar ObjectId s:

Los ObjectIds son muy buenos para evitar colisiones. Si genera su propio _id s al azar o al mismo tiempo, entonces debe administrar el riesgo de colisión usted mismo.
Los ObjectIds contienen su tiempo de creación dentro de ellos. Esa puede ser una forma económica y fácil de conservar la fecha de creación de un documento y ordenar los documentos cronológicamente. (Por otro lado, si no desea exponer/filtrar la fecha de creación de un documento, ¡entonces no debe exponer su ObjectId!)

El nanoid El módulo puede ayudarlo a generar identificaciones aleatorias cortas. También proporcionan una calculadora lo que puede ayudarlo a elegir una buena longitud de identificación, según la cantidad de documentos/identificaciones que genere cada hora.

Alternativamente, escribí mongoose-generate-unique-key por generar muy identificadores aleatorios cortos (siempre que esté utilizando la biblioteca mongoose).

Estrategias de fragmentación

No pretenderé ser un experto en la mejor manera de fragmentar datos, pero aquí hay algunas situaciones que podríamos considerar:

Un observatorio astronómico o un acelerador de partículas maneja gigabytes de datos por segundo. Cuando se detecta un evento interesante, es posible que deseen almacenar una gran cantidad de datos en solo unos segundos. En este caso, es probable que deseen una distribución uniforme de los documentos entre los fragmentos, de modo que cada fragmento trabaje igual de duro para almacenar los datos y ningún fragmento se vea abrumado.
Tiene una gran cantidad de datos y, a veces, necesita procesarlos todos. En seguida. En este caso (pero dependiendo del algoritmo), una distribución uniforme podría volver a ser deseable, de modo que todos los fragmentos puedan trabajar igual de duro en el procesamiento de su parte de los datos, antes de combinar los resultados al final. (Aunque en este escenario, podemos confiar en el balanceador de MongoDB, en lugar de nuestra clave de partición, para una distribución uniforme. El balanceador se ejecuta en segundo plano después de que se hayan almacenado los datos. Después de recopilar una gran cantidad de datos, es posible que deba déjelo redistribuir los trozos durante la noche).
Tiene una aplicación de redes sociales con una gran cantidad de datos, pero esta vez muchos usuarios diferentes están haciendo muchas consultas ligeras relacionados principalmente con sus propios datos, o sus amigos o temas específicos. En este caso, no tiene sentido involucrar cada fragmento cada vez que un usuario realiza una pequeña consulta. Puede tener sentido fragmentar por ID de usuario (o por tema o por región geográfica) para que todos los documentos que pertenecen a un usuario se almacenen en un fragmento, y cuando ese usuario realiza una consulta, solo un fragmento necesita trabajar. Esto debería dejar los otros fragmentos libres para procesar consultas para otros usuarios, por lo que se puede atender a muchos usuarios a la vez.
Fragmentación de documentos por hora de creación (que le proporcionarán los ObjectId predeterminados) podría ser deseable si tiene muchas consultas ligeras que analizan datos durante períodos de tiempo similares. Por ejemplo, muchos usuarios diferentes que consultan diferentes gráficos históricos.

Pero puede que no sea tan deseable si la mayoría de sus usuarios solo consultan los documentos más recientes (una situación común en las plataformas de redes sociales) porque eso significaría que uno o dos fragmentos obtendrían la mayor parte del trabajo. La distribución por tema o tal vez por región podría proporcionar una distribución general más plana, al mismo tiempo que permite que los documentos relacionados se agrupen en un solo fragmento.

Es posible que desee leer los documentos oficiales sobre este tema: