Datenbanken können mit Excel, GSheet oder großen ORM-Systemen implementiert werden. In meiner Praxis der Geschäftsanalyse bin ich auf verschiedene Lösungen gestoßen. Und seit ich aus den Bereichen Finanzen und Wirtschaftsprüfung zur Geschäftsanalyse gekommen bin, habe ich mir jedes Mal, wenn ich auf ein neues System gestoßen bin, Fragen gestellt: Wie unterscheiden sich alle voneinander und welche Aufgaben lösen sie? Einige Antworten gefunden. Dieser Artikel behandelt zwei Hauptzwecke von Datenbanken:
1 - Bilanzierung von Operationen,
2 - Datenanalyse
Die erste Art von Aufgaben wird von OLTP-Systemen gelöst: von O n L ine Transaction Processing. Der zweite Typ wird durch OLAP-Systeme gelöst: von O n L ine A nalytical Processing
OLTP
Das OLTP-Speichermodell kann mit Telefonbucheinträgen verglichen werden. Die Zeile in der Tabelle wird als Index und der entsprechende Datenindex dargestellt: (indexN, data). Daher kann eine solche Tabelle nicht als Tabelle bezeichnet werden. Es ist eher ein gewöhnliches Buch mit nummerierten Zeilen. Wenn Sie eine neue Operation in das Buch schreiben müssen, fügen Sie eine Zeile hinzu, weisen Sie einen Index zu und schließen Sie das Buch. Aus dem Buch ragen Etiketten heraus, mit denen Sie schnell O (log n), die gewünschte Zeile finden und CRUD ausführen können.
Für Betriebsabrechnungszwecke ist dies eine benutzerfreundliche Anzeige. Es ist jedoch nicht feindlich gegenüber der Datenanalyse, bei der nicht die Zeilen selbst für uns wichtig sind, sondern die Berechnungen, die auf dem Inhalt dieser Zeilen basieren. Und wenn Sie eine analytische Abfrage basierend auf dem Inhalt der Zeilen durchführen, d. H. Bei nicht indizierten Feldern funktionieren solche Abfragen langsamer.
Wie Sie wissen, ist das Indizieren aller Datensätze keine Option. Obwohl das Buch wie eine Tabelle wird, wenn Attribute für die schnelle Suche verfügbar werden, verlangsamt es auch die Erstellung neuer und die Aktualisierung vorhandener Zeilen. Da für diese Vorgänge das gesamte Array neu sortiert werden muss.
Der Kompromiss zwischen OLAP und OLTP
In 1C-Lösungen wird ein Kompromiss wie folgt implementiert. Ereignisse beim Schreiben in die Datenbank werden an mehrere Stellen gleichzeitig geschrieben. An einer Stelle haben Datensätze nur wenige Indizes und sind für OLTP-Ladevorgänge optimiert. An einer anderen Stelle werden Datensätze von allen Feldern indiziert und für OLAP-Ladevorgänge angepasst. Solche Tabellen werden Akkumulationsregister und Informationsregister genannt. Da das Schreiben an mehrere Stellen den belegten Speicherplatz um ein Vielfaches erhöht, fallen zum Speichern nicht alle Transaktionsattribute in die Register, sondern nur diejenigen, die für diesen Abschnitt der analytischen Buchhaltung als wichtig angesehen werden. Ein solcher Kompromiss wird als ROLAP-Modell bezeichnet, d.h. relationales analytisches Mapping.
OLAP
In SAP ging das deutsche Gegenstück 1C weiter. Das relationale OLTP-Modell in dieser Software kann auf das OLAP-Modell repliziert werden. SAP HANA implementiert eine Speicherspaltenstruktur. Dies bedeutet, dass die "Tabellen" dort nicht als Satz von Zeilen, sondern als Satz von Spalten gespeichert werden.
Ein ähnliches Speicherschema ist in Lösungen wie Google Bigquery, Microsoft SSAS Tabular, Amazon Redshift und Yandex ClickHouse implementiert.
Der Unterschied zwischen Spaltenspeicher und Zeilenspeicher
Wenn in einer zeilenweisen Struktur die Daten in Form von "horizontalen" Tupeln gespeichert sind, von denen jedes eine Transaktion ist:
period, product, department (Q1, SKU1, 1) (Q1, SKU2, 1) (Q1, SKU1, 1) ... (Q2, SKU1, 1) (Q2, SKU1, 1) (Q3, SKU1, 1) (Q3, SKU1, 1) ...
Dann werden solche Daten in der Spalte "vertikal" gespeichert:
(Q1, Q1, Q1, ... Q2, Q2, Q3, Q3, ...) (SKU1, SKU2, SKU1, ... SKU1, SKU1, SKU1, SKU1, ...) (1,1,1, ... 1,1,1,1, ...)
Wiederholungen können wie folgt bedingt optimiert werden:
period = (Q1, {start: 0, count: n}, Q2, {start: n+1; count: m}, ...) product = (SKU1, {start: 0, count: 1}, SKU2, {start: 1; count: 1}, SKU1, {start: 2; count: m}, ...) department = (1,{start:0, count:m}...)
Wenn es eine Spalte gibt, für die eine solche Optimierung das anfängliche Volumen nicht verringert, werden die Daten in ihrer ursprünglichen Form gespeichert.
Die Engine der Spaltentabelle selbst wählt die Reihenfolge der Sortierung der Spalten. Wenn Sie jedoch Ihre Daten kennen und manuell sortieren, erhöht dies häufig die Komprimierung und erleichtert die analytische Belastung. Meine Komprimierung einzelner Tabellen hat das 300-fache überschritten. In der Praxis ist eine solche Datenspeicherstruktur:
- ermöglicht es Ihnen, Daten auf das Niveau zu komprimieren, wenn sie im RAM abgelegt werden, d. h. Stellen Sie In-Memory-Berechnungen zur Verfügung, deren Geschwindigkeit nicht mit Abfragen zu relationalen Datenbanken vergleichbar ist
- legt seine eigenen Regeln für die Erstellung eines Datenmodells fest und erfordert keine Normalisierung mehr wie in OLTP
- definiert seine Semantik zum Konstruieren analytischer Ausdrücke.
Die Besonderheiten der Ausdrücke werden ausführlich beschrieben:
Hier ist für Google BigQuery.
Hier ist für Microsoft DAX.
BI als Spaltenbasisinfrastruktur
BI ist eine Lösung für die analytische Belastung. Und sie erleichtern das Leben erheblich, wenn sie auf Spaltendatenbanken aufbauen. Dies kann ein hausgemachtes ClickHouse-Grafana-Python-Bündel oder ein Google-Stapel-Bündel sein: Bigquery-Data Studio-Dataprep-Dataflow oder das monolithische Power BI.
Mehrdimensionale Cubes sind eine weitere OLAP-Alternative zum Spaltenspeicher. Für mich sind MDX-Ausdrücke im Vergleich zu SQL in BQ oder DAX redundant und komplex.