Wenn Sie mehrere Webserver mit mehreren Prozessen haben, können Sie wirklich nichts entfernen, wenn Sie die Eindeutigkeit verlieren.
Wenn Sie sich die Art der ObjectId ansehen :
- ein 4-Byte-Wert, der die Sekunden seit der Unix-Epoche darstellt,
- eine 3-Byte-Maschinenkennung,
- eine 2-Byte-Prozess-ID und
- ein 3-Byte-Zähler, beginnend mit einem zufälligen Wert.
Sie werden sehen, dass es nicht viel gibt, das Sie sicher entfernen könnten. Da die ersten 4 Bytes Zeit sind, wäre es eine Herausforderung, einen Algorithmus zu implementieren, der Teile des Zeitstempels auf saubere und sichere Weise entfernt.
Die Maschinenkennung und die Prozesskennung werden in Fällen verwendet, in denen mehrere Server und/oder Prozesse als Clients für den Datenbankserver fungieren. Wenn Sie eines davon fallen lassen, könnten Sie wieder mit Duplikaten enden. Der Zufallswert in den letzten 3 Bytes wird verwendet, um sicherzustellen, dass zwei Kennungen auf derselben Maschine innerhalb desselben Prozesses eindeutig sind, auch wenn sie häufig angefordert werden.
Wenn Sie es als Bestell-id verwendet haben , und Sie sichere Eindeutigkeit wünschen, würde ich nichts von der 12-Byte-Zahl wegschneiden, da sie sorgfältig entwickelt wurde, um einen robusten und effizienten verteilten Mechanismus zum Generieren eindeutiger Zahlen bereitzustellen, wenn viele verbundene Datenbankclients vorhanden sind.
Wenn Sie die letzten 5 Zeichen der ObjectId nehmen ... und in einem bestimmten Zeitraum, wie hoch ist die Wahrscheinlichkeit eines Konflikts?
- Prozess-ID
- Zähler
Die Konfliktwahrscheinlichkeit ist hoch . Die Prozess-ID kann während des gesamten Zeitraums gleich bleiben, und die andere Nummer ist nur eine aufsteigende Nummer, die sich nach 4095 Bestellungen wiederholen würde. Wenn der Prozess jedoch wiederverwendet wird, besteht auch die Möglichkeit, dass es zu einem Konflikt mit älteren Bestellungen usw. kommt. Und wenn Sie mit mehreren Datenbankclients sprechen, steigen die Chancen ebenfalls. Ich würde einfach nicht versuchen, die Nummer zu kürzen. Es lohnt sich nicht, dass unzufriedene Kunden versuchen, Bestellungen aufzugeben.
Selbst der Zeitstempel und der zufällige Ausgangswert sind nicht ausreichend, wenn mehrere Datenbankclients ObjectIds generieren . Wenn Sie beginnen, sich die verschiedenen Teile anzusehen, insbesondere im Kontext einer Farm von Datenbank-Clients, sollten Sie verstehen, warum die Teile vorhanden sind und warum ihre Entfernung zu einem Zusammenbruch in ObjectId führen könnte Generation.
Ich würde vorschlagen, dass Sie einen Algorithmus implementieren, um eine eindeutige Nummer zu erstellen und in der Datenbank zu speichern. Es ist einfach genug zu tun. Es wirkt sich ein wenig auf die Leistung aus, ist aber sicher.
Ich habe dieses
geschrieben vor einiger Zeit auf die Herausforderungen bei der Verwendung einer ObjectId geantwortet in einer URL. Es enthält einen Link zum Erstellen einer eindeutigen automatisch inkrementierenden Nummer mit MongoDB.
