Datenbank (OLTP) und Reporting

Question

Ich arbeite an einer Handelsplattform, die Berichterstattung als einen großen Teil ihres Geschäfts hat.

Die Einrichtung ist folgende: SQL OLTP-Datenbank (ca. 200 Tabellen) - eher kleine Anzahl von Datensätzen. (20.000 Datensätze die größte Tabelle - aber wächst jede Woche) Für Reporting-Dienste werden SQL-Ansichten verwendet, um die Live-Transaktionsdatenbank abzufragen. Stellen Sie sich die Ergebnismenge der Ansichten als de-normalisiert vor, im Sinne eines Data-Warehouse-Ansatzes. Dann werden diese Datensätze an eine Reporting-Plattform eines Drittanbieters (wie Tableau, Power Bi oder SiSense) weitergeleitet, die diese Datensätze aufnimmt und in Cubes wirft (wahrscheinlich eine spaltenartige Struktur wie mono db, hadoop usw.). Von dort werden die Berichte generiert.

Aktuelle Herausforderungen. Die SQL-Ansichten (ca. 8). Sind riesig und sehr schwer zu pflegen. Um Ihnen ein Beispiel zu geben, gibt eine der Ansichten 100 Felder aus. Aber jedes dieser Felder sind berechnete Felder mit komplizierten CASE-Anweisungen, verschachtelten IF-Anweisungen, Inline-Funktionen und was nicht, was diese Ansicht so groß wie 700 Zeilen SQL-Code macht. Ich erbte diese von Anthere Angestellter und jetzt, leider, muss ich sie beibehalten. Da die Daten wöchentlich um mehrere hundert Datensätze (durch Migration und Transaktionen) wachsen und auch die Anzahl der Felder in den Ansichten zunimmt (einige wenige pro Woche), dauert die Erstellung des Würfels länger und länger. Um Ihnen ein Beispiel zu geben, haben wir vor ein paar Monaten den neu erstellten Cube 10 Minuten lang eingerichtet, um die Daten zu aktualisieren (was 5 Minuten dauerte). Momentan dauert es 12-15 Minuten, um zu bauen, also richten wir es alle 30 Minuten ein. Wie Sie sich vorstellen können, wird sich dies verschlimmern, da die Daten und die Anzahl der Felder weiter wachsen; und wir brauchen die Daten so aktuell wie möglich.

Die einzige gute Sache ist, dass, sobald der Cube gebaut ist, die Berichte schnell laden, weil sie von der 3rd-Party-Plattform gezogen werden, also hier keine Bedenken.

Was ich im Sinn habe Ich möchte die Ansichten loszuwerden, damit ich den Prozess der maintenanace erleichtern könnte und auch bei gering halten, die Dauer des Würfels wieder aufgebaut.

Optionen:

1. ein Data Warehouse aufzubauen. Erstellen Sie dann SSIS-Pakete, um diese Struktur mit den Live-Transaktionsdaten zu füllen. Die de-normalisierte Struktur würde den oben erwähnten Ansichten wahrscheinlich sehr ähnlich sein. Der Nachteil hier ist, dass ich nicht wirklich das Gefühl habe, dass ich viel vereinfache, sondern tatsächlich eine weitere Ebene hinzufüge, nämlich die Datenmigration vom OLTP zum OLAP (Datawarehouse). Und ich müsste den Würfel immer noch neu bauen.
2. Um die aktuellen Ansichten in SQL indizierte Sichten (materialisierte Ansichten) zu verwandeln, aber in ihrem aktuellen Zustand, kann ich es einfach nicht tun, weil die Aggregate- und Inline-Funktionen viel über die gesamte Ansicht hinweg verwendet werden.
3. Eine weitere Option, die ich rot ist, ist ein ODS (Operational Data Store - das wäre eine Datenbank, die die erforderlichen Tabellen ähnlich wie die SQL-Ansichten, die ich jetzt habe, und aktualisieren sie ständig) Vielleicht mit Triggern oder Transaktion Protokolle? Aber ich bin mir nicht sicher, was es bedeutet, so etwas zu bauen und wie schwer es ist, es aufrechtzuerhalten.

Frage: Welche Ansatz soll ich nehmen? Macht irgend eines der obigen 3 einen Sinn? Natürlich interessiere ich mich auch für andere Ideen oder Vorschläge.

Vielen Dank!

Answer 1

Aus meiner Erfahrung wird Ihr bester Ansatz 1. Es ist teuer, aber wird Ihnen bessere Vorteile geben. Erstellen Sie eine ROLAP DWH (ich empfehle Kimballs "Das Data Warehouse Toolkit" für Best Practices und Design Patterns), wenn Sie die Möglichkeit haben, einen Columnar Data Store (wie Amazon Redshift oder Sap Sybase iq) und alle Case-Anweisungen, geschachtelte Wenns zu verwenden und alle Operationen, die Sie erwähnten, würden auf ETL-Zeit angewendet werden, so dass in der ROLAP alles vorberechnet und für den Verbrauch optimiert ist. Vergessen Sie nicht, Indizes zu verwenden (abhängig von der verwendeten Technologie). Einige Datenbankanbieter haben bereits "Best Practices für die Indexierung" für ROLAP veröffentlicht, sodass sie Ihnen sagen können, welcher Typ von Index abhängig vom Typ der Tabelle (Dimension) und dem Datentyp zum Beispiel ist.