Normalisieren oder Denormalisieren bei stark frequentierten Websites

Question

Was sind die besten Praktiken für Datenbankdesign und Normalisierung für stark frequentierte Websites wie stackoverflow?

Sollte man eine normalisierte Datenbank für die Aufzeichnung oder eine normalisierte Technik oder eine Kombination aus beidem verwenden?

Ist es sinnvoll, eine normalisierte Datenbank als Hauptdatenbank für die Datenspeicherung zu konzipieren, um Redundanz zu vermeiden, und gleichzeitig eine andere, denormalisierte Form der Datenbank für die schnelle Suche zu unterhalten?

o

Sollte die Hauptdatenbank denormalisiert werden, aber mit normalisierten Ansichten auf der Anwendungsebene für schnelle Datenbankoperationen?

oder ein anderer Ansatz?

Answer 1

Der Leistungsverlust durch das Zusammenführen wird häufig überschätzt. Datenbankprodukte wie Oracle sind darauf ausgelegt, sehr effizient zu verbinden. Joins werden oft als leistungsschwach angesehen, obwohl der wahre Schuldige ein schlechtes Datenmodell oder eine schlechte Indizierungsstrategie ist. Es wird auch vergessen, dass denormalisierte Datenbanken beim Einfügen oder Aktualisieren von Daten sehr schlecht abschneiden.

Das Wichtigste ist die Art der Anwendung, die Sie entwickeln. Die meisten bekannten Websites sind nicht wie normale Unternehmensanwendungen. Aus diesem Grund verwenden Google, Facebook usw. keine relationalen Datenbanken. In letzter Zeit wurde viel über dieses Thema diskutiert, das Ich habe gebloggt über .

Wenn Sie also eine Website erstellen, bei der es in erster Linie darum geht, Unmengen an halbstrukturierten Inhalten bereitzustellen, sollten Sie wahrscheinlich keine relationale Datenbank verwenden, egal ob denormalisiert oder nicht. Wenn Sie jedoch eine Website mit hohem Transaktionsvolumen erstellen (z. B. eine Online-Bank), brauchen Sie ein Design, das die Sicherheit und Integrität der Daten gewährleistet, und zwar auf eine gute Art und Weise. Das bedeutet eine relationale Datenbank in mindestens dritter Normalform.

Answer 2

Die Denormalisierung der Datenbank, um die Anzahl der für intensive Abfragen erforderlichen Joins zu reduzieren, ist eine von vielen verschiedenen Möglichkeiten der Skalierung. Weniger Joins bedeuten weniger Arbeit für die Datenbank, und Festplatten sind billig.

Abgesehen davon ist eine gute Leistung der relationalen Datenbank bei lächerlichen Mengen an Datenverkehr schwer zu erreichen. Aus diesem Grund verwenden viele größere Websites Key-Value-Stores (z. B. Memcached) und andere Caching-Mechanismen.

Die Kunst der Kapazitätsplanung ist ziemlich gut.

Answer 3

Erstens: Definieren Sie für sich selbst, was starker Verkehr bedeutet:

• 50.000 Page-Views pro Tag?
• 500.000 Seitenaufrufe pro Tag?
• 5.000.000 Seitenaufrufe pro Tag?
• mehr?

Berechnen Sie dann die wahrscheinlichen Spitzenwerte der Seitenaufrufe pro Minute und pro Sekunde. Überlegen Sie dann, welche Daten Sie pro Seitenaufruf abfragen wollen. Sind die Daten cachefähig? Wie dynamisch sind die Daten, wie groß ist der Datenbestand?

Analysieren Sie Ihre individuellen Anforderungen, programmieren Sie etwas Code, führen Sie einige Lasttests durch, optimieren Sie. In den meisten Fällen müssen Sie erst die Webserver skalieren, bevor Sie die Datenbankserver skalieren können.

Relationale Datenbanken können, wenn sie vollständig optimiert sind, erstaunlich schnell sein, wenn sie Tabellen verbinden!

Eine relationale Datenbank kann nur selten als Back-End genutzt werden, um einen Cache zu füllen oder einige denormalisierte Datentabellen zu füllen. Ich würde die Denormalisierung nicht zum Standardansatz machen.

(Sie erwähnten die Suche, schauen Sie sich z.B. lucene oder etwas Ähnliches an, wenn Sie eine Volltextsuche benötigen).

Das Beste Best-Practice-Antwort ist definitiv: Es kommt darauf an ;-)

Answer 4

Sie können sich eine Diskussion zu diesem Thema von den Machern von Stack Overflow in ihrem Podcast anhören:
http://itc.conversationsnetwork.org/shows/detail3993.html

Answer 5

Bei einem Projekt, an dem ich arbeite, haben wir uns für den Weg der denormalisierten Tabellen entschieden, da wir erwarten, dass unsere Haupttabellen ein hohes Verhältnis von Schreibvorgängen zu Lesevorgängen aufweisen (statt dass alle Benutzer auf dieselben Tabellen zugreifen, haben wir sie denormalisiert und jeden "Benutzersatz" so eingestellt, dass er einen bestimmten Shard verwendet). Sie finden vielleicht read http://highscalability.com/ für Beispiele, wie die "großen Sites" mit dem Volumen umgehen - Stapelüberlauf wurde kürzlich vorgestellt.