Archivi colonne: confronto dei database basati su colonne

Question

Ho davvero faticato a rendere SQL Server in qualcosa che, francamente, non lo sarà mai. Ho bisogno di un motore di database per il mio lavoro analitico. Il DB deve essere veloce e NON ha bisogno di tutte le registrazioni e altri sovraccarichi trovati nei database tipici (SQL Server, Oracle, DB2, ecc.)

Ieri ho ascoltato Michael Stonebraker speak at the Money:Tech conference e ho continuato a pensare: "Non sono veramente pazzo, c'è un modo migliore! " Parla dell'uso di column stores invece dei database orientati alle righe. Sono andato alla pagina di Wikipedia per column stores e vedo alcuni progetti open source (che mi piacciono) e alcuni progetti commerciali/open source (che non comprendo appieno).

La mia domanda è questa: in un ambiente analitico applicato, come differiscono i diversi DB basati su colonne? Come dovrei pensare a loro? Qualcuno ha esperienza pratica con più sistemi basati su colonne? Posso sfruttare la mia esperienza SQL con questi DB o dovrò imparare una nuova lingua?

Alla fine sto per inserire i dati in R per l'analisi.

MODIFICA: Sono stato richiesto per alcuni chiarimenti in cosa esattamente sto cercando di fare. Quindi, ecco un esempio di cosa vorrei fare: Creare una tabella che abbia 4 milioni di righe e 20 colonne (5 dim, 15 fatti). Crea 5 tabelle di aggregazione che calcolano il massimo, il minimo e la media per ciascuno dei fatti. Unisci quelle 5 aggregazioni alla tabella di partenza. Calcolare ora la deviazione percentuale dalla media, la deviazione percentuale di min e la deviazione percentuale dal massimo per ogni riga e aggiungerla alla tabella originale. I dati di questa tabella non ricevono nuove righe ogni giorno, vengono TOTALMENTE sostituiti e il processo viene ripetuto. Il cielo non vuole se il processo deve essere fermato. E i registri ... ohhhhh i registri! :)

Answer 1

La risposta breve è che per i dati analitici, un archivio colonne tenderà ad essere più veloce, con meno accordature richieste.

Un archivio di righe, l'architettura di database tradizionale, è in grado di inserire un numero ridotto di righe, aggiornare le righe in posizione e interrogare un numero limitato di righe. In un archivio di righe, queste operazioni possono essere eseguite con uno o due I/O di blocco del disco.

I database analitici caricano in genere migliaia di record alla volta; a volte, come nel tuo caso, ricaricano tutto. Tendono ad essere denormalizzati, quindi hanno un sacco di colonne. E al momento della query, spesso leggono un'alta proporzione delle righe nella tabella, ma solo alcune di queste colonne. Quindi, ha senso da un punto di vista I/O per memorizzare insieme i valori della stessa colonna.

Si scopre che questo offre al database un'enorme opportunità per eseguire la compressione del valore. Ad esempio, se una colonna di stringhe ha una lunghezza media di 20 byte ma ha solo 25 valori distinti, il database può comprimere a circa 5 bit per valore. I database degli archivi di colonne possono spesso funzionare senza decomprimere i dati.

Spesso in informatica non è un I/O rispetto al tempo di CPU compromesso, ma nei negozi colonna dei miglioramenti di I/O spesso migliorano località di riferimento, riducono l'attività di paging cache e consentire una maggiore fattori di compressione, in modo che i guadagni della CPU anche .

I database degli archivi di colonne tendono anche ad avere altre funzionalità orientate all'analisi come gli indici bitmap (ancora un altro caso in cui un'organizzazione migliore consente una compressione migliore, riduce l'I/O e consente algoritmi più efficienti in termini di CPU), partizioni e materializzati visualizzazioni.

L'altro fattore è se utilizzare un database MMP (massively parallel). Vi sono database di archivio di righe e archivi di colonne MMP. I database MMP possono scalare fino a centinaia o migliaia di nodi e consentono di memorizzare quantità enormi di dati, ma a volte hanno compromessi come una nozione più debole di transazioni o un linguaggio di query non-abbastanza-SQL.

