Big Data laden? Für mehr Geschwindigkeit, Vorsortieren und Massenladen
Höhere Geschwindigkeit beim Laden von Big Data zu finden, ist eine Herausforderung in ETL, Reorg und Index für sehr große Datenbanken (VLDB). Operationen auffüllen. Eine Möglichkeit, Big Data schneller zu laden, besteht darin, es vorzusortieren, sodass die Datenbank nicht sortiert werden muss. IBM und andere Anbieter von Mainframe-Datenbanken geben diesen Rat seit Jahrzehnten, und er gilt immer noch für relationale Datenbanken, die heute unter Unix und anderen „offenen Systemen“ verwendet werden, einschließlich Oracle, DB2, Sybase und SQL Server.
Benchmarks in diesem Bereich zeigen je nach Volumen Verbesserungen gegenüber unsortierten Ladevorgängen, aber Sortieranbieter wie IRI behaupten, dass sich die Ladeleistung um das Zwei- bis Zehnfache verbessert hat. Im TUSC Consulting-Bericht „Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle“ zeigte allein ein 100.000 Zeilen einzelner Index-Einfügungstest, dass vorsortierte Daten 58 % schneller geladen wurden und 49 % weniger Speicherplatz benötigten:
- Das Laden in sortierter Reihenfolge hatte eine um 42 % niedrigere kontinuierliche Laderate von Zeilen/Sekunde
- Unsortierte Einfügungen in Indizes erzwingen mehr interne Datenbankarbeit (Blockverwaltung und Speicherplatzreorganisation)
- In nach Last sortierten Indizes liegt der Clustering-Faktor in der Nähe der Anzahl der Blattblöcke
- Die Reihenfolge der geladenen Daten ist entscheidend für die Ladeleistung.
Viele Jahre später empfahl Sam R. Alapati (Miro Consulting) in Kapitel 13 seines „Expert Oracle Database 11g Administration“-Leitfadens das Vorsortieren in Verbindung mit direkten Pfadladevorgängen als den schnellsten Weg zum Massenladen von Oracle (im Vergleich zu Einfügungen):
„Dasdirekte Laden Option verwendet nicht die SQL INSERT-Anweisung, um Daten in Tabellen einzufügen; Vielmehr formatiert es Oracle-Datenblöcke und schreibt sie direkt in die Datenbankdateien. Dieser Direktschreibprozess eliminiert einen Großteil des Overheads, der mit der Ausführung von SQL-Anweisungen zum Laden von Tabellen verbunden ist. Da die Direct-Path-Loading-Methode nicht um Datenbankressourcen konkurriert, lädt sie Daten viel schneller als herkömmliches Laden von Daten. Für größere Datenlasten ist die Lademethode mit direktem Pfad am besten geeignet, und es kann die einzig praktikable Methode zum Laden von Daten in Tabellen sein, aus dem einfachen Grund, dass ein herkömmliches Laden mehr Zeit in Anspruch nehmen kann, als verfügbar ist.“
Für Administratoren von VLDBs von heute kommt CoSort hier ins Spiel, denn:
„Neben den offensichtlichen Vorteilen einer kürzeren Ladezeit hilft Ihnen das direkte Laden auch dabei, Indizes neu aufzubauen und Tabellendaten vorzusortieren.“
CoSort wird traditionell in der externen Vorsortierung einer Flatfile verwendet, die in einen Ladevorgang importiert wird, wobei „direct=true“ und diese Option angegeben werden:
„SORTED INDEXES:Der Parameter SORTED_INDEXES signalisiert SQL*Loader, dass Daten nach einem bestimmten Index sortiert werden, was die Ladeleistung verbessert.“
In ähnlicher Weise gibt die Microsoft SQL Server-Dokumentation die Vorsortierung von Dateien als eine der „Methoden zur Optimierung des Massenimports“ an:
Standardmäßig wird bei einem Massenimportvorgang davon ausgegangen, dass eine Datendatei unsortiert ist. Wenn die Tabelle einen gruppierten Index hat, wird der bcp Dienstprogramm, BULK INSERT-Anweisung und OPENROWSET(BULK…)-Funktion (Transact-SQL) ermöglichen es Ihnen, anzugeben, wie Daten in der Datendatei während eines Massenimportvorgangs sortiert werden. Es ist optional, dass Daten in der Datendatei in derselben Reihenfolge wie die Tabelle sortiert werden. Sie können jedoch die Leistung des Massenimportvorgangs verbessern, wenn Sie dieselbe Reihenfolge für die Datendatei wie für die Tabelle angeben.
Das Feld /KEY in einem CoSort SortCL-Skript wäre normalerweise der längste Indexschlüssel (Primärschlüssel) in der Tabelle, muss es aber nicht sein. Laut TUSC für ähnliche Spalten:
- Weniger längere Indizes sind kürzeren Indizes vorzuziehen
- Die führende Spalte bestimmt die Indexladekosten
Beachten Sie auch Folgendes:
- Laut Vertica und anderen RDBMS-Primern optimiert das Beibehalten von Spalten in sortierter Reihenfolge die Abfrageleistung. Sogar der alte Ratschlag im Rdb/VMS-Leitfaden zur Datenbankwartung und -leistung von DEC gilt immer noch:
„Sortieren Sie die Datensätze, die Sie in einer Tabelle speichern möchten, nach Primärschlüsselwert, bevor Sie sie in die Datenbank laden. Wenn die Datensätze geladen werden, liegen sie physisch nebeneinander oder gruppieren sich, bis weitere Datensätze in der Datenbank gespeichert werden. Die Beibehaltung dieser Anordnung kommt Abfragen zugute, die Zeilen basierend auf einem Wertebereich auswählen oder die viele Zeilen einer Tabelle mit Zeilen in derselben Tabelle verbinden.“
- Das Vorsortieren von Daten in Tabellen kann auch in Ansichten Zeit sparen. Laut „Oracle Database 10g:The Complete Reference“ von Kevin Loney:
„Das Sortieren der Daten in der Ansicht kann Ihre Anwendungsentwicklung vereinfachen. Wenn Ihr Code beispielsweise eine Reihe von Datensätzen schrittweise durchläuft, kann die Vorsortierung dieser Datensätze Ihre Verarbeitung und Fehlerprüfung vereinfachen. Bei Ihrer Anwendungsentwicklung wissen Sie, dass die Daten immer in geordneter Form an Sie zurückgegeben werden.“
- Mr. Alapati warnt DBAs vor einer Beschränkung des direkten Ladevorgangs:
„Hinweis:Bei einem direkten Ladevorgang können Sie keine SQL-Funktionen verwenden. Wenn Sie eine große Datenmenge laden und auch transformieren müssen die Daten während des Ladens, haben Sie ein Problem. Beim herkömmlichen Laden von Daten können Sie SQL-Funktionen zum Transformieren von Daten verwenden, aber die Methode ist im Vergleich zum direkten Laden sehr langsam. Daher sollten Sie bei großen Datenlasten die Verwendung einer der neueren Lade-/Transformationstechniken wie externe Tabellen oder Tabellenfunktionen in Erwägung ziehen.“
Das SortCL-Programm von CoSort kann jedoch die Ladedaten während der Vorsortierung umwandeln; d.h. durch Kombinieren derselben Art von SQL-Funktionen in demselben Jobskript und demselben E/A-Pass, einschließlich:Verknüpfungen, Aggregationen, Kreuzberechnungen, Suchen, Auswahl-/Filter-, Teilstring- und Instring-Funktionen sowie zahlreiche Neuformatierungs- und benutzerdefinierte Berichtsziele — in demselben Vorsortiervorgang.
- Das neue Offline-Reorg-Dienstprogramm in der IRI Workbench (Eclipse-GUI) verwendet IRI FACT (Fast Extract), um Tabellendaten schnell über OCI zu entladen, verwendet CoSort, um den Primärschlüssel vorzusortieren, und schreibt und führt SQL*Loader direkt aus Pfadlasten, um jeden dieser Schritte zu optimieren und zu kombinieren.
