Kürzlich haben wir den Ansatz getestet, den wir QDM nennen, wenn wir mit großen Datenmengen arbeiten - Hunderten von Gigabyte. Im Rahmen dieser Aufgabe haben wir 12 bis 24 Millionen Datensätze verarbeitet und die Leistung der Quintettlösung mit ähnlichen Funktionen in normalen Tabellen verglichen.
Wir haben keine neuen Entdeckungen gemacht, aber die Hypothesen bestätigt, die wir zuvor geäußert haben: Wie viel verliert der universelle Designer in den Händen der bedingten „Teekanne“ an eine professionell konfigurierte Datenbank.
Wir wissen jetzt auch, was in einer solchen Situation zu tun ist - die Lösung ist recht einfach und zuverlässig, und wir haben Erfahrung in der Organisation einer Kompromisslösung für beliebig große Datenmengen.
Während der Entwicklung des Systems zur Abstimmung von Berichten mussten wir die Daten eines der Berichtsformulare herunterladen, das zu jedem Berichtsdatum bis zu 24 Millionen Datensätze enthält. Es sollten Daten für 7 Jahre täglicher Berechnungen vorliegen. Bände, ehrlich gesagt, nicht für einen universellen Designer, sondern für ein hochspezialisiertes System, aber wir haben uns bereits an diesem Vorhaben beteiligt und mussten nach einer Lösung suchen.
Benutzer arbeiten mit diesem großen Datensatz nur innerhalb eines Berichtsdatums. Daher wird dies im Referenzsystem in einer nach diesem Datum partitionierten Tabelle gespeichert. Indizes für die verbleibenden 26 Datenfelder werden für dieses Formular nicht verwendet.
Als erstes haben wir natürlich die gewünschte Datenstruktur im Konstruktor erstellt und dort mehrere Daten geladen. Das Herunterladen eines der kleinsten Daten dauert ungefähr 14 Stunden, was unannehmbar lang ist: 12,5 Millionen Datensätze mit 27 Attributen, eine halbe Milliarde Datensätze mit 5 Feldern mit der Konstruktion von drei Indizes, von denen zwei zusammengesetzt sind.
Die Gesamtmenge dieser Daten auf der Festplatte beträgt etwas mehr als 18 GB.
Es ist erwähnenswert, zwei Merkmale dieses Formulars:
- Es eignet sich fast nicht für eine Normalisierung, im Gegensatz beispielsweise zu Form 110, die in einer früheren Veröffentlichung erörtert wurde
- Es werden keine Indizes für die Attribute von Datensätzen verwendet - es ist für den Benutzer rentabler, eine Minute zu warten, als Geld für Indizes auszugeben
Dies kann als der radikalste Fall bezeichnet werden, den Sie zum Vergleich auswählen können. In den meisten Fällen ist der Unterschied im Volumen der QDM-Daten und der üblichen Datenbank nicht so dramatisch oder sogar recht gering .
Zum Vergleich: Dieselben Daten, die in eine reguläre Tabelle in einer relationalen Datenbank geladen werden, benötigen 2,3 GB (8-mal weniger) zusammen mit dem Index nach Datum, und ihr Download dauert weniger als eine halbe Stunde (28-mal schneller). In beiden Fällen wurden die Daten in Teilen von 100.000 Datensätzen direkt aus der Datei eingefügt, ohne die Indizes zu deaktivieren.
Da es für solche Datenmengen nicht praktikabel ist, einen Konstruktor zu verwenden, haben wir dennoch Leistungstests durchgeführt: In verschiedenen Fällen haben wir die Massenverarbeitung von Datensätzen mit dem Konstruktor und unserer nicht indizierten Tabelle verglichen. Wir mussten die Grenze der Datenmenge bestimmen, für die wir fortan eine reguläre Tabelle verwenden werden, und nicht unseren Konstruktor.
Wie wir erwartet haben, sieht die Arbeit mit kleinen Datenmengen, beispielsweise auf einem separaten Konto oder Client, im Designer im Gegensatz zu einer Tabelle ohne Indizes, in der Sie Minuten warten müssen, um zu antworten, recht komfortabel aus (Antwortzeit innerhalb einer Sekunde). Gleichzeitig kann die Hauptaufgabe der Anwendung - Massenabtastung und Aggregation von Daten in verschiedenen Abschnitten - im Designer um ein Vielfaches länger dauern.
Nachfolgend finden Sie die zusammenfassenden Ergebnisse der Stichproben, die wir für ein schrittweise zunehmendes Volumen aggregierter Daten erstellt haben:
Wo es möglich war, haben wir mehrere Messungen durchgeführt, nachdem wir Statistiken ausgewählt und die Anzahl der Datensätze anhand der Kontonummernmaske ausgewählt hatten.
Die folgende Tabelle und Grafik zeigen, dass die Aggregation eines vollständigen Datensatzes innerhalb eines Tages erheblich weniger Zeit in Anspruch nimmt als die Stichprobe von mehr als 5% der Daten mithilfe des Index. Aus diesem Grund ignorieren RDBMS-Abfrageoptimierer den Index in einer solchen Situation, während der Engine unseres Dienstes derzeit eine solche Möglichkeit genommen wird.
Grafische Darstellung derselben Ergebnisse unter Verwendung einer logarithmischen Skala zum Vergleichen von Zahlen verschiedener Ordnungen:
Die Geschwindigkeit des Designers bei der Verarbeitung eines vollständigen Datensatzes ist fast eine Größenordnung niedriger als die einer regulären Tabelle, was für den Designer ganz normal ist. Es ist wichtig, eine Lawinen-ähnliche Verschlechterung der Leistung zu vermeiden, und dieses Ziel wurde erreicht.
Die Studie zeigte, dass die Anzahl der Datensätze in der Datenbank praktisch keinen Einfluss auf die Geschwindigkeit beim Erstellen von Seiten, der Navigation und kleinen Stichproben in einem Quintettdatenmodell hat. Mit der Menge der verarbeiteten Daten von bis zu 10.000 Datensätzen (und dies ist die maximale Auswahl verwandter Daten für eine Instanz einer Geschäftseinheit im Informationssystem) können Sie bequem mit einer Datenbank von Hunderten von Gigabyte oder mehr arbeiten.
Als nächstes haben wir unserem Tabellen-Plugin ( hier beschrieben) beigebracht, einen Connector für eine beliebige Datenbank aufzurufen, damit er sowohl mit dem Quintett-Datenmodell als auch mit herkömmlichen Tabellen transparent funktioniert.
Aus Sicht des Benutzers ist es ihm egal, mit welcher Datenquelle er arbeitet, während er die wichtige Arbeit für ihn in der vertrauten Oberfläche erledigen und seine Berichte erhalten kann:
Jetzt werden wir die verbleibenden ähnlich großen Tabellen, die in unserer Datenbank nur zwei Dutzend von Hunderten sind, in einem separaten Speicher herausnehmen, um bequem mit ihnen arbeiten zu können.
Daher können wir den Konstruktor für kleine und mittlere Tabellen verwenden, die eine intensive Suche und Aggregation nach beliebigen Attributen erfordern, und große nicht indizierte Objekte in flachen traditionellen Tabellen speichern und sie aus Speicher von Drittanbietern oder spezialisierten Datenbanken (Hadoop und andere NoSQL) aufrufen.
Der Designer eignet sich am besten für CRM-Systeme und ähnliche Produkte, bei denen der Benutzer mit einem einzelnen Client, Konto oder einer anderen Entität arbeitet und die Analysefunktionen in einen separaten Spezialspeicher verschoben werden.