Se você tiver vários servidores da Web, com vários processos, não há realmente algo que você possa remover com a perda de exclusividade.

Se você observar a natureza do ObjectId :

• um valor de 4 bytes representando os segundos desde a época do Unix,
• um identificador de máquina de 3 bytes,
• um ID de processo de 2 bytes e
• um contador de 3 bytes, começando com um valor aleatório.

Você verá que não há muito que você possa remover com segurança. Como os primeiros 4 bytes são tempo, seria um desafio implementar um algoritmo que removesse partes do timestamp de forma limpa e segura.

O identificador de máquina e o identificador de processo são usados ​​nos casos em que existem vários servidores e/ou processos atuando como clientes do servidor de banco de dados. Se você descartar qualquer um deles, poderá acabar com duplicatas novamente. O valor aleatório como os últimos 3 bytes é usado para garantir que dois identificadores, na mesma máquina, dentro do mesmo processo sejam únicos, mesmo quando solicitados com frequência.

Se você estava usando como um pedido id , e você deseja exclusividade garantida, eu não cortaria nada do número de 12 bytes, pois ele foi cuidadosamente projetado para fornecer um mecanismo distribuído robusto e eficiente para gerar números exclusivos quando houver muitos clientes de banco de dados conectados.

Se você pegou os últimos 5 caracteres do ObjectId..., e em um determinado período, qual a probabilidade de conflito?

• ID do processo
• contador

A probabilidade de conflito é alta . O ID do processo pode permanecer o mesmo durante todo o período, e o outro número é apenas um número incremental que se repetiria após 4095 pedidos. Mas, se o processo reciclar, você também tem a chance de haver um conflito com pedidos mais antigos, etc. E se você estiver falando com vários clientes de banco de dados, as chances também aumentam. Eu só não tentaria cortar o número. Não vale a pena os clientes insatisfeitos tentando fazer pedidos.

Mesmo o timestamp e o valor de semente aleatório não são suficientes quando há vários clientes de banco de dados gerando ObjectIds . À medida que você começa a olhar para as várias partes, especialmente no contexto de um farm de clientes de banco de dados, você deve ver por que as partes estão lá e por que removê-las pode levar a um colapso no ObjectId geração.

Eu sugiro que você implemente um algoritmo para criar um número único e armazená-lo no banco de dados. É bastante simples de fazer. Isso afeta um pouco o desempenho, mas é seguro.

Eu escrevi isto responda há algum tempo sobre os desafios de usar um ObjectId em um URL. Ele inclui um link para como criar um número único de incremento automático usando o MongoDB.