Ich stimme dem Autor der ausgewählten Antwort nicht zu, dass Keine Auto-Increment-ID in MongoDB und es gute Gründe gibt . Wir kennen keine Gründe, warum 10gen die Verwendung von automatisch inkrementierten IDs nicht unterstützt hat. Es ist Spekulation. Ich denke, 10gen hat diese Wahl getroffen, weil es einfach einfacher ist, die Eindeutigkeit von 12-Byte-IDs in einer Clusterumgebung sicherzustellen. Es ist eine Standardlösung, die für die meisten Neueinsteiger geeignet ist, und erhöht daher die Produktakzeptanz, was gut für das Geschäft von 10gen ist.
Lassen Sie mich nun allen von meinen Erfahrungen mit ObjectIds im kommerziellen Umfeld erzählen.
Ich baue ein soziales Netzwerk auf. Wir haben ungefähr 6 Millionen Benutzer und jeder Benutzer hat ungefähr 20 Freunde.
Stellen Sie sich nun vor, wir hätten eine Sammlung, die die Beziehung zwischen Benutzern speichert (wer folgt wem). Es sieht so aus
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
auf dem wir einen eindeutigen zusammengesetzten Index {user_id, followee_id} haben . Wir können die Größe dieses Index auf 12*2*6M*20 =2GB schätzen. Nun, das ist ein Index zum schnellen Nachschlagen von Personen, denen ich folge. Zum schnellen Auffinden von Personen, die mir folgen, benötige ich einen umgekehrten Index. Das sind weitere 2 GB.
Und das ist erst der Anfang. Ich muss diese Ausweise überall hin mitnehmen. Wir haben einen Aktivitätscluster, in dem wir Ihren Newsfeed speichern. Das ist jede Veranstaltung, die Sie oder Ihre Freunde machen. Stellen Sie sich vor, wie viel Platz es braucht.
Und schließlich traf einer unserer Ingenieure eine unbewusste Entscheidung und beschloss, Referenzen als Zeichenfolgen zu speichern, die die ObjectId darstellen, die ihre Größe verdoppelt.
Was passiert, wenn ein Index nicht in den Arbeitsspeicher passt? Nichts Gutes, sagt 10gen:
Wenn ein Index zu groß ist, um in den RAM zu passen, muss MongoDB den Index von der Festplatte lesen, was viel langsamer ist als das Lesen aus dem RAM. Denken Sie daran, dass ein Index in den Arbeitsspeicher passt, wenn Ihr Server RAM für den Index in Kombination mit dem Rest des Arbeitssatzes zur Verfügung hat.
Das bedeutet, dass Lesevorgänge langsam sind. Der Sperrkonflikt steigt. Schreibvorgänge werden auch langsamer. Sperrkonflikte in 80 % zu sehen, ist für mich kein Schock mehr.
Bevor Sie es wissen, haben Sie am Ende einen 460-GB-Cluster, den Sie in Shards aufteilen müssen und der ziemlich schwer zu manipulieren ist.
Facebook verwendet 64-Bit lang als Benutzer-ID :) Dafür gibt es einen Grund. Sie können fortlaufende IDs generieren
- unter Verwendung von 10gens Rat .
- Verwenden von mysql als Speicher für Zähler (wenn Sie sich Sorgen um die Geschwindigkeit machen, werfen Sie einen Blick auf Handlersocket )
- unter Verwendung eines von Ihnen erstellten ID-Erzeugungsdienstes oder unter Verwendung von etwas wie Snowflake von Twitter.
Hier also mein allgemeiner Rat an alle. Bitte machen Sie Ihre Daten so klein wie möglich. Wenn Sie wachsen, wird es Ihnen viele schlaflose Nächte ersparen.
