MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Gibt es Vorteile bei der Verwendung einer benutzerdefinierten _id für Dokumente in MongoDB?

Vorteile bei der Generierung einer eigenen _id s:

  • Sie können sie benutzerfreundlicher gestalten, indem Sie aufsteigende Nummern zuweisen:1 , 2 , 3 , ...

  • Oder Sie können sie menschenfreundlicher gestalten, indem Sie zufällige Zeichenfolgen verwenden:t3oSKd9q

    (Das nimmt nicht zu viel Platz auf dem Bildschirm ein, könnte aus einer Liste ausgewählt und bei Bedarf möglicherweise manuell kopiert werden. Sie müssen es jedoch lang genug machen, um Absprachen zu vermeiden.)

  • Wenn Sie zufällig generierte Zeichenfolgen verwenden, haben sie eine ungefähr gleichmäßige Sharding-Verteilung, im Gegensatz zu den standardmäßigen Mongo-ObjectIds, die dazu neigen, Datensätze, die ungefähr zur gleichen Zeit erstellt wurden, auf demselben Shard zu gruppieren. (Ob das hilfreich ist oder nicht, hängt wirklich von Ihrer Sharding-Strategie ab.)

  • Oder Sie möchten vielleicht Ihre eigene benutzerdefinierte _id generieren s, die verwandte Objekte auf einem Shard gruppieren, z. nach Eigentümer, geografischer Region oder einer Kombination. (Ob dies wünschenswert ist oder nicht, hängt wiederum davon ab, wie Sie die Daten abfragen möchten und/oder wie schnell Sie sie erstellen und speichern. Sie können dies auch tun, indem Sie anstelle der _id selbst. Siehe die Diskussion unten.)

Vorteile der Verwendung von ObjectId s:

  • ObjectIds sind sehr gut geeignet, Kollisionen zu vermeiden. Wenn Sie Ihre eigene _id generieren zufällig oder gleichzeitig, dann müssen Sie das Kollisionsrisiko selbst handhaben.

  • ObjectIds enthalten ihre Erstellungszeit in sich. Das kann eine kostengünstige und einfache Möglichkeit sein, das Erstellungsdatum eines Dokuments beizubehalten und Dokumente chronologisch zu sortieren. (Auf der anderen Seite, wenn Sie das Erstellungsdatum eines Dokuments nicht preisgeben/durchsickern wollen, dann dürfen Sie seine ObjectId nicht preisgeben!)

Das Nanoid Modul kann Ihnen helfen, kurze zufällige IDs zu generieren. Sie bieten auch einen Rechner Dies kann Ihnen bei der Auswahl einer guten ID-Länge helfen, je nachdem, wie viele Dokumente/IDs Sie pro Stunde generieren.

Alternativ habe ich mongoose-generate-unique-key geschrieben für die Generierung sehr kurze zufällige IDs (vorausgesetzt, Sie verwenden die Mongoose-Bibliothek).

Sharding-Strategien

Ich behaupte nicht, ein Experte dafür zu sein, wie man Daten am besten fragmentiert, aber hier sind einige Situationen, die wir in Betracht ziehen könnten:

  1. Ein astronomisches Observatorium oder ein Teilchenbeschleuniger verarbeitet Gigabyte an Daten pro Sekunde. Wenn ein interessantes Ereignis erkannt wird, möchten sie möglicherweise eine riesige Datenmenge speichern in nur wenigen sekunden. In diesem Fall möchten sie wahrscheinlich eine gleichmäßige Verteilung der Dokumente über die Shards, sodass jeder Shard gleich hart arbeitet, um die Daten zu speichern, und kein Shard überfordert wird.

  2. Sie haben eine riesige Menge an Daten und müssen manchmal alle verarbeiten auf einmal. In diesem Fall (jedoch abhängig vom Algorithmus) könnte wiederum eine gleichmäßige Verteilung wünschenswert sein, damit alle Shards gleich hart an der Verarbeitung ihres Datenblocks arbeiten können, bevor sie die Ergebnisse am Ende zusammenführen. (Obwohl wir uns in diesem Szenario möglicherweise auf den Balancer von MongoDB statt auf unseren Shard-Schlüssel für die gleichmäßige Verteilung verlassen können. Der Balancer läuft im Hintergrund, nachdem Daten gespeichert wurden. Nachdem Sie viele Daten gesammelt haben, müssen Sie dies möglicherweise tun lassen Sie es, um die Chunks über Nacht neu zu verteilen.)

  3. Sie haben eine Social-Media-App mit einer großen Datenmenge, aber diesmal stellen viele verschiedene Nutzer viele leichte Anfragen sich hauptsächlich auf ihre eigenen Daten oder ihre spezifischen Freunde oder Themen beziehen. In diesem Fall macht es keinen Sinn, jeden Shard einzubeziehen, wenn ein Benutzer eine kleine Anfrage stellt. Es kann sinnvoll sein, nach Benutzer-ID (oder nach Thema oder geografischer Region) zu splitten, sodass alle Dokumente, die einem Benutzer gehören, auf einem Shard gespeichert werden und wenn dieser Benutzer eine Anfrage stellt, nur ein Shard arbeiten muss. Dadurch sollten die anderen Shards frei bleiben, um Abfragen für andere Benutzer zu verarbeiten, sodass viele Benutzer gleichzeitig bedient werden können.

  4. Sharding von Dokumenten nach Erstellungszeit (die Ihnen die Standard-ObjectIds geben) könnte wünschenswert sein, wenn Sie viele leichte Abfragen haben, die Daten für ähnliche Zeiträume betrachten. Zum Beispiel viele verschiedene Benutzer, die verschiedene historische Diagramme abfragen.

    Es ist jedoch möglicherweise nicht so wünschenswert, wenn die meisten Ihrer Benutzer nur die neuesten Dokumente abfragen (eine häufige Situation auf Social-Media-Plattformen), da dies bedeuten würde, dass ein oder zwei Shards die meiste Arbeit erledigen würden. Die Verteilung nach Thema oder vielleicht nach Region könnte eine flachere Gesamtverteilung bieten und gleichzeitig ermöglichen, dass verwandte Dokumente auf einem einzigen Shard zusammengeballt werden.

Vielleicht möchten Sie die offiziellen Dokumente zu diesem Thema lesen: