- Artikel von Daniel Coupal und Ken W. Alger
englischer Originalartikel
https://www.mongodb.com/blog/post/building-with-patterns-the-subset-pattern
Übersetzung mit freundlicher Genehmigung von MongoDB
Die ersten PCs hatten riesige 256 KM RAM zur Verfügung. Meine Generation hat noch damit angefangen unter DOS spezielle Autoexec.bat und Config.sys Konfigurationen für einzelne Spiele anzulegen, damit diese genügend Arbeitsspeicher zur Verfügung hatten. Wer braucht schon den Treiber für das 5.25" Floppy Laufwerk ;-) Auch Festplatten waren zu Beginn recht teuer und daher begrenzt. Aufgrund dieser Limitierungen mußten z.B. beim Laden von Programmen die Disketten gewechselt werden mußten, da für das Arbeiten mit "großen" Datenmengen zu wenig Speicher zur Verfügung stand. Softwareentwickler mußten damals kreativer sein um mit den begrenzten Ressourcen klar zu kommen. Eine Möglichkeit war z.B. nur häufig verwendete Daten in den Arbeitsspeicher zu laden.
Auch moderne Applikationen sind nicht davor gefeit, Ressourcen zu verschwenden. MongoDB hält die regelmäßig genutzten Daten, das sog. Working Set, im Arbeitsspeicher. Wächst die Menge von Daten und Indexen, des Working Sets, über die Menge des verfügbaren Arbeitsspeichers hinaus, so werden Daten auf die Festplatte ausgelagert und evtl. langsame Festplattenzugriffe bei Abfragen notwendig.
Wie können wir dieses Problem umgehen? Als erstes können wir natürlich mehr RAM einbauen, das wird für eine Weile klappen. Wir können anfangen zu sharden, was aber in zusätzlicher Komplexität und zusätzlichen Kosten resultiert. Eine weitere Möglichkeit wäre es, die Größe des Working Sets zu reduzieren. An dieser Stelle kommt das "Subset Pattern" ins Spiel.
- Das Subset Pattern
Das Pattern adressiert die Probleme, die entstehen, wenn die Datenmenge den verfügbaren RAM überschreitet und Informationen aus dem Arbeitsspeicher verlagert werden. Oftmals wird das von großen Dokumenten verursacht, die eine Menge Daten enthalten, von denen aber nur Teile regelmäßig verwendet werden. Was bedeutet das genau?
Stellt euch eine E-Commerce Webseite vor, die zu jedem Produkt Reviews speichert. Wenn wir die daten des Produktes laden brauchen wir oft gar nicht alle Daten, meistens genügen die z.B. die 10 aktuellsten Reviews. Immer alle Daten, aller Reviews, verfügbar zu haben wird leicht dazu führen daß die Größe des Working Sets anwächst.
{
_id: ObjectId("507f1f77bcf86cd799439011"),
name "Super Widget",
description: "This is the most usefull item in your toolbox.",
price: { value: NumberDecimal("119.99"), currency: "USD" },
reviews: [
{
review_id: 786,
review_author: "Kristina",
review_text: "This is indeed an amazing widget.",
published_date: ISODate("2019-02-18")
},
{
review_id: 785,
review_author: "Trina",
review_text: "Very nice product, slow shipping.",
published_date: ISODate("2019-02-17")
},
...
{
review_id: 1,
review_author: "Hans",
review_text: "Meh, it´s okay.",
published_date: ISODate("2018-12-06")
}
]
}
Anstatt alle Reviews mit im Produkt zu speichern, können wir diese auf zwei Collections aufteilen. Eine Collection enthält die regelmäßig verwendeten Daten, z.B. die aktuellen Reviews und die andere Collection enthält die weniger häufig verwendeten Daten, z.B. alte Reviews, Produkthistorie, usw. Wir können einen Teil einer 1-N- oder N-N-Beziehung duplizieren, je nachdem welche Seite häufiger verwendet wird.
{
_id: ObjectId("507f1f77bcf86cd799439011"),
name "Super Widget",
description: "This is the most usefull item in your toolbox.",
price: { value: NumberDecimal("119.99"), currency: "USD" },
reviews: [
{
review_id: 786,
review_author: "Kristina",
stars: 5,
review_text: "This is indeed an amazing widget.",
published_date: ISODate("2019-02-18")
},
...
{
review_id: 776,
review_author: "Pablo",
stars: 5,
review_text: "Wow! Amazing.",
published_date: ISODate("2019-02-16")
}
]
}
{
product_id: ObjectId("507f1f77bcf86cd799439011"),
reviews: [
{
review_id: 786,
review_author: "Kristina",
review_text: "This is indeed an amazing widget.",
published_date: ISODate("2019-02-18")
},
{
review_id: 785,
review_author: "Trina",
review_text: "Very nice product, slow shipping.",
published_date: ISODate("2019-02-17")
},
...
{
review_id: 1,
review_author: "Hans",
review_text: "Meh, it´s okay.",
published_date: ISODate("2018-12-06")
}
]
}
In der Produkt Collection werden lediglich die aktuellsten Reviews gespeichert. Auf diese Weise wird das Working Set reduziert, da nur eine Teilmenge der Daten enthalten ist. Die zusätzlichen Informationen, in diesem Fall die Reviews, werden in einer separaten Reviews Collection gespeichert und stehen bereit, wenn ein Benutzer diese sehen möchte. Bei der Entscheidung, an welcher Stelle die Daten ausgesplittet werden sollen, sollten die häufig benötigten Teile in die Haupt-Collection und die weniger häufig verwendeten Teile in eine zusätzliche Collection wandern. In unserem Beispiel ist die Anzahl der angezeigten Reviews, auf der Produktseite, der entscheidende Faktor.
- Beispiel Use-Case
Das "Subset Pattern" ist dann nützlich, wenn eine größere Menge von Daten in einem Dokument nur selten benötigt wird. Produkt-Reviews, Kommentare zu Artikeln oder Schauspieler in einem Film sind Beispiele bei denen das Pattern angewendet werden kann. Wann immer die Größe der Dokumente Auswirkungen auf die Größe des Working Sets hat und dafür sorgt, daß das Working Set die Kapazitäten des RAM übersteigt, sollte das "Subset Pattern" in Betracht gezogen werden.
- Zusammenfassung
Dadurch, daß kleinere Dokumente für die regelmäßig benötigten Daten verwendet werden, schrumpft die Größe des Working Sets. Dadurch können die Zugriffszeiten für die regelmäßig verwendeten Daten stabil gehalten werden, während für die anderen Daten Festplattenzugriffe notwendig werden können. Ein Nachteil ist, daß wir das Subset managen müssen und evtl. alte Daten aus dem Hauptdokument in das Subset-Dokument verschieben müssen. Hierfür sind wiederum zusätzliche Datenbankzugriffe erforderlich.
Wer mehr über das Schema Design in MongoDB erfahren möchte, dem sei der Qualiero Kurs für Datenbank Entwickler empfohlen https://www.qualiero.com/lerninhalte/classroom-trainings/mongodb-datenbank-entwickler-kurs.html
