Wie unterscheidet sich die Performance von Wide Tables (OBT) gegenüber Star-Schemas in modernen Cloud-OLAP-Engines?

In modernen Cloud-OLAP-Engines (z. B. BigQuery, Snowflake, ClickHouse) verschiebt sich das Performance-Paradigma weg von der Normalisierung hin zur Denormalisierung. Während Star-Schemas in klassischen RDBMS die Speicherplatzoptimierung priorisieren, nutzen Cloud-native Engines spaltenbasierte Speicherung (Columnar Storage).

Die Performance-Vorteile von OBT resultieren primär aus dem Wegfall von Joins. In verteilten Systemen verursachen Joins oft einen sogenannten "Data Shuffle", bei dem Daten über das Netzwerk zwischen verschiedenen Rechenknoten verschoben werden müssen, um passende Schlüssel zu paaren. OBT eliminiert diesen Flaschenhals, da alle benötigten Attribute in einer physischen Zeile vorliegen. Da spaltenbasierte Engines nur die tatsächlich abgefragten Spalten vom Speicher lesen, spielt die theoretische Breite der Tabelle für die I/O-Performance kaum eine Rolle.

Wir beobachten in der Praxis, dass Star-Schemas weiterhin Vorteile bei der Datenkonsistenz und der Flexibilität bieten. Wenn Dimensionen häufig aktualisiert werden müssen, ist ein Star-Schema effizienter, da Änderungen nur an einer Stelle erfolgen. Für analytische Workloads mit extrem hohen Datenvolumina und Anforderungen an die Latenz ist die Denormalisierung jedoch überlegen. Im Rahmen unserer IT-Consulting & Digitale Strategie implementieren wir oft hybride Ansätze, bei denen die Rohdaten im Star-Schema vorliegen und für die Endnutzer-Reports in OBT-Views oder Materialized Tables überführt werden.

Für maximale Abfragegeschwindigkeit in Cloud-OLAP-Umgebungen empfehlen wir den konsequenten Einsatz von Wide Tables (OBT), sofern die Update-Zyklen der Dimensionen die Rechenkosten der Denormalisierung nicht übersteigen.