F

Sechs Tipps für bessere Performance von Data Warehouses

Sechs allgemeine und ausführliche Tipps aus der Praxis helfen die Performance des Data Warehouse zu erhöhen.

Könnten Sie mir ein paar Tipps dazu geben, wie wir die Performance unseres Data Warehouse verbessern können? Wir...

würden gern die Performance beim Laden von Daten und bei der Bearbeitung von Abfragen erhöhen.

Gerne gebe ich Ihnen ein paar Hinweise dazu. Denken Sie aber bitte daran, dass sich jeder ernst zu nehmende Berater das jeweilige Unternehmen genau anschauen sollte, bevor er Vorschlägen für Veränderungen an einem Data Warehouse ausarbeitet – und ich weiß nichts über Ihr Unternehmen. Hier jedenfalls sind meine sechs besten allgemeinen Tipps für bessere Performance von Data Warehouses:

1. Bevor Sie an eine Performance-Optimierung auch nur denken, sollten Sie die bestehenden Engpässe identifizieren. Wenn die Performance bei Abfragen von der CPU limitiert wird, ist es reine Geldverschwendung, schnellere Festplatten zu kaufen.

2. Kennen Sie Ihre Datenbank-Engine – wenn die Nutzer darüber nicht genau Bescheid wissen, leidet oft die Performance. So habe ich schon gesehen, dass der Befehl SQL INSERT verwendet wurde, wenn eigentlich die Utility für Bulk Loads passender gewesen wäre. Ebenfalls kommt es vor, dass Leute eine Tabelle mit DELETE * leeren. Dies kann im Vergleich mit DROP oder CREATE schmerzhaft langsam verlaufen - erst recht im Vergleich mit TRUNCATE. Natürlich kann es sein, dass Ihre Datenbank-Software TRUNCATE nicht unterstützt – genau deshalb müssen Sie ihre Datenbak-Engine ja so genau kennen. Wenn Sie noch keinen guten Datenbank-Administrator haben, könnte sich die Einstellung schon aus Performance-Gründen lohnen.

3. Bei Abfragen sollten Sie darüber nachdenken, die Daten als MOLAP-Cube (multidimensional online analytical processing) zu strukturieren und solange zu aggregieren, bis die Abfrage-Performance zufriedenstellend ist. Dies kann viel Speicherplatz und Zeit für Datenverarbeitung erfordern, sich aber sehr positiv auswirken.

4. Denken Sie über den Einsatz von Solid-State Drives (SSDs) nach. Um Probleme durch mangelnde Festplatten-Geschwindigkeit zu beheben, können diese eine unglaublich kostengünstige Lösung sein. Vor kurzem habe ich einen Kunden mit einem OLAP-Cube von 35 Gigabyte beraten, der zu langsam war – sowohl hinsichtlich Aggregationszeit als auch bei der Reaktion auf Abfragen. Ich habe hier die Verwendung einer SSD vorgeschlagen. Zufällig war gerade ein nagelneuer PC mit einer SSD von 70 Gigabyte für Tests im Haus, vorgesehen für einen Vertreter, der sich über zu langsames Booten beschwert hatte.

Die Maschine wurde ausgeliehen, das Management-System für die relationale Datenbank auf der Festplatte installiert und eine Kopie des OLAP-Cubes auf der SSD. Schon die Aggregation des Cubes ging deutlich schneller vonstatten, doch bei Abfragen gab es geradezu dramatische Verbesserungen – teilweise um den Faktor 20 bei gleichem Aggregationsgrad. Die Kosten der SSD (etwa 200 Dollar) waren in diesem Licht trivial.

Die meisten Leute denken bei SSDs an Laptops (auch in meinem steckt eine 250-GB-SSD). Dabei können sie bei Platten-intensiven Anwendungen ganz allgemein ungeheuer nützlich sein.

5. Nehmen Sie Extract, Processing und Loading (ETL) wenn möglich im Arbeitsspeicher vor. Bei langen ETL-Jobs kann es sich lohnen, Caches auf der Festplatte anzulegen (falls der Prozess abbricht), während der Transformationen aber sollten die Daten im RAM gehalten werden. Als Cache sollten sie eine SSD statt einer normalen Festplatte verwenden.

6. Indizieren Sie Ihre analytischen Strukturen für Analysen, nicht für Transaktionen. Das hört sich offensichtlich an. Aber ich habe schon unzählige relationale OLAP-Sternschemata gesehen, bei denen die Indizierungsstrategie eindeutig auf langer Erfahrung mit transaktionalen Systemen und wenig Wissen über analytische beruhte.

So indizieren viele RDBMS-Engines als Voreinstellung den Primärschlüssel einer Tabelle. In einer transaktionalen Struktur ist das sehr sinnvoll, weil hier viele Abfragen diese Indizes verwenden – nicht aber in einem Sternschema, bei dem keinerlei, wirklich absolut null Abfragen die Primärschlüssel-Indizes verwenden. Auf der anderen Seite werden alle analytischen Spalten in Dimensionstabellen mit sehr hoher Wahrscheinlichkeit durchsucht und lassen trotzdem oft jeden Index vermissen.

Artikel wurde zuletzt im Mai 2011 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Data Warehouse

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close