MongoDB-Datenmodellierungshandbuch für Blogging-Apps

Du willst also dein eigenes Content-Management-System (CMS) aufbauen, das manchmal auch als Blog bezeichnet wird? Das ist ein super Beispiel, wenn man lernt, wie man eine Datenbank benutzt, egal ob es sich um ein relationales Datenbankmanagementsystem (RDBMS) oder eine nosql-Datenbank handelt, weil es eine potenziell große Datenmenge sowie die Beziehungen innerhalb dieser Daten untersucht. Das Beispiel einer Blogging-App lässt sich auch gut auf andere Datenmodellierungsanforderungen übertragen.

In diesem Artikel schauen wir uns an, was du beim Entwerfen deiner nosql-Dokumente in MongoDB beachten solltest und was du besser nicht machen solltest. Wir werden aber keine Blogging-App entwickeln, sondern uns nur mit den Daten beschäftigen.

Die Teile einer Blogging-App

Bevor wir versuchen, ein Dokumentmodell für einen Blog zu entwerfen, sollten wir einen Schritt zurücktreten und über alle Komponenten nachdenken, die mit Daten verbunden sein könnten.

Ein typischer Blog könnte so aussehen:

• Viele Leute oder Autoren
• Viele Blogbeiträge für einen Autor
• Viele Kommentare zu einem einzelnen Blogbeitrag

Klar, diese Liste von Funktionen kann je nach deinen geschäftlichen Anforderungen an einen Blog noch länger und komplexer werden. Um es einfach zu halten, modellieren wir unsere Daten anhand der obigen Angaben.

Was du tun kannst, aber nicht tun solltest

Wenn du dir die oben genannten Funktionen anschaust, denkst du vielleicht zuerst daran, jeden Punkt als eigenes Dokument zu behandeln. Das ist der typische Ansatz, den du in einer relationalen Datenbank wie Postgres verwenden würdest. In MongoDB könnte das ungefähr so aussehen:

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic."
}

Das oben Genannte könnte eine sehr vereinfachte Darstellung eines Autors sein. Natürlich könntest du noch viele andere Felder haben, wie „ email “ und so weiter, aber das ist hier nicht wirklich wichtig.

Dann könnten wir für Blog-Beiträge Folgendes haben:

{
	"_id": "blog-1",
	"author_id": "author-1",
	"title": "MongoDB is Awesome!",
	"content": "This is some blog content..."
}

Genau wie beim vorherigen könnte das Blog-Dokument auch andere Felder haben, wie z. B. „ tags “ und was dir sonst noch einfällt. Das Wichtigste hier ist, dass es eine Referenz vom Typ „ id “ zwischen den beiden Dokumenten gibt. Mehr dazu gleich.

Das endgültige Dokumentmodell in diesem Szenario würde sich um Kommentare drehen:

{
	"_id": "comment-1",
	"blog_id": "blog-1",
	"username": "Anonymous User",
	"content": "Hey great article, it really helped a lot!"
}

Auch hier hat das Kommentardokument in diesem Szenario eine Referenzbeziehung, die auf einem Wert „ id “ zwischen dem Kommentardokument und dem Blogdokument basiert. Das ist in relationalen Datenbanken total üblich, und ehrlich gesagt würde es auch in MongoDB super funktionieren. Das ist aber nicht die beste Art, MongoDB zu nutzen.

Ein Grund, warum du das in MongoDB nicht machen solltest, ist die Leistung.

Um diese drei Dokumente zusammenzufügen, solltest du eine „ $lookup “-Operation innerhalb einer Aggregationspipeline verwenden. Diese „ $lookup “-Operationen sind nicht billig und können deine Leistung beeinträchtigen, wenn deine Datenbank wächst, vor allem, wenn du mehr als eine „ $lookup “-Operation in deiner Pipeline hast.

Es gibt bessere Wege, um die Aufgabe in MongoDB zu erledigen.

Ein besserer, MongoDB-freundlicherer Ansatz für die Datenmodellierung

Eine der ersten Regeln von MongoDB ist, dass Daten, auf die zusammen zugegriffen wird, auch zusammen gespeichert werden sollten. Das Speichern jeder Funktion in einem separaten Dokument oder einer separaten Sammlung verstößt gegen diese Regel, weil wir nicht mehr nur einen einzigen Abrufvorgang für die Daten machen, die dem Benutzer angezeigt werden.

Versuchen wir's nochmal und modellieren die Dokumente für unseren Blog so:

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic.",
	"posts": [
		{
			"title": "MongoDB is Awesome!",
			"content": "This is some blog content...",
			"comments": [
				{
					"username": "Anonymous User",
					"content": "Hey great article, it really helped a lot!"
				}
			]
		}
	]
}

Okay, also eine der wichtigsten MongoDB-Regeln ist im obigen Modell erfüllt. Wir haben ein einziges Dokument, das alle Blogbeiträge und alle Kommentare mit dem Autor mithilfe von Verschachtelungen speichert.

Auch wenn es funktionieren könnte, ist es wahrscheinlich keine gute Idee, die Dokumente deiner Blogging-App so zu modellieren.

MongoDB hat Grenzen für die Dokumentgröße, und wenn du unbegrenzte Arrays in diesen Dokumenten hast, riskierst du, diese Grenzen zu überschreiten. Ganz zu schweigen davon, dass du bei großen Arrays auf Performance-Probleme stoßen könntest. In diesem Fall könnten wir unbegrenzt viele Blogbeiträge und unbegrenzt viele Kommentare pro Blogbeitrag haben. Irgendwann wird es chaotisch werden.

In diesem Fall könnte eine Mischung aus beiden Strategien besser funktionieren.

Denk dran, dass Autoren, Blogbeiträge und Kommentare mit beliebig vielen Feldern verknüpft sein können. In diesem Beispiel haben wir es minimal gehalten. Vor diesem Hintergrund wissen wir, dass die am häufigsten aufgerufenen Daten der Blog selbst sein werden. Schau dir das neue Design an:

{
	"_id": "blog-1",
	"author": {
		"_id": "author-1",
		"name": "Nic Raboy",
	},
	"title": "MongoDB is Awesome!",
	"content": "This is some blog content...",
	"comments": [
		{
			"username": "Anonymous User",
			"content": "Hey great article, it really helped a lot!"
		}
	]
}

Das zweite Dokument, das wir in diesem Beispiel haben, wäre immer noch das Originaldokument mit den Autoreninfos:

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic."
}

Wir wissen, dass ein paar Infos zum Autor in einem Blogartikel gezeigt werden sollten, aber wir brauchen nicht unbedingt alle Infos. Wir können die nötigen Autoreninfos zusammen mit dem _id in den Blogbeitrag einbauen. Wenn der Nutzer mehr über den Autor wissen will, kann er in deiner App nachschauen. Die Operation „ $lookup “ wird nicht jedes Mal ausgeführt, was die Leistung verbessert.

Jetzt haben wir das Problem, dass es potenziell unendlich viele Kommentare zu jedem Blogartikel gibt, die gerade als Array angehängt sind.

Es gibt ein paar Möglichkeiten, damit umzugehen, und letztendlich liegt die Entscheidung bei dir:

• Du kannst den naiven Ansatz wählen und sie als Array speichern, was wahrscheinlich keine gute Idee ist.
• Du kannst die Kommentare wieder zum ursprünglichen Design mit einem Kommentar pro Dokument zurückbringen, indem du eine Referenz-ID zum Blog-Artikel verwendest und sie mit den Funktionen „ $lookup “ einfügst.
• Du kannst eine Archivierungsstrategie nutzen, bei der du eine bestimmte Anzahl von Kommentaren in einem Array innerhalb des Blogartikels speicherst und gleichzeitig für jeden Kommentar ein separates Dokument erstellst. So kannst du nur bei Bedarf nach zusätzlichen Kommentaren suchen.
• Du kannst das Bucketing-Muster erkunden, indem du Kommentare in „Buckets“ mit etwa 100 Kommentaren pro Dokument gruppierst und so viele Kommentar-Buckets abfragst, wie du gerade brauchst. Durch Bucketing umgeht man die Begrenzung der Dokumentgröße und es hilft auch bei der Paginierung. Du kannst die Leistung bei diesem Ansatz auch verbessern, indem du einen Index auf der Tabelle „ blog_id ” erstellst, um Kommentare zu einem bestimmten Blog-Artikel schnell abzurufen. Mehr Infos zum Indexieren findest du in der MongoDB-Dokumentation.
• Mischen, kombinieren und mehr...

