Was ist MongoDB? Funktionen, Dokumentenmodell und Einsatzbereiche

MongoDB ist eine Datenbank, die Daten als Dokumente speichert, anstatt sie primär in relationalen Tabellen zu organisieren. Ziehen Sie sie für Daten in Betracht, die häufig zusammen gelesen werden, wie Produktkataloge mit unterschiedlichen Attributen oder verschachtelte Benutzerprofile, während Sie trotzdem das Schema entwerfen und die Leistung überprüfen.

Dieser Leitfaden erklärt MongoDBs Speichermodell, Funktionen, Anwendungsfälle und Kriterien für die Einführung. Für einen umfassenderen Überblick lesen Sie den Vergleich von NoSQL-Modellen und relationalen Datenbanken.

Wie speichert MongoDB Daten?

Ein Dokument besteht aus Feld-und-Wert-Paaren. Eine Sammlung ist eine logische Gruppierung von Dokumenten, und eine Datenbank kann Sammlungen für verschiedene Zwecke enthalten, wie Produkte, Bestellungen und Kunden.

MongoDB speichert Dokumente als BSON (Binary JSON). BSON stellt JSON (JavaScript Object Notation) Strukturen in binärer Form dar und unterstützt zusätzliche Typen, einschließlich Datumsangaben und ObjectId-Werten. MongoDB sollte daher nicht als ein Speicher verstanden werden, der einfach JSON-Textdateien speichert. Die Dokumentenreferenz erklärt Typen und Bezeichnungsregeln.

Dieses fiktive Produkt-JSON veranschaulicht die Struktur eines Dokuments. In einer Standardkollektion identifiziert _id ein Dokument. Das Beispiel verwendet einen lesbaren String; eine Anwendung benötigt dennoch ein Bezeichnungsformat und Regeln für den Umgang mit Duplikaten.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes ist ein verschachteltes Objekt und tags ist ein Array. Bücher können Autor- und Seitenfelder haben, während Elektronik Batterieinformationen hat. Gemeinsame Regeln für Preistypen, Pflichtfelder und fehlende Werte beibehalten.

Hauptmerkmale und ihre Bedingungen

Flexibles Schema und Validierung

Ein Schema definiert Felder, Typen und erforderliche Bedingungen. MongoDB erfordert standardmäßig nicht, dass jedes Dokument in einer Sammlung identische Felder hat. Diese Flexibilität beseitigt das Schema-Design nicht.

Schema-Validierung kann zulässige Typen und Wertebereiche einschränken. Koordinieren Sie Anwendungsprüfungen und Datenbankvalidierung, um gemischte Zahlen-/String-Preise oder inkonsistente Datumsdarstellungen zu verhindern. Bevor Regeln zu bestehenden Daten hinzugefügt werden, identifizieren Sie nicht konforme Dokumente und entscheiden Sie, wie Aktualisierungen gehandhabt werden.

Abfragen, Aggregation und zugehörige Daten

MongoDB-Abfragen verwenden Feldbedingungen und Operatoren anstelle der direkten Übernahme von SQL-Anweisungen. Lernen Sie die Syntax, die vom Treiber Ihrer Sprache oder der Shell verwendet wird. Punktnotation greift auf verschachtelte Felder zu, und Abfragen können auch Array-Bedingungen ausdrücken.

Eine Aggregations-Pipeline verarbeitet Dokumente durch Stufen wie Filtern, Gruppieren und Berechnen. Zum Beispiel können nicht stornierte Bestellpositionen gefiltert und die Gesamtmengen nach Produkt summiert werden. Der Aggregations-Pipeline-Leitfaden erklärt, wie Stufen funktionieren.

$lookup bietet einen Left Outer Join zu einer anderen Sammlung, daher ist „MongoDB hat keine Joins“ ungenau. Überprüfen Sie $lookup-Unterstützung und Leistungsbedingungen. Gehen Sie nicht davon aus, dass Referenzen automatisch die referentielle Integritätsdurchsetzung erhalten, die mit relationalen Fremdschlüsselbeschränkungen verbunden ist.

Indizes und Leistung

Ein Index ist eine Datenstruktur, die die zu durchsuchenden Daten reduzieren kann, um passende Dokumente zu finden. Einzel- und zusammengesetzte Indizes dienen unterschiedlichen Zugriffsmustern. Die Index-Dokumentation erklärt sowohl die Vorteile für Abfragen als auch die Kosten beim Schreiben.

Mehr Indizes erfordern Speicherplatz und Arbeit zur Pflege während des Schreibens. Die Leistung hängt auch von der Dokumentgröße, dem Lese-/Schreibverhältnis, dem Speicher, den Festplatten und dem Netzwerk ab. Bewerten Sie repräsentative Abfragen mit Ausführungsplänen und realistischen Lasten, anstatt anzunehmen, dass NoSQL von vornherein schnell ist.

Transaktionen und Lese-/Schreibgarantien

