Echtzeit-Berichterstattung in Geschwindigkeit und Umfang

Als ein großes britisches Logistikunternehmen das Berichtswesen für seine Großkunden verbessern wollte, wandte es sich an Actian, um das zugrundeliegende Datenbanksystem (LARS") zu entwerfen, zu implementieren und zu unterstützen, wobei es Ingres-, HVR- und Vector-Produkte für seine Architektur verwendete.

Der Brief

Der Kunde hatte etwa 100 Kundenbetreuer, die sich um Großkunden kümmerten. Jeder dieser Kundenbetreuer erstellte manuell eine Reihe von täglichen, zweimal täglichen und Ad-hoc-Berichten auf der Grundlage von Tabellenkalkulationen, die er per E-Mail an seine Kundenbetreuer schickte, basierend auf einer Reihe von täglichen Auszügen aus einer Ingres-Datenbank auf operativer Ebene.

Der Kunde wollte das Format der Berichte standardisieren und ihre Erstellung automatisieren, um die Zeit der Mitarbeiter zu sparen, die Berichte einheitlich und rechtzeitig an die Kunden zu liefern und schließlich die Auslagerung der Funktion zu ermöglichen.

Die Herausforderung bestand nicht nur darin, das Volumen an geplanten komplexen Analyseberichten (über 1000 pro Tag, die sich eng um kritische Zeiten am Vormittag und am Nachmittag gruppieren) zu erstellen und gleichzeitig die Erstellung komplexer Ad-hoc-Berichte für 200 Benutzer mit einer Antwortzeit von wenigen Sekunden zu unterstützen, sondern auch darin, a) dies ohne erheblichen Overhead in der operativen Quelldatenbank zu tun und b) den Bedarf an einer Reihe bestehender Auszüge aus der operativen Datenbank zu verringern. Eine weitere Anforderung war, dass es möglich sein sollte, andere bestehende Anwendungen von der Betriebsdatenbank zu einem späteren Zeitpunkt auf diese neue Datenbank umzustellen, so dass das Datenbankdesign der bestehenden Betriebsdatenbank so ähnlich wie möglich sein musste.

Da sich der Projektbeginn verzögerte (aufgrund von Änderungen in der Organisation des Kunden), bestand ein erheblicher Druck, das Projekt in einem möglichst kurzen Zeitrahmen durchzuführen.

Die Architektur

Zur Bereitstellung der Nutzer Front-End-Analyse- und Berichterstattungsfunktion wurde ein halb-angepasstes Paket eines Partnerunternehmens gewählt, das auf dem Produkt Logi Analytics basiert.

Der Entwurf des Datenbankschemas wurde durch den Entwurf des Quelldatenbankschemas eingeschränkt, was dazu führte, dass eine Reihe von Datenbankansichten bereitgestellt werden mussten, die Verknüpfungen über 12 Tabellen beinhalteten, wobei einige der Tabellen über 300 Millionen Zeilen hatten. Um den interaktiven Nutzern realistische Antwortzeiten zu bieten und gleichzeitig den Anforderungen geplanter Berichte gerecht zu werden, wurde Vector als ideales DBMS für diese Datenbank ausgewählt, da es komplexe Abfragen sehr schnell verarbeitet und die Struktur der Ingres-Quelldatenbank praktisch unverändert wiedergeben kann.

Da die Ingres-Quelldatenbank und die Vector-Zieldatenbank im Wesentlichen ähnliche Schemata hatten, wurde HVR (High Volume Replicator) als Softwarelösung gewählt, um die Vector-Datenbank mit der Ingres-Quelldatenbank in Einklang zu bringen. Der HVR Capture-Prozess liest das Transaktionsprotokoll der Ingres-Quelldatenbank und leitet Einfüge- und Aktualisierungsvorgänge über den HVR-Hub an den Zielcomputer weiter, wo der HVR Integrate-Prozess die Einfüge- und Aktualisierungsvorgänge als "Upserts" in die Vector-Datenbank reflektiert ("Löschvorgänge" wurden in HVR unterdrückt, um zu vermeiden, dass die regelmäßigen Bereinigungen der Quelldatenbank auch zu Bereinigungen der Zieldatenbank führen), wodurch der Quelldatenbankcomputer sehr wenig belastet wird.

