Vorhersage der Vorteile der Denormalisierung von Datenbanken

Mir wurde immer beigebracht, nach der höchsten Normalform der Datenbanknormalisierung zu streben, und uns wurde Bernsteins Synthesealgorithmus beigebracht , um 3NF zu erreichen. Dies ist alles sehr gut und es fühlt sich gut an, Ihre Datenbank zu normalisieren, da Sie wissen, dass Felder geändert werden können, während die Konsistenz erhalten bleibt.

Die Leistung kann jedoch leiden. Deshalb frage ich mich, ob es eine Möglichkeit gibt, die Beschleunigung / Verlangsamung beim Denormalisieren vorherzusagen. Auf diese Weise können Sie Ihre Liste der FDs mit 3NF erstellen und dann so wenig wie möglich denormalisieren. Ich stelle mir vor, dass zu viel Denormalisierung Platz und Zeit verschwenden würde, weil z. B. riesige Blobs dupliziert werden oder weil es schwieriger ist, die Konsistenz aufrechtzuerhalten, weil Sie mehrere Felder mithilfe einer Transaktion aktualisieren müssen.

Zusammenfassung: Wie kann ich bei einem 3NF-FD-Satz und einer Reihe von Abfragen die Beschleunigung / Verlangsamung der Denormalisierung vorhersagen? Link zu Papieren ebenfalls geschätzt.

Sie müssten die Datenflüsse zwischen den Tabellen kennen, um die Leistung des DB-Modells sehen zu können. Sobald Sie dies haben, können Sie die Leistungsänderung für eine bestimmte Denormalisierung berechnen (z. B. wenn Sie sich entscheiden, Daten zu duplizieren).

Einige grobe Schätzungen lassen sich daraus ableiten, wie viele neue Indizes Sie nach den Denormalisierungsschritten benötigen würden. Jeder neue Index muss separat aktualisiert und abgefragt werden, was zu einem Leistungseinbruch im Verhältnis zur Anzahl der neuen Indizes führt.

Große Blobs von Binärdaten sollten auf jeden Fall in einer separaten Tabelle gespeichert und nicht kopiert werden. Sie werden (normalerweise) nicht abgefragt, sondern als Teil der endgültigen Ergebnismenge nach einer Abfrage für eine andere Gruppe von Tabellen zurückgegeben.

Ich bin mir nicht sicher, ob es akademische Forschungen darüber gibt, wann Denormalisierung helfen kann (IMHO gibt es einen ziemlich großen Unterschied zwischen dem, was über DB-Normalisierung gelehrt wird, und der Funktionsweise in der Praxis).

Es gibt jedoch einige interessante Artikel und Blogeinträge zu diesem Thema. Jeff Atwood spricht in seinem Blog über Normalisierung , und es gibt eine "Antwort" auf ihn mit hoher Skalierbarkeit.

Ich schlage vor, dass Sie beim Denormalisieren darauf achten

• Anzahl und Art der Abfragen pro Zeiteinheit; Wenn Sie Insert und / oder Update mehr als Read verwenden, ist die Denormalisierung keine große Hilfe.
• Wie oft werden die duplizierten Informationen aktualisiert?
• die Eigenschaften des DBMS, das Sie verwenden werden
• Wie oft werden die Informationen dupliziert? Wenn Sie dieselben Informationen in 4-5 Tabellen haben, ist es möglicherweise schneller, sie in einer separaten Tabelle zu speichern, als sie so oft zu kopieren
• die erwartete Datenmenge, die in der Datenbank gespeichert ist; Was für kleine Datenmengen funktionieren könnte, kann zu einer Katastrophe führen, wenn die Anzahl der Datensätze zunimmt. Und umgekehrt (ich meine das KISS-Prinzip und nicht zu reparieren, was nicht kaputt ist).

Ich stelle mir vor, dass eine zu starke De-Normalisierung Raum und Zeit verschwenden würde

In den meisten mittelgroßen OLTP-Branchenanwendungen ist der Speicherplatz kein Problem. Lassen Sie also Platz. Mit der Zeit und mit der Zeit meine ich die Leistung der Abfrage, die normalerweise verbessert werden kann und kein echtes Problem verursacht, es sei denn, Sie haben ein schlechtes Design, unzureichende Ressourcen, eine extrem große Datenbank, eine sehr große Anzahl von Transaktionen oder alle obenstehendes. Die meisten Anwendungen, die heutige Datenbanken verwenden, haben selten ein Leistungsproblem, nur weil die Datenbank normalisiert ist.

Riesige Blobs werden dupliziert oder es ist schwieriger, die Konsistenz aufrechtzuerhalten, da Sie mehrere Felder mithilfe einer Transaktion aktualisieren müssen.

Durch die Normalisierung Ihrer Datenbank können Sie Folgendes sicherstellen:

1. Keine redundanten Daten.

2. Keine große Anzahl von Log-Enteritis verursacht werden (z. B. mit einer Tabelle von 2 Millionen Kunden: UPDATE Customer Set Country = "USA" WHERE Country = "US")

