Wer weiß etwas über OLAP Internals?

Question

Ich weiß ein wenig über Datenbank Interna. Ich habe vorher eine kleine, einfache relationale Datenbank-Engine implementiert, die ISAM-Strukturen auf Disketten- und BTree-Indizes verwendet und all diese Dinge. Es war lustig und sehr lehrreich. Ich weiß, dass ich viel mehr über das sorgfältige Entwerfen von Datenbankschemas und das Schreiben von Abfragen weiß, da ich ein bisschen mehr darüber weiß, wie RDBMS unter der Haube funktionieren.

Aber ich weiß nichts über multidimensionale OLAP-Datenmodelle, und ich hatte es schwer, nützliche Informationen im Internet zu finden.

Wie sind die Informationen auf der Festplatte gespeichert? Welche Datenstrukturen umfassen den Würfel? Wenn ein MOLAP-Modell keine Tabellen mit Spalten und Datensätzen verwendet, dann ... was? Insbesondere bei hochdimensionalen Daten, welche Arten von Datenstrukturen machen das MOLAP-Modell so effizient? Verwenden MOLAP-Implementierungen etwas analog zu RDBMS-Indizes?

Warum sind OLAP-Server bei der Verarbeitung von Ad-hoc-Abfragen so viel besser? Die gleichen Aggregationsarten, die Stunden benötigen, um in einer normalen relationalen Datenbank verarbeitet zu werden, können in Millisekunden in einem OLTP-Cube verarbeitet werden. Was sind die zugrunde liegenden Mechanismen des Modells, die das ermöglichen?

Answer 1

Ich habe ein paar Systeme implementiert, die OLAP-Cubes nachahmen, und hier sind ein paar Dinge, die wir getan haben, um sie zur Arbeit zu bringen.

1) Die Kerndaten wurden in einem n-dimensionalen Array gespeichert, alle im Speicher, und alle Schlüssel wurden über Hierarchien von Zeigern zum darunterliegenden Array implementiert. Auf diese Weise könnten wir mehrere verschiedene Sätze von Schlüsseln für die gleichen Daten haben. Die Daten in dem Array entsprachen der Faktentabelle, oft hatten sie nur ein paar Daten, in einem Fall waren dies Preis und Anzahl.

2) Das zugrundeliegende Array war oft spärlich, also verwendeten wir alle leeren Zellen, um Speicher zu sparen - viele harte Kernzeigerarithmetik, aber es funktionierte.

3) Da wir Schlüsselheerarchien hatten, konnten wir sehr einfach Routinen schreiben, um eine Hierarchie auf einfache Weise zu erweitern. Zum Beispiel würden wir auf das Jahr der Daten zugreifen, indem wir die Monate-Schlüssel durchlaufen, die wiederum auf Tage und/oder Wochen abgebildet werden. Auf jeder Ebene aggregierten wir die Daten als Teil der Erstellung der kubischen Berechnungen viel schneller.

4) Wir haben keine Abfragesprache implementiert, aber wir haben Drill Down auf allen Achsen (bis zu 7 in unseren größten Cubes) unterstützt, und das war direkt an die UI gebunden, die den Benutzern gefallen hat.

5) Wir haben Kernmaterial in C++ implementiert, aber in diesen Tagen denke ich, dass C# schnell genug sein könnte, aber ich würde mir Gedanken darüber machen, wie man Arrays mit Sparse implementieren kann.

Hoffnung, die hilft, klingen interessant.

Answer 2

Das Buch Microsoft SQL Server 2008 Analysis Services Unleashed buchstabiert einige der Besonderheiten von SSAS 2008 in dezenten Details. Es ist nicht ganz "hier ist genau, wie SSAS unter der Haube funktioniert", aber es ist ziemlich suggestiv, besonders auf der Datenstrukturseite. (Es ist nicht ganz so detailliert/spezifisch über die genauen Algorithmen.) Einige der Dinge, die ich als Amateur in diesem Bereich habe, stammen aus diesem Buch. Das ist alles über SSAS MOLAP:

• Trotz all des Geredes über multidimensionale Würfel, Faktentabelle (aka Gruppe messen) Daten sind nach wie vor, in erster Näherung, schließlich in grundsätzlich 2D-Tabellen gespeichert ist, eine Zeile pro Tatsache . Eine Anzahl von OLAP-Operationen besteht letztendlich darin, Zeilen in 2D-Tabellen zu durchlaufen.
• Die Daten sind in MOLAP möglicherweise viel kleiner als in einer entsprechenden SQL-Tabelle. Ein Trick besteht darin, dass jede eindeutige Zeichenkette nur einmal in einem "Zeichenkettenspeicher" gespeichert wird. Datenstrukturen können sich dann in einer kompakteren Form auf Strings beziehen (im Prinzip durch String-ID). SSAS komprimiert auch Zeilen in dem MOLAP-Speicher in irgendeiner Form. Dieses Schrumpfen nehme an, dass mehr Daten gleichzeitig im RAM bleiben, was gut ist.
• In ähnlicher Weise kann SSAS häufig über eine Teilmenge der Daten statt über den vollständigen Datensatz iterieren. Ein paar Mechanismen sind im Spiel:
  • Standardmäßig erstellt SSAS einen Hash-Index für jede Dimension/Attributwert; es weiß also "sofort", welche Seiten auf der Platte die relevanten Daten für beispielsweise Year = 1997 enthalten.
  • Es gibt eine Caching-Architektur, bei der relevante Teilmengen der Daten getrennt vom gesamten Datensatz im RAM gespeichert werden. Beispielsweise haben Sie möglicherweise einen Teilcache zwischengespeichert, der nur einige Ihrer Felder enthält und der sich nur auf die Daten von 1997 bezieht. Wenn eine Abfrage nur nach 1997 fragt, wird sie nur über diesen Teilcube iteriert, wodurch die Vorgänge beschleunigt werden . (Beachten Sie jedoch, dass ein "Teilcube" in erster Näherung nur eine 2D-Tabelle ist.)
  • Wenn Sie vordefinierte Aggregate sind, können diese kleineren Teilmengen auch vor der Cube-Verarbeitungszeit im Voraus berechnet und nicht nur berechnet/zwischengespeichert werden auf Nachfrage.
• SSAS Faktentabelle Zeilen sind feste Größe, die in irgendeiner Form vermutlich hilft. (In SQL dagegen haben Sie möglicherweise Zeichenfolgenspalten mit variabler Breite.)
• Die Caching-Architektur bedeutet auch, dass nach der Berechnung einer Aggregation diese nicht erneut von der Festplatte abgerufen und erneut berechnet werden muss.

Dies sind einige der Faktoren im Spiel in SSAS sowieso. Ich kann nicht behaupten, dass es auch andere lebenswichtige Dinge nicht gibt.