MongoDB - Harmonisierung der Datenmodellierung

Der Wechsel von traditionellen relationalen Datenbanksystemen zu dokumentenorientierten Datenbanksystemen (auch bekannt als No-SQL) ist Teil der Transformation und Modernisierung von Anwendungen. Bei der Modellierung der Daten für eine Anwendung besteht jedoch die Möglichkeit, entweder zu viel oder zu wenig zu modellieren. In diesem Beitrag werden die optimalen Wege der Datenmodellierung für dokumentenorientierte Datenbanksysteme beschrieben, um eine optimale Leistung zu erzielen.

Relationale Datenbanksysteme organisieren Daten in Form von Tabellen mit Zeilen und Spalten, während eine dokumentenorientierte Datenbank die Daten im JSON-Format (JavaScript Object Notation) als Dokument organisiert.

Aus Sicht der Datenorganisation besteht der Hauptunterschied zwischen SQL- und No-SQL-Datenbanksystemen darin, dass relationale Datenbanksysteme die Daten für ein bestimmtes Objekt in der Regel über mehrere Tabellen hinweg speichern, indem sie die Normalisierungsprinzipien anwenden, während No-SQL-Datenbanksysteme alle Informationen zu einem Objekt in einem einzigen Dokument speichern, ohne dass in einem anderen Dokument danach gesucht werden muss. Der subtile Akt, alle Informationen zu einem Objekt in einem einzigen Dokument zu speichern, ist oft verwirrend und kann zu Leistungsproblemen führen. Sie müssen darauf achten, ein optimales Datenmodell zu erstellen und die unten aufgeführten Grundsätze zu befolgen.

Normalisierung vs. De-Normalisierung

Keines der beiden Prinzipien (Normalisierung und De-Normalisierung) hat einen Vorteil gegenüber dem anderen, aber die Praxis hängt von der Datenpersona ab. Der Kompromiss zwischen Normalisierung und De-Normalisierung liegt im Zugriffsdurchsatz und der Integrität der Daten.

Betrachten Sie zum Beispiel das folgende Dokumentobjekt:

Customer: {
    ‘_id’: “cust_001”, 
    'Name':"Customer_One",
    ‘Address’:”Address details”, 
    'Orders_List': [
[0]: {
            'Type': "Sports",
            'SubType': "Tennis",
            'Item': "Racquet",
            'ItemSubType': "Wide-Band",
            'OrderStatus': "Active",
            'Quantity': 1,
            'DeliverySchedule':"2021-June-23",
            'DeliveryStatus':"In-Progress As Planned"
        }
    ]   
}

Im obigen Beispiel befindet sich das Dokumentobjekt Kunde, das auch die Bestellungsdetails als Unterdokument enthält (Teil der Liste, Composite-Beziehung), im de-normalisierten Zustand.

• Zur Verwaltung der Auftragsdetails eines bestimmten Kunden ohne weitere Suche
• Hoher Durchsatz beim Zugriff auf die Daten.

Stellen Sie sich ein Szenario vor, in dem alle Bestellungen, die "noch zu liefern" und vom Typ "Sport" sind, angezeigt und/oder verwaltet (aktualisiert) werden müssen. Dazu müssen Sie alle Kundendokumente scannen und solche Dokumente identifizieren, die die Kriterien erfüllen und anschließend verwaltet werden können. In diesem Szenario wäre das ineffizient.

Wir haben das Datenmodell nach dem Normalisierungsprinzip überarbeitet und es kann wie folgt dargestellt werden:

Customer: {
    'Name':"Customer_One",
    ‘Address’:”Address details”, 
    'Orders_List': [
[0]: “Order_1”
    ]   
}

Order: {
    ‘_id’: “Order_1”,
    'Type': "Sports",
    'SubType': "Tennis",
    'Item': "Racquet",
    'ItemSubType': "Wide-Band",
    'OrderStatus': "Active",
    'Quantity': 1,
    'DeliverySchedule':"2021-June-23",
    'DeliveryStatus':"In-Progress As Planned"
}

Die Dokumente vom Typ 'Kunde' und 'Bestellung' sind normalisiert und haben eine gemeinsame Beziehung, indem sie einen Verweis auf die Bestellung aus dem Dokument 'Kunde' haben. Dieses Datenmodell ist optimal für die Szenarien:

• Dokument vom Typ 'Bestellung' kann seinen eigenen Lebenszyklus haben
• Ermöglicht die Referenzierung aus anderen Dokumenten.
• Datenkonsistenz
• Flexibel, um die Funktionalität zu erweitern, um verschiedenen Persona der Daten gerecht zu werden.

Hier haben beide Prinzipien, die Normalisierung und die De-Normalisierung, ihre eigenen Vorteile und vieles hängt von der Persona der Daten ab.

Die Normalisierung oder De-Normalisierung des Datenmodells hängt von verschiedenen Faktoren ab:

• Konsistenz der Daten
• Lesefrequenz vs. Schreibfrequenz
• Anschauliche Szenarien der Datennutzung
• Bedeutung der Leistung bei Lesevorgängen
• Abfragen der eingebetteten Dokumentfelder oder der Felder des übergeordneten Dokuments.
• Wachsendes Dokument - Ein Dokument, das ständig wächst, ist nicht ideal für eine bessere Leistung.
• Selbstversorger

Redundant

Das Datenmodell enthält redundante Daten, weil:

• Dieselben Daten werden in verschiedenen Szenarien verwendet.
• Die Leseleistung ist wichtiger als die Schreibleistung.

