Qualcuno sa niente di OLAP Internals?

Question

Lo so un po 'di interni di database. In realtà ho implementato un piccolo, semplice motore di database relazionale prima, utilizzando strutture ISAM su disco e indici BTree e tutto quel genere di cose. E 'stato divertente, e molto educativo. So che io sono molto più consapevoli sulla progettazione con attenzione gli schemi di database e scrivere query ora che conosco un po 'di più sul lavoro come RDBMS sotto il cofano.

Ma io non so nulla di modelli di dati multidimensionali OLAP, e ho avuto difficoltà a trovare tutte le informazioni utili su Internet.

Come le informazioni memorizzate sul disco? Quali strutture di dati comprendono il cubo? Se un modello MOLAP non usa le tabelle, con le colonne e le registrazioni, allora ... che cosa? Soprattutto in dati altamente dimensionali, quali tipi di strutture di dati rendono il modello MOLAP in modo efficiente? Fare implementazioni MOLAP usano qualcosa di analogo per gli indici RDBMS?

Perché sono server OLAP molto meglio a elaborazione query ad hoc? Lo stesso tipo di aggregazioni che potrebbero prendere ore per elaborare in un database relazionale ordinaria possono essere elaborati in millisecondi in un cubo OLTP. Quali sono i meccanismi alla base del modello che rendono possibile?

Answer 1

Ho implementato un paio di sistemi che mimiced cosa cubi OLAP fare, e qui sono un paio di cose che abbiamo fatto per farli funzionare.

1) I dati di nucleo è tenuta in una matrice n dimensionale, tutto in memoria, e tutti i tasti sono stati attuati attraverso gerarchie di puntatori nella matrice sottostante. In questo modo potremmo avere più insiemi differenti di chiavi per gli stessi dati. I dati dell'array era l'equivalente del tavolo fatto, spesso avrebbe solo un paio di pezzi di dati, in un caso che questo era il prezzo e il numero composto.

2) La matrice di fondo era spesso scarsa, quindi una volta che è stato creato che abbiamo usato per rimuovere tutte le celle vuote per risparmiare memoria - un sacco di hard core aritmetica dei puntatori ma ha funzionato

.

3) Come abbiamo avuto gerarchie di chiavi, potremmo scrivere routine abbastanza facilmente di drill-down / up una gerarchia facilmente. Per esempio vorremmo accedere anno di dati, passando attraverso i tasti mesi, che a sua volta mappati per giorni e / o settimane. Ad ogni livello ci sarebbe aggregare i dati come parte della costruzione del cubo -. Calcoli fatti molto più veloce

4) Non abbiamo realizzare qualsiasi tipo di linguaggio di interrogazione, ma il supporto abbiamo approfondire nei dettagli tutti gli assi (fino a 7 nei nostri più grandi cubi), e che è stato legato direttamente all'interfaccia utente, che gli utenti volevano.

5) Abbiamo implementato roba di base in C ++, ma in questi giorni mi sa C # potrebbe essere abbastanza veloce, ma mi piacerebbe preoccupiamo di come implementare le matrici sparse.

Speranza che aiuta, il suono interessante.

Answer 2

Il libro Microsoft SQL Server 2008 Analysis Services Unleashed enuncia alcuni dei particolarità di SSAS 2008 in dettaglio decente. Non è un bel "qui è esattamente come funziona SSAS sotto il cofano", ma è piuttosto suggestiva, soprattutto sul lato struttura di dati. (Non è abbastanza dettagliata / specifiche sui algoritmi esatti.) Alcune delle cose che, come un dilettante in questo settore, raccolti da questo libro. Questo è tutto su SSAS MOLAP:

• Nonostante tutto il parlare cubi multidimensionali, tabella dei fatti (alias gruppo di misure) dati sono ancora, in prima approssimazione, infine memorizzati nelle tabelle fondamentalmente 2D, una riga per fatto. Un numero di operazioni OLAP sembrano consistere in definitiva di iterazione sulle righe nelle tabelle 2D.
• I dati sono potenzialmente molto piccolo all'interno MOLAP che in una corrispondente tabella SQL, tuttavia. Un trucco è che ogni stringa univoca viene memorizzata solo una volta, in un "negozio stringa". Strutture dati possono quindi fare riferimento a stringhe in una forma più compatta (per ID di stringa, in fondo). SSAS comprime anche righe all'interno del negozio MOLAP in qualche forma. Questa contrazione Presumo lascia più del soggiorno dei dati nella RAM contemporaneamente, il che è positivo.
• Allo stesso modo, SSAS spesso può iterare su un sottoinsieme dei dati, piuttosto che il set di dati completo. Alcuni meccanismi sono in gioco:
  • Per impostazione predefinita, SSAS costruisce un indice di hash per ogni valore di quota / attributo; sa quindi "subito", che le pagine sul disco contengono i dati rilevanti per, diciamo, Anno = 1997.
  • C'è un'architettura di caching in cui importanti sottoinsiemi di dati sono memorizzati in RAM separata dal tutto dataset. Ad esempio, si potrebbe avere un sottocubo nella cache che ha solo alcuni dei vostri campi, e che riguarda solo i dati a partire dal 1997. Se una query sta chiedendo solo circa 1997, allora sarà iterare solo su quella sottocubo, accelerando così le cose . (Ma si noti che un "sottocubo" è, in prima approssimazione, solo un tavolo 2D.)
  • Se sei aggregati predefiniti, quindi questi sottoinsiemi più piccoli possono anche essere pre-calcolate in fase di elaborazione del cubo, piuttosto che semplicemente calcolato / cache su richiesta.
righe della tabella
• SSAS infatti sono fissate dimensioni, che aiuta presumibly in qualche forma. (In SQL, in constrast, si potrebbe avere larghezza variabile colonne stringa.)
• L'architettura caching significa anche che, una volta che un aggregato è stata calcolata, non ha bisogno di essere refetched dal disco e ricalcolati ripetutamente.

Questi sono alcuni dei fattori in gioco in SSAS comunque. Non posso affermare che non ci sono altre cose di vitale importanza come bene.