Ich möchte wissen, welche spezifischen Probleme / Lösungen / Ratschläge / Best Practices [bestrafen mich für das Wort] entstehen, während Sie mit riesigen Datenbanken arbeiten.
Unter riesig implizieren ich Datenbanken, die Tabellen mit Millionen von Zeilen und / oder Datenbanken mit Petabyte Daten haben.
Plattformorientierte Antworten werden auch großartig sein.
Einige Ideen
Erfahren Sie die Details der spezifischen Datenbank-Engine, wie sie funktioniert
So optimieren Sie Abfragen (Hinweise, Ausführungspläne)
Wie Sie die Datenbank optimieren (nicht nur Indizes, sondern auch physische Speicherung und Darstellung, Betriebssystemintegration).
"Tricks" wie temporäre Tabellen abfragen, um temporäre Ergebnisse zu speichern, die wiederverwendet werden können,
Wie man die Notwendigkeit der Denormalisierung zur Leistungsverbesserung bewertet
Wie Sie Profiling-Tools für die Datenbank verwenden, um die Engpässe zu identifizieren.
Ein paar Ratschläge von einem Produktions-DBA (meine Erfahrung ist MS SQL, aber diese sollten für andere Plattformen gelten):
Die Wartung wird zu einem bedeutenden Problem (nächtliche Backups, DBCCs, wöchentliche Neuindex / Optimierungsjobs usw.). Sehr einfach zu Beginn eines angemessenen Nacht- oder Wochenendwartungsfensters. Dies ist nicht nur ein technisches Problem, sondern auch ein Geschäfts Problem ("Was meinst du, es wird 4 Stunden dauern, um die Datenbank aus dem letzten guten Backup wiederherzustellen ? ")
Entwickler müssen verstehen, dass sie möglicherweise anders arbeiten müssen. "Sie meinen, ich kann nicht nur DELETE (500m rows) FROM MassiveTable und erwarten, dass es funktioniert?
Ich bin sicher, ich denke an mehr ...
Mein erster Rat wäre, jemanden einzustellen, der weiß, was er tut und sich nicht auf SO verlässt, sonst könnten Sie extrem teure Fehler machen. Meine zweite wäre, die richtige Plattform Hardware und Software zu wählen. Die Details werden sehr von den Anforderungen abhängen.
Jedes RDBMS kann unter einer schlechten Leistung leiden, wenn es sehr groß wird, insbesondere wenn komplexe Join-Bedingungen verwendet werden. Datenbankschemas müssen auch für große Datenmengen skaliert werden. Die meisten Systeme sind ziemlich gut im Umgang mit Lasten, aber Sie können auch Probleme bekommen, wenn Sie eine Datenbank haben, die auf mehrere Maschinen verteilt werden muss.
Viele neue Tools tauchen auf, um mit der Datenbank-Skalierbarkeit fertig zu werden. Eines der vielversprechendsten ist Memcached, das eine große Menge an Daten im Speicher speichert, was einen viel schnelleren Zugriff ermöglicht und die Synchronisation zwischen mehreren Datenbankservern erleichtert. Einige der NoSQL-Lösungen, die traditionelle SQL-Systeme um Architekturen erweitern, die keine Schemata erzwingen.
Einige Beispiele für NoSQL-Technologien sind Cassandra, CouchDB, Google BigTable und MongoDB. Einige Leute schwören, dass diese Systeme bei der Bewältigung der "kommenden Datenexplosion" von entscheidender Bedeutung sein werden.
Es gibt zwei Aspekte einer Datenbank, die wichtiger sind als die Größe, was Design und Verwaltung betrifft.
Die erste ist Komplexität. Wie viele Benutzertabellen gibt es? Wie viele Spalten in diesen Tabellen? Eine Datenbank mit mehreren hundert Benutzertabellen im Schema und mehr als tausend Spalten in diesen Tabellen ist sehr komplex. Eine Datenbank mit einem halben Dutzend Tabellen ist nicht sehr komplex, selbst wenn sie Petabyte an Daten enthält.
Der zweite ist der Umfang der gemeinsamen Nutzung von Daten. Wenn eine Datenbank für die gemeinsame Nutzung von Daten zwischen sechs oder mehr Anwendungen erstellt wird, die von separaten Programmierteams entwickelt wurden, sollten Sie sie sehr anders entwerfen und verwalten als eine Datenbank, die in einer einzigen Anwendung eingebettet ist.
Die meisten der in SO gestellten Datenbankfragen beziehen sich auf einzelne Anwendungsdatenbanken.
Hier sind ein paar Dinge zu lernen, zusätzlich zu dem, was bereits erwähnt wurde.
Erfahren Sie den Unterschied zwischen Tabellenpartitionierung und Tabellenzerlegung. Einige Leute zerlegen Tabellen in mehrere Tabellen mit denselben Spalten, wenn die Partitionierung ihnen besser dienen würde.
Lernen Sie den wahren Unterschied zwischen dem Graphenmodell der Daten und dem relationalen Modell der Daten kennen. Manche Leute entwerfen Datenbanken so, als wären fremde Schlüssel im Wesentlichen dieselben wie Zeiger. Am Ende steht ein System, das die Langsamkeit eines relationalen Systems und die Unkontrollierbarkeit eines Graphensystems erfasst.
(Hinweis: Das Graphenmodell wird oft als hierarchisches oder Netzwerkmodell bezeichnet).
Das Entwerfen einer echten relationalen Datenbank ist viel subtiler und viel lohnender als das Entwerfen einer Datenbank, die vorgibt, relational modelliert zu werden, aber tatsächlich grafisch modelliert ist.
Tags und Links sql database database-design bigdata