Cosa rende i database colonnari adatti alla scienza dei dati?

Quali sono alcuni dei vantaggi degli archivi di dati colonnari che li rendono più adatti alla scienza e all'analisi dei dati?

Un database orientato alla colonna (= archivio dati colonnare) memorizza i dati di una tabella colonna per colonna sul disco, mentre un database orientato alla riga memorizza i dati di una tabella riga per riga.

Vi sono due vantaggi principali nell'utilizzo di un database orientato alle colonne rispetto a un database orientato alle righe. Il primo vantaggio riguarda la quantità di dati che uno deve leggere nel caso in cui eseguiamo un'operazione su poche funzionalità. Prendi in considerazione una semplice query:

SELECT correlation(feature2, feature5)
FROM records

Un esecutore tradizionale leggerebbe l'intera tabella (cioè tutte le funzionalità):

Invece, usando il nostro approccio basato su colonne, dobbiamo solo leggere le colonne che sono interessate a:

Il secondo vantaggio, che è anche molto importante per i database di grandi dimensioni, è che l'archiviazione basata su colonne consente una migliore compressione, poiché i dati in una colonna specifica sono effettivamente omogenei rispetto a tutte le colonne.

Lo svantaggio principale di un approccio orientato alle colonne è che la manipolazione (ricerca, aggiornamento o eliminazione) di un'intera riga è inefficiente. Tuttavia, la situazione dovrebbe verificarsi raramente nei database per l'analisi ("magazzinaggio"), il che significa che la maggior parte delle operazioni sono di sola lettura, raramente legge molti attributi nella stessa tabella e le scritture vengono solo aggiunte.

Alcuni RDMS offrono un'opzione di motore di archiviazione orientata alla colonna. Ad esempio, PostgreSQL non ha nativamente alcuna opzione per memorizzare le tabelle in modo basato su colonne, ma Greenplum ne ha creato uno chiuso (DBMS2, 2009). È interessante notare che Greenplum è anche dietro la libreria open source per l'analisi scalabile in-database, MADlib (Hellerstein et al., 2012), che non è una coincidenza. Più recentemente, CitusDB, una startup che lavora su database analitici ad alta velocità, ha rilasciato la propria estensione di archivio colonnare open source per PostgreSQL, CSTORE (Miller, 2014). Il sistema di Google per l'apprendimento automatico su larga scala Sibyl utilizza anche un formato dati orientato alle colonne (Chandra et al., 2010). Questa tendenza riflette il crescente interesse per lo storage orientato alle colonne per analisi su larga scala. Stonebraker et al. (2005) discutono ulteriormente i vantaggi del DBMS orientato alle colonne.

Due casi d'uso concreti: come vengono archiviati la maggior parte dei set di dati per l'apprendimento automatico su larga scala?

(la maggior parte della risposta proviene dall'Appendice C di: BeatDB: un approccio end-to-end per svelare salienze da enormi insiemi di dati di segnale. Franck Dernoncourt, SM, tesi, Dipartimento MIT di EECS )

Dipende da cosa fai.

I negozi di colonne hanno due vantaggi principali:

• intere colonne possono essere saltate
• la compressione run-length funziona meglio su colonne (per alcuni tipi di dati; in particolare con pochi valori distinti)

Tuttavia hanno anche degli svantaggi:

• molti algoritmi necessiteranno di tutte le colonne e registreranno solo alla volta (ad es. k-medie) o potrebbero anche aver bisogno di calcolare una matrice di distanza a coppie
• le tecniche di compressione funzionano bene solo su tipi e fattori di dati sparsi, ma non su dati continui a doppio valore
• gli appendi nei negozi di colonne sono costosi, quindi non è l'ideale per lo streaming / modifica dei dati

L'archiviazione a colonne è molto popolare per OLAP, noto anche come "stupid analytics" (Michael Stonebraker) e, naturalmente, per la preelaborazione in cui potresti essere effettivamente interessato a scartare intere colonne (ma per prima cosa dovresti avere dati strutturati: non memorizzi i file JSON in colonne formato). Perché il layout a colonne è davvero bello per esempio contando quante mele hai venduto la scorsa settimana.

Per gran parte dei casi di utilizzo di scienza scientifica / dei dati, i database di array sembrano essere la strada da percorrere (oltre, ovviamente, i dati di input non strutturati). Ad esempio SciDB e RasDaMan.

In molti casi (ad es. Apprendimento approfondito), le matrici e le matrici sono i tipi di dati necessari, non le colonne. MapReduce ecc. Può ancora essere utile nella pre-elaborazione, ovviamente. Forse anche i dati di colonna (ma il database di array di solito supporta anche una compressione simile a una colonna).

Non ho usato un database colonnare, ma ho usato un formato di file colonnare open source chiamato Parquet, e penso che i vantaggi siano probabilmente gli stessi - elaborazione dei dati più veloce quando hai solo bisogno di interrogare un piccolo sottoinsieme di un grande numero di colonne. Avevo una query in esecuzione su circa 50 terabyte di file Avro (un formato file orientato alle righe) con 673 colonne che impiegavano circa un'ora e mezza su un cluster Hadoop a 140 nodi. Con Parquet, la stessa query ha richiesto circa 22 minuti perché avevo bisogno solo di 5 colonne.

Se tu avessi un piccolo numero di colonne o usassi una grande proporzione delle tue colonne, non penso che un database colonnare farebbe molta differenza rispetto a uno orientato alle righe perché dovresti comunque scansionare sostanzialmente tutti i tuoi dati. Credo che i database colonnari memorizzino le colonne separatamente mentre i database orientati alle righe memorizzano le righe separatamente. La tua query sarà più veloce ogni volta che sarai in grado di leggere meno dati dal disco.

Questo link spiega ulteriori dettagli.

Nota: questa è la mia domanda, e sono davvero grato per le meravigliose risposte qui, che mi hanno aiutato a capire il concetto.

Quindi, vorrei spiegare il concetto nel modo in cui ho capito:

In genere, i dati nei database vengono archiviati nella memoria nei seguenti formati:

Considera questo dato:

           X1         X2
1   0.7091409 -1.4061361
2  -1.1334614 -0.1973846
3   2.3343391 -0.4385071

In un archivio basato su righe relazionale, viene archiviato in questo modo:

1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071 

sotto forma di righe.

Nel negozio colonnare, sarebbe memorizzato in questo modo:

1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071

sotto forma di colonne.

Che cosa significa questo?

Ciò significa che l'inserimento (e l'aggiornamento) e le eliminazioni sono veloci nell'archivio di colonne basato su righe poiché è solo la rimozione degli ultimi valori o dei primi valori. Tuttavia, non è il caso nei negozi a colonne in quanto è necessario rimuovere il valore in ciascun negozio a blocchi.

Tuttavia, quando vi è la necessità di aggregati e operazioni colonnari, i negozi colonnari hanno un vantaggio rispetto alle loro controparti basate su righe, poiché sono archiviati in base alle colonne e, di conseguenza, l'accesso alle singole colonne è molto semplice.