Non sono assolutamente d'accordo con l'autore della risposta selezionata che Nessun ID di incremento automatico in MongoDB e ci sono buone ragioni . Non conosciamo i motivi per cui 10gen non ha incoraggiato l'utilizzo di ID con incremento automatico. È speculazione. Penso che 10gen abbia fatto questa scelta perché è semplicemente più semplice garantire l'unicità degli ID a 12 byte in un ambiente cluster. È una soluzione predefinita che si adatta alla maggior parte dei nuovi arrivati, quindi aumenta l'adozione del prodotto, il che è positivo per il business di 10 generazioni.
Ora permettetemi di raccontare a tutti la mia esperienza con ObjectIds in ambiente commerciale.
Sto costruendo un social network. Abbiamo circa 6 milioni di utenti e ogni utente ha circa 20 amici.
Ora immagina di avere una raccolta che memorizza la relazione tra gli utenti (chi segue chi). Sembra così
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
su cui abbiamo un indice composito univoco {user_id, followee_id} . Possiamo stimare che la dimensione di questo indice sia 12*2*6M*20 =2GB. Questo è l'indice per una rapida ricerca delle persone che seguo. Per una rapida ricerca delle persone che mi seguono ho bisogno dell'indice inverso. Sono altri 2 GB.
E questo è solo l'inizio. Devo portare questi ID ovunque. Abbiamo un cluster di attività in cui memorizziamo il tuo feed di notizie. Questo è ogni evento che tu o i tuoi amici fate. Immagina quanto spazio ci vuole.
E alla fine uno dei nostri ingegneri ha preso una decisione inconscia e ha deciso di memorizzare i riferimenti come stringhe che rappresentano ObjectId che ne raddoppia le dimensioni.
Cosa succede se un indice non rientra nella RAM? Niente di buono, dice 10gen:
Quando un indice è troppo grande per essere contenuto nella RAM, MongoDB deve leggere l'indice dal disco, operazione molto più lenta rispetto alla lettura dalla RAM. Tieni presente che un indice si adatta alla RAM quando il tuo server ha RAM disponibile per l'indice combinata con il resto del working set.
Ciò significa che le letture sono lente. La contesa sui blocchi aumenta. Anche le scritture diventano più lente. Vedere la contesa di blocco nell'80% di nish non è più scioccante per me.
Prima che tu te ne accorga, ti sei ritrovato con un cluster da 460 GB che devi dividere in frammenti e che è piuttosto difficile da manipolare.
Facebook utilizza 64 bit come ID utente :) C'è una ragione per questo. Puoi generare ID sequenziali
- utilizzando Consigli di 10gen .
- utilizzando mysql come archiviazione dei contatori (se sei preoccupato per la velocità dai un'occhiata a handlersocket )
- utilizzando il servizio di generazione ID che hai creato o utilizzando qualcosa come Fiocco di neve da Twitter.
Quindi ecco il mio consiglio generale per tutti. Per favore, riduci i tuoi dati il più piccoli possibile. Quando cresci, ti risparmierai molte notti insonni.
