In einem kürzlichen Projekt entwickelte der "Lead" -Entwickler ein Datenbankschema, in dem "größere" Tabellen auf zwei getrennte Datenbanken mit einer Sicht auf die Hauptdatenbank aufgeteilt wurden, die die zwei getrennten Datenbanktabellen miteinander vereinte. Die Hauptdatenbank ist, woraus die Anwendung entfernt wurde, so dass diese Tabellen wie gewöhnliche Tabellen aussahen und sich so anfühlten (außer einigen eigenartigen Dingen bei der Aktualisierung). Dies schien wie ein riesiges Leistungsproblem. Wir sehen Probleme mit der Leistung an diesen Tischen, aber nichts, was ihn dazu bringen könnte, seine Meinung über sein Design zu ändern. Frage mich nur, was ist der beste Weg, dies zu tun, oder wenn es sich lohnt, es zu tun?Was ist der beste Weg, um große Tabellen in SQL Server zu partitionieren?
Antwort
Ich denke nicht, dass Sie wirklich etwas gewinnen werden, indem Sie die Tabelle auf mehrere Datenbanken auf einem einzigen Server verteilen. Alles, was Sie im Wesentlichen dort getan haben, erhöht den Overhead beim Arbeiten mit der "Tabelle" an erster Stelle, indem mehrere Instanzen (d. H. In zwei verschiedenen DBs geöffnet) unter einer einzigen SQL Server-Instanz vorhanden sind.
Wie groß von einem Datensatz haben Sie? Ich habe einen Client mit einer 6 Millionen Zeilen-Tabelle in SQL Server, die 2 Jahre Umsatzdaten enthält. Sie verwenden es transaktional und für die Berichterstattung ohne nennenswerte Geschwindigkeitsprobleme.
Die Abstimmung der Indizes und die Auswahl des richtigen Clustered-Index ist natürlich für die Leistung von entscheidender Bedeutung.
Wenn Ihr Dataset sehr groß ist und Sie nach einer Partition suchen, erhalten Sie mehr Geld für die Partitionierung der Tabelle auf physischen Servern.
Welche Version von SQL Server verwenden Sie? SQL Server 2005 verfügt über partitionierte Tabellen, aber in 2000 (oder 7.0) mussten Sie Partitionsansichten verwenden.
Auch, was war der Grund für die Tabellenpartitionen in einer separaten Datenbank?
Wenn ich Tabellen in der Vergangenheit (vor 2005) partitionieren musste, ist es in der Regel durch eine Datumsspalte oder etwas ähnliches, mit einer Ansicht über die verschiedenen Partitionen. In der Onlinedokumentation gibt es einen Abschnitt, in dem darüber gesprochen wird, wie dies zu tun ist und welche Regeln dabei gelten. Sie müssen die Regeln befolgen, damit es funktioniert, wie es funktionieren soll.
Das Wichtigste, das Sie beachten sollten, ist, dass Ihre Partitionierungsspalte Teil des Primärschlüssels sein muss und Sie versuchen möchten, diese Spalte bei jedem Zugriff auf die Tabelle zu verwenden, damit das Optimierungsprogramm Partitionen ignorieren kann, die nicht betroffen sein sollen durch die Abfrage.
Suchen Sie nach "partitionierte Tabelle" in MSDN und Sie sollten in der Lage sein, ein vollständigeres Lernprogramm für partitionierte SQL Server 2005-Tabellen sowie Ratschläge zum Einrichten für maximale Leistung zu finden.
Fragen Sie nach Best Practices in Bezug auf das Datenbankdesign oder überzeugen Sie sich davon, Ihre Meinung zu ändern? :)
In Bezug auf Design ... Zurück in den alten Zeiten, manchmal vertikale Partitionierung wurde benötigt, um Datenbank-Engines zu umgehen, wo die Anzahl der Spalten in einer Tabelle war eine harte Grenze, wie 255 Spalten. Heutzutage sind die Hauptvorteile rein für die Leistung: selten verwendete Spalten oder Blobs auf einem separaten Disk-Array zu platzieren. Aber wenn Sie regelmäßig Dinge von beiden Tischen ziehen, wird es wahrscheinlich ein Verlust sein. Es klingt so, als ob Ihr Lead an einer vorzeitigen Optimierung leidet.
In Bezug auf die Angabe Ihrer Führung ist falsch ... das erfordert Diplomatie. Wenn er in Bezug auf die Leistung auf Unmut murmelt, ist ein Benchmark wahrscheinlich der beste Weg, den Unterschied zu zeigen.
Erstellen Sie eine neue physische Tabelle mit 'create table t1' als * from view1 'und führen Sie einen längeren Batch mit der vertikal partitionierten Tabelle und Ihrer neuen Tabelle aus. Wenn es so schlimm ist wie du sagst, sollte der Unterschied offensichtlich sein.
Aber auch dies kann vorzeitige Optimierung sein. Finden Sie heraus, was die Endnutzer von der Leistung halten. Wenn die Leistung gut genug ist, um etwas Gutes zu definieren, dann repariere nicht, was nicht kaputt ist.
Die Partitionierung sollte nicht leichtfertig vorgenommen werden, da es viele subtile Auswirkungen auf die Leistung geben kann.
Meine erste Frage lautet, beziehen Sie sich einfach auf größere Tabellenobjekte in separaten Dateigruppen (auf separaten Spindeln) oder beziehen Sie sich auf Datenpartitionierung innerhalb eines Tabellenobjekts?
Ich vermute, dass die beschriebene Situation ein Versuch ist, den physischen Speicher bestimmter großer Tabellen auf verschiedenen Spindeln aus dem Rest der Tabellen zu haben. In diesem Fall bietet das Hinzufügen des zusätzlichen Overheads separater Datenbanken, der Verlust der Fähigkeit, die referenzielle Integrität zwischen Datenbanken zu erzwingen, und die Sicherheitsimplikationen beim Aktivieren der cross-data-Besitzverkettung keinen Vorteil gegenüber der Verwendung mehrerer Dateigruppen in einer einzelnen Datenbank. Wenn, wie es durchaus möglich ist, die separaten Datenbanken, auf die Sie in Ihrer Frage verweisen, nicht einmal auf separaten Spindeln gespeichert sind, sondern alle auf derselben Spindel gespeichert sind, negieren Sie sogar den geringen Leistungsvorteil, den Sie durch physische Trennung Ihrer Festplattenaktivität erhalten hätten habe absolut keinen Nutzen erhalten.
Ich würde vorschlagen, statt zusätzliche Datenbanken zu verwenden, um große Tabellen zu halten Sie in der Dateigruppenthema in SQL Server-Onlinedokumentation oder für eine kurze Überprüfung finden Sie in diesem Artikel: http://www.mssqltips.com/tip.asp?tip=1112.
Wenn Sie an Datenpartitionierung interessiert sind (einschließlich Partitionierung in mehrere Dateigruppen), empfehle ich Artikel von Kimberly Tripp zu lesen, der zu der Zeit, als SQL Server 2005 über die dort verfügbaren Verbesserungen bekannt wurde, eine hervorragende Präsentation hielt. Ein guter Ausgangspunkt ist dieses Whitepaper: http://www.sqlskills.com/resources/Whitepapers/Partitioning%20in%20SQL%20Server%202005%20Beta%20II.htm.
Ich würde nicht mit der Annahme übereinstimmen, dass nichts durch Partitionierung gewonnen werden kann.
Wenn die Partitionsdaten physikalisch und logisch ausgerichtet sind, sollte die potenzielle IO von Abfragen drastisch reduziert werden.
Zum Beispiel: Wir haben eine Tabelle, die Batch-Feld als INT hat, die eine INT darstellt.
Wenn wir die Daten durch dieses Feld partitionieren und dann eine Abfrage für eine bestimmte Charge erneut ausführen, sollten wir in der Lage sein Set-Statistiken laufen io ON vor als auch nach der Partitionierung und eine Verringerung der IO sehen,
Wenn Wir haben eine Million Zeilen pro Partition und jede Partition wird auf ein separates Gerät geschrieben. Die Abfrage sollte in der Lage sein, die nicht essentiellen Partitionen zu eliminieren.
Ich habe nicht viel Partitionierung auf SQL Server, aber ich habe Erfahrung mit der Partitionierung auf Sybase ASE, und dies ist bekannt als Partition Eliminiation. Wenn ich Zeit habe, werde ich das Szenario auf einem SQL Server 2005-Rechner testen.
Ich kann nicht sehen, wie Partitionierungstabelle für Stapelfeld weniger IO verursachen würde. Wenn Stapel Teil von richtigen Indizes ist, reduziert es die Anzahl der Zeilen, die unabhängig von der Partitionierung gelesen werden müssen. Jetzt ist IO eine Funktion von Datenzeilen, die gelesen werden müssen. Wie verbessert Partitionierung alles? –
Wie Partitionierungstabelle zwischen mehreren physischen Geräten ist besser als die Konfiguration der Dateigruppe, die diese Geräte umfasst, wie Joe Kuemerle vorschlägt? Ich verstehe, dass es in einigen sehr spezifischen Situationen effizienter sein kann, sie manuell einzurichten. Aber ist es nicht eine sehr außergewöhnliche Situation? Ich denke, normalerweise ist es günstiger, ein größeres RAID zu kaufen, als wenn Entwickler und Datenbankadministratoren viel Zeit damit verbringen, Tabellen zu verschieben. –
Es gibt eindeutige Vorteile für die Tabellenpartitionierung (unabhängig davon, ob es sich um dieselben oder verschiedene Dateigruppen/Festplatten handelt). Wenn die Partitionsspalte korrekt ausgewählt ist, werden Sie feststellen, dass Ihre Abfragen nur die erforderliche Partition betreffen.Stellen Sie sich vor, Sie hätten 100 Millionen Datensätze (ich habe Tabellen sehr viel stärker partitioniert - etwa 20+ Milliarden Zeilen) und wenn mehr als 70% Ihres Datenzugriffs nur eine bestimmte Kategorie, Zeitleiste oder Art von Daten sind dann hilft es, die am meisten zugegriffenen Daten in einer separaten Partition zu behalten. Außerdem können Sie die Partition mit verschiedenen Dateigruppen mit verschiedenen Arten von Festplatten (SATA, Fibre Channel, SSDs) ausrichten, so dass die am meisten zugegriffen/beschäftigt Daten auf dem schnellsten Speicher und die am wenigsten/selten zugegriffen werden, sind praktisch auf langsameren Festplatten.
Obwohl in SQL Server gibt es im Gegensatz zu Oracle begrenzt Partitionierungsfunktion. Sie können nur eine Spalte für die Partitionierung auswählen (auch in SQL 2008). Sie müssen also eine Spalte sinnvoll auswählen, in der diese Spalte auch zu den meisten Ihrer häufigen Abfragen gehört. Die meisten Leute finden es einfach, die Partitionierung durch eine Datumsspalte zu wählen. Obwohl es logisch erscheint, auf diese Weise zu partitionieren, werden Sie, wenn Ihre Abfragen diese Spalte nicht als Teil der Bedingung haben, nicht genügend Vorteile aus der Partitionierung ziehen (mit anderen Worten, Ihre Abfrage wird die gesamte Partition unabhängig treffen).
Die Partitionierung für Datawarehouse-/Data Mining-Datenbanken ist wesentlich einfacher als bei OLTP, da die meisten DW-Datenbankabfragen zeitlich begrenzt sind.
Aus diesem Grund ist es heutzutage aufgrund der Menge an Daten, die von Datenbanken gehandhabt werden, sinnvoll, die Anwendung so zu gestalten, dass jede Anfrage durch eine breitere Gruppe wie Zeit, geografische Position oder dergleichen eingeschränkt wird Spalten für die Partitionierung ausgewählt werden, erhalten Sie maximale Vorteile.
SQLTeam.com hatte auch kürzlich Beiträge über Partitionierung und Automatisierung der Wartung: http://weblogs.sqlteam.com/. –