No estoy de acuerdo con el autor de la respuesta seleccionada de que No hay identificación de incremento automático en MongoDB y hay buenas razones . No conocemos las razones por las que 10gen no fomentó el uso de identificaciones incrementadas automáticamente. es especulación Creo que 10gen tomó esta decisión porque es más fácil garantizar la exclusividad de los ID de 12 bytes en un entorno agrupado. Es una solución predeterminada que se adapta a la mayoría de los recién llegados, por lo que aumenta la adopción del producto, lo que es bueno para el negocio de 10gen.
Ahora permítanme contarles a todos sobre mi experiencia con ObjectIds en un entorno comercial.
Estoy construyendo una red social. Tenemos aproximadamente 6 millones de usuarios y cada usuario tiene aproximadamente 20 amigos.
Ahora imagine que tenemos una colección que almacena la relación entre los usuarios (quién sigue a quién). Se parece a esto
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
en el que tenemos un índice compuesto único {user_id, followee_id} . Podemos estimar el tamaño de este índice en 12*2*6M*20 =2GB. Ese es el índice para una búsqueda rápida de las personas a las que sigo. Para buscar rápidamente a las personas que me siguen, necesito el índice inverso. Son otros 2 GB.
Y esto es sólo el principio. Tengo que llevar estas identificaciones a todas partes. Tenemos un grupo de actividades donde almacenamos su News Feed. Ese es cada evento que tú o tus amigos hacen. Imagina cuánto espacio ocupa.
Y finalmente, uno de nuestros ingenieros tomó una decisión inconsciente y decidió almacenar referencias como cadenas que representan ObjectId que duplica su tamaño.
¿Qué sucede si un índice no cabe en la RAM? Nada bueno, dice 10gen:
Cuando un índice es demasiado grande para caber en la RAM, MongoDB debe leer el índice desde el disco, que es una operación mucho más lenta que leer desde la RAM. Tenga en cuenta que un índice cabe en la RAM cuando su servidor tiene RAM disponible para el índice combinado con el resto del conjunto de trabajo.
Eso significa que las lecturas son lentas. La contención de bloqueo aumenta. Las escrituras también se vuelven más lentas. Ver la contención de bloqueo en el 80 % de finalización ya no me sorprende.
Antes de que te des cuenta, terminaste con un clúster de 460 GB que tienes que dividir en fragmentos y que es bastante difícil de manipular.
Facebook usa una identificación de usuario de 64 bits :) Hay una razón para eso. Puede generar identificaciones secuenciales
- utilizando Consejos de 10gen .
- utilizando mysql como almacenamiento de contadores (si le preocupa la velocidad, eche un vistazo a handlersocket )
- Usando el servicio de generación de ID que creaste o usando algo como Snowflake por Twitter.
Este es mi consejo general para todos. Por favor, haga sus datos lo más pequeños posible. Cuando crezca te ahorrará muchas noches de insomnio.
