Qu'est-ce qui rend les bases de données en colonnes adaptées à la science des données?

Quels sont les avantages des magasins de données en colonnes qui les rendent plus adaptés à la science des données et à l'analyse?

Une base de données orientée colonne (= magasin de données en colonnes) stocke les données d'une table colonne par colonne sur le disque, tandis qu'une base de données orientée ligne stocke les données d'une table ligne par ligne.

Il existe deux avantages principaux à utiliser une base de données orientée colonne par rapport à une base de données orientée ligne. Le premier avantage concerne la quantité de données à lire au cas où nous effectuerions une opération sur quelques fonctionnalités seulement. Considérez une requête simple:

SELECT correlation(feature2, feature5)
FROM records

Un exécuteur traditionnel lirait la table entière (c'est-à-dire toutes les fonctionnalités):

Au lieu de cela, en utilisant notre approche basée sur les colonnes, nous n'avons qu'à lire les colonnes qui sont intéressées par:

Le deuxième avantage, qui est également très important pour les grandes bases de données, est que le stockage basé sur les colonnes permet une meilleure compression, car les données d'une colonne spécifique sont en effet homogènes par rapport à toutes les colonnes.

Le principal inconvénient d'une approche orientée colonne est que la manipulation (recherche, mise à jour ou suppression) d'une ligne donnée entière est inefficace. Cependant, la situation devrait se produire rarement dans les bases de données pour l'analyse («entreposage»), ce qui signifie que la plupart des opérations sont en lecture seule, lisent rarement de nombreux attributs dans la même table et les écritures ne sont que des annexes.

Certains RDMS offrent une option de moteur de stockage orienté colonnes. Par exemple, PostgreSQL n'a nativement aucune option pour stocker les tables en mode colonne, mais Greenplum en a créé une à source fermée (DBMS2, 2009). Fait intéressant, Greenplum est également à l'origine de la bibliothèque open-source d'analyse évolutive en base de données, MADlib (Hellerstein et al., 2012), ce qui n'est pas un hasard. Plus récemment, CitusDB, une startup travaillant sur une base de données analytique à haute vitesse, a publié sa propre extension de magasin en colonnes open-source pour PostgreSQL, CSTORE (Miller, 2014). Le système de Google pour l'apprentissage automatique à grande échelle Sibyl utilise également un format de données orienté colonnes (Chandra et al., 2010). Cette tendance reflète l'intérêt croissant pour le stockage orienté colonne pour les analyses à grande échelle. Stonebraker et al. (2005) discutent davantage des avantages du SGBD orienté colonnes.

Deux cas d'utilisation concrets: comment sont stockés la plupart des ensembles de données pour l'apprentissage automatique à grande échelle?

(la plupart des réponses proviennent de l'annexe C de: BeatDB: une approche de bout en bout pour dévoiler les saillies des ensembles de données de signaux massifs. Franck Dernoncourt, SM, thèse, MIT Dept of EECS )

Cela dépend de ce que vous faites.

Les magasins à colonnes présentent deux avantages clés:

• des colonnes entières peuvent être ignorées
• la compression de la longueur d'exécution fonctionne mieux sur les colonnes (pour certains types de données; en particulier avec peu de valeurs distinctes)

Cependant, ils présentent également des inconvénients:

• de nombreux algorithmes nécessiteront toutes les colonnes et n'enregistreront qu'à la fois (par exemple k-means) ou peuvent même avoir besoin de calculer une matrice de distance par paire
• les techniques de compression ne fonctionnent bien que sur des types et des facteurs de données clairsemés, mais pas sur des données continues à double valeur
• les ajouts sur les magasins de colonnes sont chers, il n'est donc pas idéal pour le streaming / changement de données

Le stockage en colonnes est très populaire pour OLAP aka "stupid analytics" (Michael Stonebraker) et bien sûr pour le prétraitement où vous pouvez en effet être intéressé à supprimer des colonnes entières (mais vous devez d'abord avoir des données structurées - vous ne stockez pas les JSON dans les colonnes format). Parce que la disposition en colonnes est vraiment sympa, par exemple pour compter le nombre de pommes que vous avez vendues la semaine dernière.

Pour la plupart des cas d'utilisation de la science / science des données, les bases de données de tableaux semblent être le chemin à parcourir (plus, bien sûr, les données d'entrée non structurées). Par exemple SciDB et RasDaMan.

Dans de nombreux cas (par exemple, apprentissage en profondeur), les matrices et les tableaux sont les types de données dont vous avez besoin, pas les colonnes. MapReduce etc. peut toujours être utile dans le prétraitement, bien sûr. Peut-être même des données de colonnes (mais la base de données de tableaux prend généralement en charge également une compression de type colonne).

Je n'ai pas utilisé de base de données en colonnes, mais j'ai utilisé un format de fichier en colonnes open source appelé Parquet, et je pense que les avantages sont probablement les mêmes - un traitement plus rapide des données lorsque vous avez seulement besoin d'interroger un petit sous-ensemble d'un grand le nombre de colonnes. J'ai eu une requête en cours d'exécution sur environ 50 téraoctets de fichiers Avro (un format de fichier orienté ligne) avec 673 colonnes qui ont pris environ une heure et demie sur un cluster Hadoop à 140 nœuds. Avec Parquet, la même requête a pris environ 22 minutes car je n'avais besoin que de 5 colonnes.

Si vous aviez un petit nombre de colonnes ou utilisiez une grande partie de vos colonnes, je ne pense pas qu'une base de données en colonnes ferait une grande différence par rapport à une base orientée ligne, car vous auriez encore à analyser essentiellement toutes vos données. Je crois que les bases de données en colonnes stockent les colonnes séparément tandis que les bases de données orientées lignes stockent les lignes séparément. Votre requête sera plus rapide chaque fois que vous pourrez lire moins de données sur le disque.

Ce lien explique plus de détails.

Remarque: Ceci est ma question, et je suis vraiment reconnaissant pour les merveilleuses réponses ici, qui m'ont aidé à saisir le concept.

Donc, j'expliquerais le concept de la façon dont j'ai compris:

Généralement, les données des bases de données sont stockées dans la mémoire dans les formats suivants:

Considérez cette donnée:

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

Dans un magasin relationnel basé sur des lignes, il est stocké comme suit:

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

sous forme de lignes.

Dans le magasin en colonnes, il serait stocké comme ceci:

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

sous forme de colonnes.

Qu'est-ce que cela signifie?

Cela signifie que l'insertion (et la mise à jour) et les suppressions sont rapides dans le magasin de colonnes basé sur les lignes car il s'agit simplement de la suppression des dernières valeurs ou des premières valeurs. Cependant, ce n'est pas le cas dans les magasins en colonnes car la valeur de chaque magasin de blocs doit être supprimée.

Cependant, lorsqu'il existe un besoin d'agrégats et d'opérations en colonnes, les magasins en colonnes ont un avantage sur leurs homologues basés sur les lignes, car ils sont stockés en colonnes, et en conséquence, l'accès aux colonnes individuelles est très facile.