Leistungstests einer Greenfield-Datenbank

Question

Unter der Annahme, dass die Best Practices beim Entwurf einer neuen Datenbank befolgt wurden, wird die Datenbank so getestet, dass das Vertrauen in die Fähigkeit der Datenbank, angemessene Leistungsstandards zu erfüllen, verbessert wird leistungssteigernde Optimierungen an der Datenbankstruktur, wenn sie benötigt werden?

Benötige ich Testdaten? Wie sieht das aus, wenn für die Datenbank noch keine Nutzungsmuster festgelegt wurden?

HINWEIS: Ressourcen wie Blogposts und Buchtitel sind willkommen.

Answer 1

Sie könnten ein Tool wie RedGate's Data Generator verwenden, um eine gute Menge von Testdaten zu erhalten, um zu sehen, wie das Schema unter Last funktioniert. Sie haben recht, dass es ohne den Umgang mit den Verwendungsmustern schwierig ist, einen perfekten Testplan zusammenzustellen, aber ich nehme an, dass Sie eine ungefähre Vorstellung davon haben müssen, welche Art von Abfragen dagegen ausgeführt werden.

Angemessene Leistungsstandards werden durch die spezifischen Client-Anwendungen definiert, die Ihre Datenbank verbrauchen. Holen Sie sich einen SQL-Profiler-Trace, während die Anwendungen Ihre Datenbank erreichen, und Sie sollten in der Lage sein, alle Problembereiche schnell zu erkennen, die möglicherweise mehr Optimierung benötigen (oder in einigen Fällen sogar eine De-Normalisierung).

Answer 2

Ich würde ein paar Dinge tun:

1) Benutzer/Anwendungsverbindung mit dem db und Testlast (Lasttests) simulieren. Ich würde vorschlagen, mit viel mehr Benutzern zu verbinden, als erwartet werden, das System tatsächlich zu verwenden. Sie können sich von allen Benutzern anmelden oder Software von Drittanbietern verwenden, die viele Benutzer anmelden und definierte Funktionen ausführen, von denen Sie glauben, dass sie ein angemessener Test für Ihr System sind.

2) viele (möglicherweise Millionen) Testdatensätze einfügen und Test erneut laden (Skalierbarkeitstest). Wenn Tabellen wachsen, können Sie feststellen, dass Sie Indizes benötigen, die Sie vorher nicht hatten. Oder es könnte Probleme mit VIEWS oder Joins geben, die im gesamten System verwendet werden.

3) Analysieren Sie die Datenbank. Ich beziehe mich auf die Methode der Tabellenanalyse. Here ist eine langweilige Seite, die beschreibt, was es ist. Auch here ist ein Link zu einem tollen Artikel über Oracle Database Tuning. Einige davon könnten sich auf das beziehen, was Sie tun.

4) Führen Sie Abfragen aus, die von Anwendungen/Benutzern generiert werden, und führen Sie EXPLAIN-Pläne für sie aus. Dies wird zum Beispiel sagen, wenn Sie vollständige Tabellen-Scans haben. Es wird Ihnen helfen, viele Ihrer Probleme zu beheben.

5) Auch Backup und Reload von diesen Backups, um auch in diesem Vertrauen zu zeigen.

Answer 3

+1 Vogelhäuschen, stimme den Vorschlägen zu. Datenbanklasttests können jedoch sehr schwierig sein, da der erste und der entscheidende Schritt ungefähr ist, um die Datenmuster, die in der realen Welt auftreten werden, so gut wie möglich vorherzusagen. Diese Aufgabe wird am besten in Verbindung mit mindestens einem Domänenexperten durchgeführt, da dies sehr stark mit funktionalen und nicht technischen Aspekten des Systems zu tun hat.

Das Modellieren von Datenmustern ist so kritisch, wie die meisten SQL-Ausführungspläne auf Tabellen- "Statistiken" basieren, d. H. Zählungen und Verhältnisse, die von modernem RDBMS verwendet werden, um den optimalen Abfrageausführungsplan zu berechnen. Einige Leute haben Bücher über das sogenannte , z.B. Cost Based Oracle Fundamentals und es ist oft eine Herausforderung, einige dieser Probleme zu beheben, da es an Dokumentation fehlt, wie die Internals funktionieren (oft absichtlich, da RDBMS-Anbieter nicht zu viel über die Details preisgeben wollen).

