Si tiene múltiples servidores web, con múltiples procesos, entonces realmente no hay algo que pueda eliminar con la pérdida de singularidad.
Si observa la naturaleza del ObjectId :
- un valor de 4 bytes que representa los segundos desde la época de Unix,
- un identificador de máquina de 3 bytes,
- una identificación de proceso de 2 bytes, y
- un contador de 3 bytes, que comienza con un valor aleatorio.
Verá que no hay mucho allí que pueda eliminar con seguridad. Como los primeros 4 bytes son de tiempo, sería un desafío implementar un algoritmo que eliminara partes de la marca de tiempo de una manera limpia y segura.
El identificador de máquina y el identificador de proceso se utilizan en los casos en que hay varios servidores y/o procesos que actúan como clientes del servidor de la base de datos. Si dejó caer cualquiera de esos, podría terminar con duplicados nuevamente. El valor aleatorio como los últimos 3 bytes se usa para garantizar que dos identificadores, en la misma máquina, dentro del mismo proceso sean únicos, incluso cuando se soliciten con frecuencia.
Si lo estuviera usando como un pedido id , y desea unicidad garantizada, no eliminaría nada del número de 12 bytes, ya que fue diseñado cuidadosamente para proporcionar un mecanismo distribuido robusto y eficiente para generar números únicos cuando hay muchos clientes de bases de datos conectados.
Si tomó los últimos 5 caracteres del ObjectId... y en un período determinado, ¿cuál es la probabilidad de conflicto?
- identificación del proceso
- contador
La probabilidad de conflicto es alta . La identificación del proceso puede permanecer igual durante todo el período, y el otro número es solo un número creciente que se repetiría después de 4095 pedidos. Pero, si el proceso se recicla, también existe la posibilidad de que haya un conflicto con pedidos anteriores, etc. Y si está hablando de varios clientes de base de datos, las posibilidades también aumentan. Simplemente no intentaría recortar el número. No vale la pena que los clientes descontentos intenten hacer pedidos.
Incluso la marca de tiempo y el valor inicial aleatorio no son suficientes cuando hay varios clientes de bases de datos que generan ObjectIds . A medida que comience a observar las diversas piezas, especialmente en el contexto de una granja de clientes de base de datos, debería ver por qué las piezas están allí y por qué eliminarlas podría provocar un colapso en ObjectId generación.
Le sugiero que implemente un algoritmo para crear un número único y almacenarlo en la base de datos. Es bastante simple de hacer. Afecta un poco el rendimiento, pero es seguro.
Escribí esto
respondió hace un tiempo sobre los desafíos de usar un ObjectId en una URL. Incluye un enlace a cómo crear un número de incremento automático único usando MongoDB.