Ti consiglio di provare LucidDB. (Disclaimer: Sono un committer di LucidDB.) È un database di archivio di colonne open source, ottimizzato per applicazioni di analisi e ha anche altre caratteristiche come gli indici di bitmap. Attualmente funziona solo su un nodo, ma utilizza diversi core in modo efficace e può gestire volumi di dati ragionevoli con poco sforzo.

Answer 2

Sembra una modifica di implementazione (matrice 2-D in ordine di colonna principale, invece di ordine di riga maggiore), piuttosto che una modifica dell'interfaccia.

Pensare al modello "strategia", piuttosto che essere un intero cambiamento di paradigma. Naturalmente, non ho mai usato questi prodotti, quindi potrebbero forzare un cambio di paradigma in gola. Non so perché, però.

Answer 3

Potremmo essere in grado di aiutarti a prendere una decisione informata se hai descritto [1] il tuo obiettivo specifico e [2] i problemi che stai incontrando con SQL Server.

Answer 4

Ho una certa esperienza con l'edizione della community di Infobright --- column-or. db, basato su mysql.

Pro:

• è possibile utilizzare le interfacce MySQL/driver ODBC di MySQL, da R anche
• abbastanza domande veloci su grandi blocchi di selezione dei dati (a causa della KnowledgeGrid pacchetti di dati &)
• molto veloce caricatore dati nativo e connettori per ETL (talend, bollitore)
• ottimizzato esattamente le operazioni che uso io (e penso che la maggior parte di noi) (selezione per livello di fattore, unione ecc.)
• speciale opzione di "ricerca" per ottimizzati memorizzazione variabili fattore R;) (ok, variabili char/varchar con relativamente piccolo livelli/numero righe)
• FOSS
• pagato all'opzione supporto
• ?

Contro:

• nessuna operazione di inserimento/aggiornamento in Community Edition (ancora?), Il caricamento dei dati solo tramite nativi connettori dati caricatore/ETL
• non UTF-8 il supporto ufficiale (collazione/sort ecc.), previsto per il terzo trimestre 2009
• nessuna funzione nelle query aggregate selezionare il mese (data) da ...) ancora, pianificato per luglio (?) 2009, ma a causa dell'archiviazione delle colonne, preferisco semplicemente creare colonne di date per ogni livello di aggregazione (numero della settimana, mese, ...) Ho bisogno di
• non può essere installato sul server mysql esistente come motore di archiviazione (a causa del proprio ottimizzatore, se ho capito correttamente), ma è possibile installare Infobright & mysql su porte diverse se è necessario
• ?

Ripresa: Buona soluzione FOSS per le attività analitiche quotidiane e, penso, anche le attività.

Answer 5

4 milioni di righe volte 20 colonne volte 8 byte per un doppio è 640 mb. Seguendo la regola generale che R crea tre copie temporanee per ogni oggetto, arriviamo a circa 2 GB. Questo non è molto per lo standard di oggi.

Quindi questo dovrebbe essere possibile eseguire in memoria su una macchina a 64 bit adatta con una quantità "decente" di ram (ad esempio 8 GB o più). L'installazione di Ubuntu o Debian (possibilmente nella versione server) può essere eseguita in pochi minuti.

Answer 6

Ecco i miei 2 centesimi: il server SQL non scala bene. Abbiamo tentato di utilizzare il server SQL per archiviare i dati finanziari in tempo reale (ovvero i tick di prezzi in arrivo per 100 simboli). Ha funzionato perfettamente per le prime 2 settimane - poi è andato più lentamente e più lentamente quando le dimensioni del database sono aumentate, e finalmente fermato, troppo lento per inserire ogni prezzo come è stato ricevuto. Abbiamo cercato di aggirarlo spostando i dati dal database attivo allo storage offline tutte le sere, ma alla fine il progetto è stato abbandonato in quanto non funzionava.

In conclusione: se si prevede di archiviare molti dati (> 1 GB), è necessario disporre di una soluzione che si adatti in modo corretto e che probabilmente significhi un database di colonne.