Die Umsetzung

Die Ingres-Quelldatenbank läuft auf einer älteren HP-UX-Plattform, so dass HVR auf einem eigenen Linux-Server installiert wurde, der als Hub fungiert. Die Vector-Datenbank befindet sich auf einem separaten dedizierten Linux-Server. Eine HVR-"Capture"-Komponente läuft auf dem Ingres-Rechner, erfasst die Änderungen der Quelldatenbank aus dem Transaktionsprotokoll und sendet sie über den HVR-Hub an die HVR-"Integration"-Komponente auf dem Vector-Server, die dieselben Änderungen (über "Upserts") auf die Vector-Zieldatenbank anwendet.

Um den Bedarf des Kunden an kürzeren Entwicklungszeiten kennenlernen , wurde das Projekt innerhalb von 3 Monaten nach Entwicklungsbeginn für die Abnahme Nutzer fertiggestellt, dank der Fähigkeit von Vector, ein Ingres-Schema mit wenigen Änderungen zu spiegeln.

Um die Anzahl der Tabellen-Joins in den Ansichten von 12 auf überschaubare 9 zu reduzieren, wurde ein regelmäßig geplanter Job (der alle 10 Minuten ausgeführt wird) erstellt, um eine de-normalisierte Tabelle zu pflegen.

Der Aktualisierungsauftrag für die Entnormalisierung, der HVR-Auftrag "Upsert", die große Anzahl geplanter Berichte und die interaktiven Benutzer können auf dem Vector-Server problemlos nebeneinander bestehen.

Vektorielle Leistung

Es ist oft wenig aussagekräftig, die Abrufzeiten eines Systems anzugeben, da so viele Variablen eine Rolle spielen, aber wir können einen Eindruck von der Abrufleistung der Vector-Datenbank im Vergleich zu ihrer Ingres-Quelldatenbank vermitteln. Ein Mitglied des IT-Personals des Kunden musste eine unangemessen umfangreiche Anfrage gegen die Ingres-Quelldatenbank laufen lassen, die 10 Minuten lang lief, bevor sie sie als unhaltbar abbrach. Wir führten dieselbe SQL-Anfrage gegen die Vector-Live-Datenbank aus, und zwar zur Hauptgeschäftszeit - sie wurde in 0,05 Sekunden abgeschlossen. Obwohl dies kein direkter Vergleich ist, da die beiden Datenbanken auf unterschiedlichen Plattformen und Hardwarekonfigurationen liefen, zeigt es doch die enorme Abrufgeschwindigkeit, zu der Vector in der Lage ist.

In der Tat war die Leistung von Vector so beeindruckend, dass die Anforderungen des Kundenteams geändert wurden. Die vorgesehene Arbeitspraxis sah vor, dass bis zu 200 komplexe Berichte zwischen 10 Uhr und 10:30 Uhr ausgeführt werden sollten, aber Vector war so schnell und komfortabel, dass diese Berichte jetzt alle innerhalb von 5 Minuten nach 10 Uhr ausgeführt werden, und das war nur durch die Ressourcen (Kerne, Speicher usw.) auf dem Rechner begrenzt.

Kundenzufriedenheit

Der Kunde war von der neuartigen Architektur der LARS-Implementierung so beeindruckt, dass er ein zweites, anspruchsvolleres vektorbasiertes Projekt in Auftrag gab, das aus einem kontinuierlichen Nachrichtenstrom gespeist werden sollte. Dies wird das Thema eines zukünftigen Blogeintrags sein.

Über Emma McGrattan

Als Chief Technology Officer bei Actian leitet Emma McGrattan die Technologiestrategie, Innovation und Produktentwicklung des Unternehmens und unterstützt damit Actians Mission, die Art und Weise zu vereinfachen, wie Unternehmen Daten verbinden, verwalten, steuern und analysieren, um Unternehmen zu transformieren. Seit ihrem Eintritt in das Unternehmen vor drei Jahrzehnten hat Emma Rattan eine entscheidende Rolle bei der Entwicklung und Weiterentwicklung der Analyse-, Datenintegrations- und Datenmanagement von Actian gespielt, einschließlich der Actian Data Platform. Emma hat einen Abschluss in Elektronikingenieurwesen von der Dublin City University in Irland.