Bei der Bucketing-Methode könnten deine Kommentardokumente so aussehen:

{
	"_id": "comment-bucket-1",
	"blog_id": "blog-1",
	"comments": [
		{
			"username": "Anonymous User",
			"content": "Hey great article, it really helped a lot!"
		},
		// More comments here...
	],
	"comment_count": 57
}

In diesem Fall suchst du bei neuen Kommentaren nach einem Bucket, der nicht voll ist. Du fügst den neuen Kommentar zum Array hinzu und erhöhst den Zählwert. Diese Strategie hängt zwar stärker von der Logik auf Anwendungsebene ab, um die Buckets zu verwalten, führt aber zu einer besseren Leistung. Wenn du in deinem Blog einen unendlichen Scroll-Mechanismus hast, ist das sogar noch besser, weil du dann mit den Buckets besser paginieren kannst.

Auch wenn das hier nicht so richtig zum Thema passt, wenn du mal sehen willst, wie man einen neuen Kommentar hinzufügt, filterst du einfach die Sammlung der Kommentar-Buckets (siehe Beispielabfrage unten) nach Buckets, die mit dem „ blog_id ” übereinstimmen und einen „ comment_count ” haben, der kleiner ist als der von dir gewählte Wert.

Für die Übereinstimmung würdest du den Operator „ $push “ in deinen Aktualisierungskriterien und den Operator „ $inc “ verwenden, um den Zählwert deiner Kommentaranzahl zu erhöhen. All das kannst du in einem einzigen Schritt erledigen. Wenn du das Flag „ upsert “ verwendest, kannst du einen neuen Kommentar-Bucket erstellen, falls noch keiner vorhanden ist, der deinen Kriterien entspricht.

Beispiel für eine Aktualisierungsabfrage: 

db.commentBuckets.updateOne(
  { blog_id: "blog-1", comment_count: { $lt: 100 } },
  { $push: { comments: newComment }, $inc: { comment_count: 1 } },
  { upsert: true }
)

Fazit

So toll es auch wäre, zu sagen, dass du alles über deinen Blog in einem einzigen verschachtelten Dokument speichern solltest, wäre das wahrscheinlich keine so gute Idee. Genauso wie es wahrscheinlich keine gute Idee wäre, ein Datenmodell zu implementieren, das gut mit einer relationalen Datenbank funktioniert, aber nicht unbedingt mit einer Dokumentendatenbank wie MongoDB.

Mit MongoDB solltest du deine referenzierten Beziehungen so weit wie möglich reduzieren, um die bestmögliche Leistung zu erzielen.

Beachte beim Skalieren Folgendes:

• Wenn du viele Kommentare erwartest, solltest du das Bucket-Muster oder eine Kombination davon zusammen mit einer teilweisen Einbettung in das Blog-Dokument in Betracht ziehen.
• Was sind deine Anforderungen an die Paginierung?
• Indiziere deine Sammlungen so, wie du sie in deiner Anwendung abfragen willst.

Also nochmal: Überleg dir, wie du die Blog-Daten in deinem Frontend zeigen willst. Brauchst du wirklich alle Autoreninfos mit der Anfrage oder reichen ein paar davon? Willst du wirklich eine Million Kommentare zu deinem Blogartikel laden oder reicht es, wenn du nur ein paar wenige lädst? Wenn du mal darüber nachdenkst, wirst du überrascht sein, wie viele Join-Operationen du gar nicht brauchst.

Wenn du noch keine Erfahrung mit MongoDB hast, schau dir doch mal den Kurs „Einführung in MongoDB in Python“ an.