SQL Server-Datenbank auf einer SSD - ein Vorteil gegenüber einer separaten Datei für jede Tabelle?

19

Ich erstelle eine Datenbank mit etwa 30 Tabellen, wobei jede Tabelle zig Millionen Zeilen und jede Tabelle eine einzelne wichtige Spalte und eine Primär- / Fremdschlüsselspalte enthält, um die Abfrageeffizienz angesichts hoher Anforderungen zu maximieren Aktualisierungen und Einfügungen sowie häufige Verwendung von Clustered-Indizes. Zwei der Tabellen enthalten Textdaten variabler Länge, von denen eine Hunderte Millionen Zeilen enthält, der Rest jedoch nur numerische Daten.

Da ich wirklich den letzten Tropfen der verfügbaren Hardware (etwa 64 GB RAM, eine sehr schnelle SSD und 16 Kerne) ausnutzen möchte, habe ich mir überlegt, jeder Tabelle eine eigene Datei zuzuweisen, egal ob Ich verbinde auf 2, 3, 4, 5 oder mehr Tabellen, jede Tabelle wird immer mit einem separaten Thread gelesen und die Struktur jeder Datei wird eng mit dem Tabelleninhalt abgestimmt, was hoffentlich die Fragmentierung minimieren und schneller machen würde für SQL Server zum Inhalt einer beliebigen Tabelle hinzufügen.

Eine Einschränkung, ich bin auf SQL Server 2008 R2 Web Edition stecken . Das heißt, ich kann die automatische horizontale Partitionierung nicht verwenden, was eine Leistungssteigerung ausschließt.

Maximiert die Verwendung einer Datei pro Tabelle tatsächlich die Leistung, oder übersehen ich die Eigenschaften des integrierten SQL Server-Moduls, die dies überflüssig machen würden?

Zweitens, wenn die Verwendung einer Datei pro Tabelle von Vorteil ist, warum kann create tableich die Tabelle dann nur einer Dateigruppe und nicht einer bestimmten logischen Datei zuordnen? In diesem Fall müsste ich für jede Datei in meinem Szenario eine eigene Dateigruppe erstellen, was darauf hindeutet, dass SQL Server möglicherweise nicht die Vorteile sieht, von denen ich annehme, dass sie sich aus dem ergeben, was ich vorschlage.

— Nathan Ridley
quelle

18

Ich habe darüber nachgedacht, jeder Tabelle eine eigene Datei zu erlauben, damit, egal ob ich an 2, 3, 4, 5 oder mehr Tabellen beitrete, jede Tabelle immer mit einem separaten Thread gelesen wird und die Struktur jeder Datei eng an den Tabelleninhalten ausgerichtet sein, was hoffentlich die Fragmentierung minimieren und es für SQL Server beschleunigen würde, den Inhalt einer bestimmten Tabelle zu ergänzen

Wovon zur Hölle redest du? Sie sind sich nicht sicher, woher Sie Ihre Informationen haben, aber Sie sollten diese Quelle unbedingt verwerfen. Nichts von dem, was Sie hier vermuten, ist tatsächlich richtig.

Wenn Sie eine gute Diskussion über die SSD-Leistung für SQL Server lesen möchten, gibt es mehrere Blogserien. Wie immer ist Paul Randals die beste Wahl:

Brent hat auch eine schöne Präsentation zum Thema: SQL auf SSDs: Hot and Crazy Love und es gibt mehr da draußen.

Wenn Sie all diese Präsentationen durchgehen, werden Sie schnell bemerken, dass sich alle auf das Schreiben konzentrieren, da hier die Leistung von SSDs zum Tragen kommt. In Ihrem Posting geht es fast ausschließlich um das Lesen, was ein anderes Thema ist. Wenn Lesevorgänge Ihr Problem sind, sollten Sie über RAM sprechen, nicht über SSDs, und über geeignete Indizierungs- und Abfragestrategien.

— Remus Rusanu
quelle

1

Ja, ich habe irgendwo auf der Strecke die falschen Informationen erhalten, aber wie ich auf Stuarts Antwort eingegangen bin, habe ich die Frage gestellt, um sicherzustellen, dass ich meine Entscheidungen nicht auf falschen Informationen beruhte. Vielen Dank für die Links, ich werde sie überprüfen.

17

Mein erster Vorschlag wäre, keine Annahmen über die Leistung zu treffen, ohne Lasttests für beide Konfigurationen durchzuführen.

Wenn ich in der Vergangenheit solche Konfigurationen gesehen hätte (die auf dem Papier sinnvoll sind), hätte das vermutlich keine messbaren positiven Auswirkungen auf die Leistung, wenn jede Tabelle in einer separaten Datei enthalten wäre. Die zusätzliche Komplexität würde alle Leistungssteigerungen ausgleichen auch wenn sie messbar wären.

Zum Schluss verweise ich Sie auf die folgende Tabelle, wenn es darum geht, jeden Leistungsabfall aus einem SQL Server herauszuholen:

Bildbeschreibung hier eingeben

Potenzielle Optimierungen, die aus Sicht der Anwendung vorgenommen werden könnten, stellen mögliche Optimierungen auf Hardware- / Datenbankkonfigurationsebene in den Schatten.

— Michael Fredrickson
quelle

Na sicher. In meinem Fall habe ich das gesamte System so weit wie möglich optimiert, und der derzeitige primäre Engpass sind sehr schnelle Abfragegeschwindigkeiten angesichts häufiger Aktualisierungen, Löschungen und Einfügungen. Da ich SQL Server einsetzen werde, um dieses Problem zu lösen, möchte ich sicherstellen, dass es die bestmögliche Chance bietet, meine Daten so schnell wie möglich zu verarbeiten.

@ NathanRidley Ok, verstanden ... Ich denke, die eigentliche Antwort ist, wenn nicht jemand über eine Ressource verfügt, die sagt: "Mach das nie", dass die beste Vorgehensweise darin besteht, zwei Konfigurationen mit deiner typischen Arbeitsbelastung zu vergleichen und festzustellen, ob es einen messbaren Unterschied gibt.

— Michael Fredrickson

4

Wie andere angemerkt haben, gibt es keinen direkten Nutzen aus einer Datei pro Tabelle. Hier ist eine großartige Zusammenfassung von Steve Jones, wie dieser Mythos entstand: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

Möglicherweise möchten Sie auch eine partitionierte Ansicht untersuchen, die meines Erachtens von der 2008 Web Edition unterstützt wird. Es gibt einige Tricks beim Codieren mit einer partitionierten Ansicht, aber Sie können einen Großteil der Funktionalität partitionierter Tabellen relativ einfach nachahmen.

— Stuart Ainsworth
quelle

2

Ich denke, dass separate Dateien für jede Tabelle keinen Leistungsvorteil bringen würden. Die richtigen Indizes können eine potenzielle Leistungssteigerung (Datenträgerlesung) auf dem Datenbankserver aufweisen.

Unterstützt der SQL Server 2008 R2 die Komprimierung? Wenn ja, schalten Sie das ein.

Korrigiere mich, wenn ich falsch liege.

— Peter Kiss
quelle

Können Sie erläutern, warum es keinen Leistungsvorteil gibt? Erklären Sie zumindest, warum dies der Fall ist, wenn SQL Server in separaten Dateien mehrere Threads zum Lesen verwenden kann.

Wenn Sie alle Tabellen in einer eigenen Dateigruppe, aber auf demselben Laufwerk ablegen, ist die Leistung vor der Partitionierung gleich. Wenn Sie jedoch einige Tabellen auf einer anderen schnelleren Festplatte in ihre Dateigruppen aufteilen, hat dies einen Leistungsvorteil. Sie können beispielsweise auch nach Jahr partitionieren, wenn Sie viele Daten haben, die vom Jahr abhängen. Mit dieser Technik können Sie Ihre am häufigsten verwendeten Daten auf einer schnelleren Festplatte speichern als die alten. Sie können Indizes auch trennen, aber nur, wenn Sie sie auf eine neue physische Festplatte legen, hat dies einen Leistungsvorteil.

Sie haben Recht mit den parallelen Threads (Tabellen / Dateien), aber ich denke, bis Sie nur eine physische Festplatte haben, wird der Leistungsgewinn gering sein.

Und ich empfehle Ihnen, ein starkes Festplatten-RAID-Array für die Datenbank zu erwerben, da die SSD bald abstirbt.