3. Vollständig unterstützt werden von SQL Queries. Dieser Punkt ist sehr wichtig.

4. Fährt sauberen Anwendungscode.

5. Erzwingen Sie ein hohes Maß an Datenkonsistenz über die Datenbank, ohne die Anwendung zu belasten.

6. Teilen Sie Geschäftsregeln, die in der Datenbank von verschiedenen Anwendungen definiert wurden, ohne denselben Code in verschiedenen Anwendungen zu codieren.

Die Normalisierung erzeugt jedoch eine optimale Struktur für alle Spalten und Tabellen. Dies ist möglicherweise nicht immer in Ihrer speziellen Anwendung erforderlich. Sie können dann aufgrund Ihres Verständnisses Ihrer Domain und Ihrer Anwendung festlegen, dass einige der Tabellen / Spalten als Kompromiss für die Geschwindigkeit de-normalisiert werden. Dies wäre jedoch eher eine bewusste Entscheidung als ein Versehen.

Wie kann ich bei einem 3NF-FD-Satz und einer Reihe von Abfragen die Beschleunigung / Verlangsamung der De-Normalisierung vorhersagen?

Sie können die Leistung ohne Tests nicht genau vorhersagen (was Sie tun können, bevor Sie den Anwendungscode schreiben). Sie können jedoch Faktoren eliminieren und erkennen, die aufgrund des Designs zu einer schlechten Leistung führen würden. Beispielsweise können Sie die zu verwendende Indexstrategie wie folgt identifizieren (andere Techniken können vorhanden sein):

1. Erstellen Sie eine Matrix mit Abfragen und Spalten, die von diesen Abfragen betroffen sind.

2. Suchen Sie die am häufigsten verwendeten Spalten.

3. Erwägen Sie, Indizes für diese Spalten zu erstellen.

Dies ist hauptsächlich ein Job, bei dem Ihr DBA Sie unterstützen kann. Leistung ist mehr als Normalisierung. Es gibt Aspekte der Datenverteilung über Datenträger, der vertikalen Tabellenaufteilung, der Partitionierung, der Indextypen und der Indexpufferung, um nur einige zu nennen. Alle diese Techniken sollten in Büchern und in der Herstellerdokumentation unter den Themen "Datenbankdesign" und "Datenbankleistungsoptimierung" behandelt werden. Bei der obigen Diskussion wird davon ausgegangen, dass es sich bei Ihrer Anwendung um eine OLTP-Anwendung handelt.

Einer der Hauptgründe für die Normalisierung ist die Optimierung für allgemeine Anwendungsfälle, während die Denormalisierung dazu neigt, die Leistung für spezielle Anwendungsfälle zu optimieren (mit erheblichen Strafen für andere Anwendungsfälle). Dies ist ein Grund, warum OLTP-Workloads normalerweise hauptsächlich von der Normalisierung profitieren (es gibt hier Ausnahmen, aber sie sind selten).

Um Vorteile vorhersagen zu können, müssen Sie wirklich wissen, was genau Sie denormalisieren und für welche Workflows. Es gibt auch Fragen zur Größe Ihres Datensatzes und zu den möglichen Auswirkungen des Caching. Die Antwort hängt wahrscheinlich von einer sehr großen Anzahl von Dingen ab, einschließlich der Datenbankgröße, dem Teil, der sich wahrscheinlich noch im Speicher befindet, dem Planungsaufwand für komplexe Abfragen und dergleichen. Dies ist eine sehr komplizierte, implementierungsspezifische Angelegenheit, die sehr stark von Ihrer Datenbank und Ihrem RDBMS abhängt. Diese Vorteile sind bei OLAP-Workloads am größten, und in der Regel sind die Nachteile bei OLTP-Workloads am größten.

Daher sehe ich hier keine einzige Antwort, außer Abfragepläne anzusehen und die Möglichkeit materialisierter Ansichten für denormalisierte Daten in Betracht zu ziehen. Meiner Ansicht nach besteht der beste Ansatz darin, die OLTP-Datenbank relativ zu normalisieren und sie nur zu Berichtszwecken zu Berichtszwecken zu denormalisieren.

Normalerweise normalisieren Sie Ihr Datenmodell, um die Leistung für einen bestimmten Anwendungsfall zu optimieren . Dies wirkt sich normalerweise nachteilig auf die Leistung anderer Anwendungsfälle aus. Das Wiederholen von Daten in mehreren Zeilen kann beispielsweise die Abfrageverarbeitung beschleunigen, indem ein Join entfernt wird. Die Aktualisierungsverarbeitung wird jedoch verlangsamt.

Tatsächlich bietet 3NF eine optimale Leistung für eine beliebige Anzahl beliebiger Zugriffe auf Ihre Datenbank. Für bestimmte Verknüpfungen und Auswahlen gibt es jedoch möglicherweise bessere Modelle.

Behandeln Sie die De-Normalisierung wie jede andere Optimierung. Das heißt, tun Sie es nur, wenn Sie tatsächlich ein Leistungsproblem haben, und stellen Sie sicher, dass Ihr "Fix" nicht mehr Probleme verursacht, als es löst.