Ein Update eines einzelnen Dokuments ist atomar: Es wird nicht teilweise durchgeführt. Für Änderungen, die zusammen entweder erfolgreich sein oder fehlschlagen müssen über mehrere Dokumente hinweg, sollten Multi-Dokument-Transaktionen in Replikatsets oder Sharded Clustern in Betracht gezogen werden. Gehen Sie nicht davon aus, dass dieselbe Fähigkeit auf einem eigenständigen Server existiert.

ACID bedeutet Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Überprüfen Sie Einsatz- und Konfigurationsbedingungen in der Transaktionsdokumentation. Wenn die Erstellung einer Bestellung und die Reduzierung des Lagerbestands verschiedene Dokumente betreffen, definieren Sie Transaktionsgrenzen, Umgang mit gleichzeitigen Anfragen und Wiederholungsverhalten.

Read Concern steuert den Datenzustand, den ein Lesevorgang beobachten kann, während Write Concern die Bestätigungsebene für einen Schreibvorgang steuert. Legen Sie die Garantien fest, die erforderlich sind, bevor Sie einem Benutzer mitteilen, dass eine Zahlung abgeschlossen ist, und unterscheiden Sie Operationen, die ältere Werte von Replikaten akzeptieren können.

Sollten verwandte Daten eingebettet oder referenziert werden?

Einbetten legt verwandte Daten in ein Dokument. Referenzieren verlinkt auf den Bezeichner eines anderen Dokuments. Der Modellierungsleitfaden empfiehlt, zusammen zu speichern, was zusammen abgerufen wird; der Einbetten-vs-Referenzen-Leitfaden erklärt die Kompromisse für Beziehungen und Aktualisierungen.

Das Kopieren einer Lieferadresse in eine Bestellung kann deren historische Bedeutung bewahren. Das Kopieren der aktuellen Kontaktdaten eines Kunden in jede Bestellung erstellt Kopien, die bei Änderungen dieser Daten gepflegt werden müssen. Unterscheiden Sie zuerst historische Fakten von Werten, die immer aktuell sein müssen.

Ein reguläres BSON-Dokument hat eine maximale Größe von 16 Mebibyte (MiB). Das Anhängen jedes Kommentars oder jeder Protokolleintragung an ein Array kann diese Grenze erreichen und die Aktualisierungskosten erhöhen. Verwenden Sie separate Sammlungen, Verweise oder begrenzte Gruppen unter Berücksichtigung des Dokumentgrößenlimits.

Welche Anwendungsfälle verdienen Aufmerksamkeit?

Dies sind Gründe, ein Dokumentenmodell zu bewerten, statt Garantien basierend auf Branchenbezeichnungen. Tatsächliche Lesevorgänge und Aktualisierungen sollten die Wahl bestimmen.

Vergleichen Sie auch relationale Datenbanken, wenn flexible Berichte über mehrere Tabellen hinweg, gemeinsame Beziehungen und Einschränkungen oder komplexe Many-to-Many-Aktualisierungen zentrale Anforderungen sind. Das Speichern von JSON allein rechtfertigt nicht, eine bestehende Datenbank zu ersetzen. Prüfen Sie, ob ein Dokumentenmodell die wichtigen Abfragen und die operative Arbeitslast verbessert.

Ein kleines Beispiel zum Einfügen und Abfragen

Die folgenden Befehle verwenden die MongoDB-Shell, mongosh. Stellen Sie zunächst eine Verbindung zu einer separaten Übungsbereitstellung her, wobei Sie ein Konto mit Lese-, Schreib- und Indexerstellungsberechtigungen für die Zieldatenbank und eine installierte Shell verwenden. Siehe die MongoDB Shell-Dokumentation für Anweisungen zur Verbindung.

Das Beispiel fügt ein Produkt in product_catalog in der mongodb_intro_demo-Datenbank ein. Beginnen Sie mit einer leeren Sammlung dieses Namens in einer Übungsumgebung und überprüfen Sie, dass Ihre Verbindung auf diese Umgebung zielt, bevor Sie die Befehle ausführen.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() fügt Dokumente ein. Das wiederholte Einfügen desselben _id in einer Standard-Collection führt zu einem Duplicate-Key-Fehler. Für wiederholte Übungen verwenden Sie eine neue Übungsdatenbank oder identifizieren und behandeln Sie explizit nur das hinzugefügte Beispieldokument. Löschen Sie nicht eine bestehende Collection, um diesen Fehler zu beheben.

Diese Abfrage findet Produkte in books, die weniger als 30.000 koreanische Won kosten, gibt ihre Identifier, Namen und Preise zurück und sortiert nach aufsteigendem Preis. Mit nur den Beispieldaten erfüllt book-101 die Bedingungen.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt bedeutet „weniger als.“ Das zweite Objekt gibt zurückgegebene Felder an, eine Projektion, und 1 in sort() bedeutet aufsteigende Reihenfolge. Die find()-Referenz erklärt Filter und Projektionen.