Für typische Designer von relationalen Datenmodellen scheint dies umständlich zu sein, aber gut durchdachte und orchestrierte Schreiboperationen helfen dabei, die Leseleistung erheblich zu verbessern.

Bei demselben Beispiel kann das Datenmodell wie folgt umgestaltet werden:

Customer: {
    ‘_id’: “cust_001”, 
    'Name':"Customer_One",
    ‘Address’:”Address details”, 
    'Orders_List': [
[0]: {
            'Type': "Sports",
            'SubType': "Tennis",
            'Item': "Racquet",
            'ItemSubType': "Wide-Band",
            'OrderStatus': "Active",
            'Quantity': 1,
            'DeliverySchedule':"2021-June-23",
            'DeliveryStatus':"In-Progress As Planned"
        }
    ]   
}
Order: {
    ‘_id’: “Order_1”,
    'Type': "Sports",
    'SubType': "Tennis",
    'Item': "Racquet",
    'ItemSubType': "Wide-Band",
    'OrderStatus': "Active",
    'Quantity': 1,
    'DeliverySchedule':"2021-June-23",
    'DeliveryStatus':"In-Progress As Planned"
}

Hier ist das Dokument vom Typ 'Order' überflüssig, aber ein solches Modell ermöglicht:

• Hohe Leseleistung
• Verfügbarkeit von Daten für Lesevorgänge in lebendigen Szenarien, d.h. Vorbefüllung der Daten und Bereitstellung für jedes spezifische Szenario.

Ein Datenmodell mit redundanten Daten erfordert jedoch mehrere Schreibvorgänge und ein gutes Design der Orchestrierung ist erforderlich, um sicherzustellen, dass keine signifikanten Auswirkungen durch mehrere Schreibvorgänge auf das System entstehen.

Kontrolle vs. Daten

Bei der Modellierung der Daten führt das Prinzip, alle Informationen zu einem Objekt in einem einzigen Dokument zu speichern, oft dazu, dass die Informationen zur Steuerung der Daten zusammen mit den eigentlichen Daten gespeichert werden. Das folgende Dokument zeigt beispielsweise einen Auftrag vom Typ 'Sport' an

Order:
{
    'Type': "Sports",
    'SubType': "Tennis",
    'Item': "Racquet",
    'ItemSubType': 'Wide-Band',
    'Quantity': 1
    'Role': {
        'Type':'OrderManagement',
        'SubType':'Sports'
    }
}

Dieses Dokument enthält Informationen zu einem 'Auftrag', aber auch Informationen darüber, wer das Dokument verwalten darf. Das wird durch das Unterdokument 'Rolle' angezeigt. Hier dient die Information 'Rolle' zur Kontrolle des eigentlichen Dokuments. Dieser Ansatz hat den Nachteil, dass:

• Beibehaltung der Informationen, die sich auf den Kontrollteil des Dokuments beziehen, der keine Informationen über den "Auftrag" selbst enthält
• Um die Dokumente anhand von Kontrollinformationen zu suchen, ist die Anzahl der zu scannenden Dokumente proportional zur Anzahl der im System vorhandenen Dokumente
• Wenn das System vergrößert wird, kann dies zu Leistungsproblemen führen, da die Anzahl der zu durchsuchenden Dokumente ständig steigt.

Eine optimale Modellierung der Daten kann in diesem Szenario wie folgt betrachtet werden:

Order:
{
    'Type': "Sports",
    'SubType': "Tennis",
    'Item': "Racquet",
    'ItemSubType': 'Wide-Band',
    'Quantity': 1
}

RoleMapping:
{
    'Type': "OrderManagement",
    'SubType': "Sports",
    'OrderTYpe': {
        'Type':'Sports',
        'SubType':'Tennis'
    }
}

Hier wird das Dokument normalisiert, indem die Informationen, die sich auf die Kontrolle des Dokuments beziehen, in einem separaten Dokument gespeichert werden. Mit der darunter liegenden Funktion 'Indizierung' des Datenbanksystems können alle Auftragsdokumente des Typs 'Sport' und 'Tennis' für eine Benutzerrolle des Typs 'Auftragsverwaltung' und 'Sport' abgerufen werden; eine schnellere und direkte Suche nach den Dokumenten hat eine weitaus bessere Leistung im Vergleich zu einem früheren Datenmodell.

In diesem Szenario basierte das Wesen der Modellierung auf Daten, die sich selbst charakterisieren.

Unterdokumente und Arrays

MongoDB erwartet, dass die Arrays eine einheitliche Größe haben und ist nicht für ein kontinuierliches Wachstum eines Arrays geeignet. In Anbetracht dieser Tatsache ist das Einbetten von Dokumentenobjekten in ein anderes Dokument, das Einschließen von Dokumenten in ein Array keine optimale Designwahl, sondern die Normalisierung der Dokumente ist eine optimale Designwahl.

Fazit

• Je nach Bereich und Kontext der Datenverwaltung können verschiedene Techniken zur Modellierung der Daten eingesetzt werden, um eine optimale Leistung zu erzielen.
• Trennen Sie die Daten- und Steuerungsteile eines Dokuments, obwohl sie miteinander verbunden sind.
• Wenden Sie je nach Persona eine Normalisierung und/oder De-Normalisierung an.

For more insights, reach out to our team of MongoDB experts constantly engaged in improving management of various data systems. For more information, please visit –Contact us page