Datenbank Tabellen Vervielfältigungsrichtlinien

Question

Ich habe einen konstanten Datenfluss. Alle Daten müssen mit einem Zeitstempel in der Datenbank gespeichert werden. Die Daten stammen in einem 5-Minuten-Schritten und eine ausgewählte der neuesten Daten in dem gleichen Intervall, in Pseudo-SQL-Code gemacht:

SELECT * FROM TB_TABLE WHERE TIMESTAMP = MAX(TIMESTAMP) 

Wie diese Tabelle wächst wirklich groß (Gigabyte), habe ich eine vorzeitige Optimierung Aufteilen in zwei Tabellen: eine für alle Daten (nur für Einfügungen) und eine für die neuesten Daten (für Einfügungen, löschen und auswählen).

Ich frage mich, ob diese Duplizierung ist eine gute Sache zu tun, da ich keine Metriken zu beweisen, dass es meine Anwendungsleistung verbessert hat. Würden Sie als allgemeine Richtlinie empfehlen, was ich getan habe?

aktualisiert BTW verwende ich MS SQL Server 2005 und .NET C# Linq to SQL-

Answer 1

Ich frage mich, ob Tabellen Partitionierung hilfreich wäre. Ich habe es nicht persönlich benutzt, kann also nicht aus Erfahrung sprechen, aber das klingt nach der geeigneten Situation, in der man es benutzen kann.

Answer 2

Splitting Tabellen mit einem hohen Eingangsvolumen in einen Schreiboptimierte „jüngsten“ Tisch und ein Lese optimiert „Archiv“ Tabelle ist im Allgemeinen eine ziemlich gute Optimierung. Es erhöht die Komplexität, also wollen Sie es nicht dort tun, wo es nicht benötigt wird, aber es ist vernünftig, wenn Sie sicher sind, dass die fragliche Tabelle Tonnen von Daten erhalten wird.

Answer 3

Ich würde den Ansatz, den Sie genommen haben, nicht empfehlen. Wenn es darum ging, die Anwendungsleistung zu verbessern, wäre es zweckmäßiger gewesen, zunächst Leistungsmetriken zu sammeln. Wenn ein Trend eine abnehmende Leistung anzeigt, wenn die Datenmenge wächst, wäre es klar, dass eine Änderung der Datenbank angemessen ist.

Angenommen, Ihr Hauptanliegen ist die Leistung von SELECTs für eine große Tabelle. Schritte wie das Anwenden guter Indizes und das Ersetzen von "select *" mit den gewünschten Spalten sind möglicherweise besser geeignet als das Duplizieren von Daten über mehrere Tabellen hinweg. Wenn Ihre Abfragen eine erhebliche Anzahl von Joins enthalten, kann sich dies negativ auf Ihre Leistung auswirken. In diesem Fall wäre das Erstellen einer zusätzlichen Tabelle, die die Notwendigkeit von Joins in Ihren Abfragen überflüssig macht, eine gute Optimierung.

Answer 4

Sie haben nicht erwähnt, welche Datenbank Sie verwenden, aber ich kann mir ein paar mögliche schnelle Optimierungen vorstellen. Wie viele Gigabyte reden wir?

1) Das Berechnen des Maximums (Zeitstempel) kann bei einer großen Anzahl von Zeilen teuer sein. Sie wissen wahrscheinlich bereits, was dieser Wert ist, speichern Sie ihn in einer anderen Tabelle oder einer Konfigurationsdatei oder so. Dies wird wahrscheinlich Ihre größte Optimierung sein.

2) Fügen Sie eine weitere Spalte hinzu, um die letzten Aktualisierungen zu kennzeichnen. Wenn Sie Ihr Update starten SET recent = false WHERE recent = true, schreiben Sie alle Ihre Datensätze mit recent = true. Sie können möglicherweise die Größe Ihres Indexes einschränken, indem Sie ihm eine Where-Bedingung hinzufügen CREATE INDEX foo_index auf "TB_TABLE" (recently) WHERE recent = true;

3) Stellen Sie sicher, dass Ihr Datenbankserver ordnungsgemäß optimiert ist. Stellen Sie sicher, dass Ihre Schlüssel- und Sortierpuffer für die Datenmenge geeignet sind. Die meisten Open-Source-Datenbanken sind für die Workstation eines Entwicklers voreingestellt und nicht für die Produktion.

4) Überdenken Sie Ihr Schema. Sind Sie sicher, dass Sie alle Ihre Unterlagen benötigen? Erfassen Sie alle Daten und nicht nur die geänderten Daten? Ich habe zwei Zeitstempel in dieser Situation gut genutzt, einen Zeitstempel für den letzten Ladevorgang und einen Zeitstempel für den letzten Wechsel.