Se hai più server Web, con più processi, non c'è davvero qualcosa che puoi rimuovere perdendo l'unicità.
Se osservi la natura di ObjectId :
- un valore di 4 byte che rappresenta i secondi dall'epoca di Unix,
- un identificatore di macchina a 3 byte,
- un ID processo a 2 byte e
- un contatore a 3 byte, che inizia con un valore casuale.
Vedrai che non c'è molto che potresti rimuovere in sicurezza. Poiché i primi 4 byte sono tempo, sarebbe difficile implementare un algoritmo che rimuove parti del timestamp in modo pulito e sicuro.
L'identificatore della macchina e l'identificatore del processo vengono utilizzati nei casi in cui sono presenti più server e/o processi che agiscono come client per il server del database. Se hai lasciato cadere uno di questi, potresti ritrovarti di nuovo con i duplicati. Il valore casuale degli ultimi 3 byte viene utilizzato per assicurarsi che due identificatori, sulla stessa macchina, all'interno dello stesso processo siano univoci, anche se richiesti frequentemente.
Se lo stavi utilizzando come id dell'ordine e si desidera un'unicità assicurata, non taglierei nulla dal numero di 12 byte poiché è stato accuratamente progettato per fornire un meccanismo distribuito robusto ed efficiente per generare numeri univoci quando ci sono molti client di database connessi.
Se hai preso gli ultimi 5 caratteri dell'ObjectId..., e in un dato periodo, qual è la probabilità di conflitto?
- ID processo
- contatore
La probabilità di conflitto è alta . L'ID del processo può rimanere lo stesso per l'intero periodo e l'altro numero è solo un numero crescente che si ripeterebbe dopo 4095 ordini. Ma se il processo si ricicla, hai anche la possibilità che ci sia un conflitto con ordini precedenti, ecc. E se stai parlando di più client di database, anche le possibilità aumentano. Non proverei a tagliare il numero. Non vale la pena che i clienti insoddisfatti cerchino di effettuare ordini.
Anche il timestamp e il valore del seme casuale non sono sufficienti quando sono presenti più client di database che generano ObjectIds . Quando inizi a guardare i vari pezzi, specialmente nel contesto di una farm di client di database, dovresti vedere perché i pezzi sono lì e perché rimuoverli potrebbe portare a un tracollo in ObjectId generazione.
Ti suggerirei di implementare un algoritmo per creare un numero univoco e salvarlo nel database. È abbastanza semplice da fare. Influisce leggermente sulle prestazioni, ma è sicuro.
Ho scritto questo
rispondere qualche tempo fa sulle sfide dell'utilizzo di un ObjectId in un URL. Include un collegamento a come creare un numero univoco con incremento automatico utilizzando MongoDB.