Für häufige kategoriespezifische Preisfilter und Sortierungen sollten Sie diesen zusammengesetzten Index in Betracht ziehen. Untersuchen Sie die tatsächliche Verteilung und andere Abfragen, bevor Sie createIndex() in der Produktion anwenden.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

Der folgende Befehl führt die Abfrage aus und meldet Ausführungsstatistiken, ohne Dokumente zu ändern. Überprüfen Sie in den explain("executionStats")-Ergebnissen den gewählten Plan, die Schlüssel und die untersuchten Dokumente sowie die zurückgegebenen Dokumente. Eine kleine Sammlung könnte einen Sammlungsscan verwenden; das bloße Erstellen eines Index zeigt keine Geschwindigkeitsverbesserung.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

Replikation und Sharding haben unterschiedliche Aufgaben

Ein Replikatset ist eine Gruppe von Servern, die dieselben Daten pflegen. Typischerweise akzeptiert ein Primärserver Schreibvorgänge, und Sekundärserver replizieren Änderungen; berechtigte Mitglieder können nach einem Ausfall einen neuen Primärserver wählen. Der Replikationsleitfaden erklärt Wahlen und asynchrone Replikation.

Ein Failover kann vorübergehende Schreibverzögerungen oder Fehler verursachen, und Lesevorgänge von Sekundärservern können Replikationsverzögerungen widerspiegeln. Replikation garantiert nicht bedingungslos einen unterbrechungsfreien Dienst oder verhindert jeden Datenverlust. Entwickeln Sie Wiederholungsmechanismen, die Handhabung doppelter Anfragen und erforderliche Lese-/Schreibgarantien zusammen mit der Anwendung.

Sharding verteilt Daten über Server für horizontale Skalierung. Ein Shard-Schlüssel enthält die Felder, die für die Verteilung und Abfrageweiterleitung verwendet werden. Konzentrierte Schlüssel oder Abfragen, die jeden Shard besuchen müssen, können den Nutzen einschränken. Der Sharding-Leitfaden erklärt die Auswahl von Schlüsseln und die betriebliche Komplexität.

Replikation und Sharding können zusammen verwendet werden, dienen jedoch unterschiedlichen Zwecken. Überprüfen Sie das Modell, die Indizes und aktuelle Engpässe, bevor Sie Sharding einführen, nur weil die Daten möglicherweise wachsen. Es sollte einen Grund geben, seine zusätzliche Komplexität und Kosten zu akzeptieren.

Was sollten Sie überprüfen, bevor Sie MongoDB einführen?

1. Definieren Sie wichtige Operationen. Geben Sie Filter, Reihenfolge und Update-Einheiten für Produktdetails, Kategoriesuche nach Preisen und Auftragserstellung an; vergleichen Sie die tatsächlichen relationalen und Dokumenten-Implementierungen.
2. Überprüfen Sie das Modell und die Korrektheit. Entscheiden Sie über Einbettung oder Referenzen, Dokumentgröße, Validierung, Indizes, Transaktionen und Sofort-Lese-Anforderungen.
3. Vergleichen Sie die repräsentative Last. Messen Sie Latenz, Durchsatz und Fehler mit realistischen Daten und Anfrageverteilung. Protokollieren Sie Versionen, Hardware und Einstellungen und untersuchen Sie Ausfall- und Wiederherstellungsszenarien.
4. Wählen Sie ein Betriebsmodell. Entscheiden Sie zwischen Selbstverwaltung und einem Managed Service, wobei Verantwortlichkeiten für Backup, Wiederherstellung, Überwachung, Upgrades und Support festzulegen sind.
5. Bereiten Sie die Migration und einen Rückweg vor. Definieren Sie Identifikator-/Typumwandlungen, Prüfungen auf fehlende Daten, Schreibvorgänge während des Cutovers und Bedingungen für die Rückkehr zum bestehenden Speicher.

MongoDB Atlas ist ein verwalteter Cloud-Dienst mit einer anderen Aufteilung der betrieblichen Verantwortung als eine selbstverwaltete Bereitstellung. Verwenden Sie die Atlas-Dokumentation, um die erforderlichen Funktionen und Bereitstellungsoptionen zu überprüfen. Berücksichtigen Sie neben den Instanzkosten auch Speicher, Backups, Netzwerk und den betrieblichen Aufwand.

Für die Produktion überprüfen Sie Konten mit minimalen Rechten, verschlüsselte Verbindungen, Netzwerkeinschränkungen und die Verwaltung von Anmeldeinformationen unter Verwendung der Sicherheitsrichtlinien, die für Ihre Bereitstellung geeignet sind. Eine versehentliche Löschung kann auf Replikate übertragen werden, daher ersetzt die Replikation kein Backup. Befolgen Sie die Backup-Methode-Richtlinien und überprüfen Sie, dass die Wiederherstellung tatsächlich funktioniert.