Zurück zu Ihrer Frage, schlage ich die folgenden Schritte:

1. Gönnen Sie sich ein paar Tage/Wochen/Monate (von der Größe und Komplexität des Projektes abhängig) zu versuchen, den Zustand eines definieren "reife" Datenbank (zB 2-3 Jahre alt) sowie einige Leistungstestfälle, die Sie für diesen großen Datensatz ausführen müssten.
2. Erstellen Sie alle Skripts, um die Basisdaten zu pumpen. Sie können Tools von Drittanbietern verwenden, aber ich habe oft festgestellt, dass sie nicht funktional genug sind, um einige erweiterte Datenverteilungen auszuführen, und außerdem ist es oft viel schneller, SQL zu schreiben als neue Tools zu lernen.
3. Erstellen/implementieren Sie den Leistungstest-Szenario-Client! Dies hängt nun stark davon ab, welche Art von Anwendung die Datenbank unterstützen muss. Wenn Sie eine browserbasierte Benutzeroberfläche haben, gibt es viele Tools wie LoadRunner, JMeter, um End-to-End-Tests durchzuführen. Für Web-Services gibt es SoapSonar, SoapUI ... Vielleicht müssen Sie einen benutzerdefinierten JDBC/ODBC/.Net-Client mit Multithreading-Fähigkeiten schreiben ...
4. Test -> tune -> test -> tune ...
5. Wenn Sie das System in Produktion bringen, machen Sie sich bereit für Überraschungen, da Ihre Vorhersage von Datenmustern niemals sehr genau sein wird. Das bedeutet, dass Sie (oder wer auch immer der Produktions-DBA ist) möglicherweise auf seinen/ihren Füssen denken und einige Indizes im laufenden Betrieb erstellen oder andere Tricks des Handels anwenden müssen.

Viel Glück

Answer 4

ich in der gleichen Situation bin jetzt, hier ist mein Ansatz (SQL Server 2008):

Erstellen Sie eine separate "Numbers" Tabelle mit Millionen von Zeilen von Beispieldaten. Die Tabelle kann zufällige Zeichenfolgen, GUIDs, numerische Werte usw. enthalten. Schreiben Sie eine Prozedur, um die Beispieldaten in Ihr Schema einzufügen. Verwenden Sie das Modul (%) einer Zahlenspalte, um verschiedene Benutzer-IDs usw. zu simulieren.

Erstellen Sie eine weitere "NewData" -Tabelle ähnlich der ersten Tabelle. Dies kann verwendet werden, um neue Datensätze zu simulieren, die hinzugefügt werden.

Erstellen Sie eine "TestLog" -Tabelle, in der Sie Zeilenanzahl, Startzeit und Endzeit für Ihre Testabfragen aufzeichnen können.

Schreiben Sie eine gespeicherte Prozedur, um den Arbeitsablauf zu simulieren, den Sie von Ihrer Anwendung erwarten, wobei Sie je nach Bedarf neue oder vorhandene Datensätze verwenden.

Wenn die Leistung schnell scheint, bedenken Sie die Wahrscheinlichkeit eines Cache-Fehlers! Wenn Ihr Produktionsserver beispielsweise über 32 GB RAM verfügt und Ihre Tabelle 128 GB beträgt, wird eine zufällige Zeilensuche wahrscheinlich zu> 75% nicht im Puffercache gefunden.

Um dies zu simulieren, können Sie den Cache löschen, bevor Sie Ihre Abfrage ausgeführt wird:

DBCC DROPCLEANBUFFERS; (Wenn Oracle: ALTER SYSTEM FLUSH SHARED POOL)

Sie können eine 100x Verlangsamung der Leistung feststellen, wie Indizes und Datenseiten jetzt von der Festplatte geladen werden müssen.

Ausführen SET STATISTICS IO ON; um Abfragestatistiken zu sammeln. Suchen Sie nach Fällen, in denen die Anzahl der logischen Lesevorgänge für eine Abfrage sehr hoch ist (> 1000). Dies ist normalerweise ein Zeichen für einen vollständigen Tabellenscan.

Verwenden Sie die Standardtechniken, um die Abfragezugriffsmuster (Scans vs. Suchvorgänge) zu verstehen und die Leistung zu optimieren.

Fügen tatsächlichen Ausführungsplan, SQL Server Profiler