Magasins de colonnes: comparaison de bases de données en colonnes

Question

J'ai vraiment eu du mal à faire de SQL Server quelque chose que, franchement, il ne sera jamais. J'ai besoin d'un moteur de base de données pour mon travail analytique. Le DB doit être rapide et n'a pas besoin d'autant l'exploitation forestière et autres frais généraux trouvés dans les bases de données typiques (SQL Server, Oracle, DB2, etc.)

Hier j'ai écouté Michael Stonebraker speak at the Money:Tech conference et je pensais: « Je ne suis pas vraiment fou, il y a un meilleur moyen! Il parle d'utiliser column stores au lieu de bases de données orientées ligne. Je suis allé à la page Wikipedia pour column stores et je vois quelques projets open source (que j'aime) et quelques projets commerciaux/open source (que je ne comprends pas complètement).

Ma question est la suivante: Dans un environnement analytique appliqué, comment les différents DB basés sur les colonnes diffèrent-ils? Comment devrais-je penser à eux? Quelqu'un at-il une expérience pratique avec plusieurs systèmes basés sur des colonnes? Puis-je tirer parti de mon expérience SQL avec ces bases de données ou dois-je apprendre une nouvelle langue? Je vais finalement extraire des données dans R pour les analyser.

EDIT: On m'a demandé de clarifier ce que j'essaie exactement de faire. Donc, voici un exemple de ce que je voudrais faire: Créer une table qui a 4 millions de lignes et 20 colonnes (5 dims, 15 faits). Créez 5 tables d'agrégation qui calculent les valeurs max, min et average pour chacun des faits. Joignez ces 5 agrégations à la table de départ. Calculez maintenant le pourcentage d'écart par rapport à la moyenne, le pourcentage d'écart de min et le pourcentage d'écart par rapport à la valeur maximale pour chaque ligne et ajoutez-le à la table d'origine. Cette table n'obtient pas de nouvelles lignes chaque jour, elle est TOTALEMENT remplacée et le processus est répété. Que Dieu nous garde si le processus doit être arrêté. Et les journaux ... ohhhhh les journaux! :)

Answer 1

La réponse courte est que pour les données analytiques, un magasin de colonnes aura tendance à être plus rapide, avec moins d'accord nécessaire. Un magasin de lignes, l'architecture de base de données traditionnelle, permet d'insérer un petit nombre de lignes, de mettre à jour des lignes et d'interroger un petit nombre de lignes. Dans un magasin de lignes, ces opérations peuvent être effectuées avec une ou deux E/S de bloc de disque.

Les bases de données analytiques chargent généralement des milliers d'enregistrements à la fois; parfois, comme dans votre cas, ils rechargent tout. Ils ont tendance à être dénormalisés, donc ont beaucoup de colonnes. Et au moment de la requête, ils lisent souvent une forte proportion des lignes de la table, mais seulement quelques unes de ces colonnes. Donc, il est logique d'un point de vue E/S pour stocker les valeurs de la même colonne ensemble.

Il s'avère que cela donne à la base de données une énorme opportunité de faire de la compression de valeur. Par exemple, si une colonne de chaîne a une longueur moyenne de 20 octets mais n'a que 25 valeurs distinctes, la base de données peut compresser à environ 5 bits par valeur. Les bases de données de magasin de colonnes peuvent souvent fonctionner sans décompresser les données. Souvent, en informatique, il y a un compromis entre les E/S et le temps processeur, mais dans les mémoires de colonnes, les améliorations d'E/S améliorent souvent la localisation de référence, réduisent l'activité de pagination du cache et autorisent de plus grands facteurs de compression. . Les bases de données de colonnes ont également tendance à avoir d'autres fonctionnalités orientées analytiques comme les index bitmap (encore une autre cas où une meilleure organisation permet une meilleure compression, réduit les E/S, et permet des algorithmes plus efficaces), des partitions et matérialisées vues.

L'autre facteur consiste à utiliser ou non une base de données massivement parallèle (MMP). Il existe des bases de données de magasin de lignes MMP et de colonnes. Les bases de données MMP peuvent évoluer jusqu'à des centaines ou des milliers de nœuds et vous permettent de stocker des quantités énormes de données, mais ont parfois des compromis comme une notion plus faible de transactions ou un langage de requête pas tout à fait SQL.

Je vous recommande d'essayer LucidDB. (Disclaimer: Je suis un auteur pour LucidDB.) Il s'agit d'une base de données de librairies open-source, optimisée pour les applications analytiques, et dispose également d'autres fonctionnalités telles que les index bitmap. Il fonctionne actuellement sur un seul nœud, mais utilise plusieurs cœurs efficacement et peut gérer des volumes raisonnables de données sans trop d'efforts.

Answer 2

Cela ressemble à un changement d'implémentation (tableau 2-D dans l'ordre des colonnes, au lieu de l'ordre des lignes principales) plutôt qu'à un changement d'interface. Pensez à un modèle de «stratégie», plutôt que d'être un changement de paradigme complet. Bien sûr, je n'ai jamais utilisé ces produits, ils peuvent donc forcer un changement de paradigme dans votre gorge. Je ne sais pas pourquoi, cependant.

Answer 3

Nous serions peut-être mieux à même de vous aider à prendre une décision éclairée si vous décrivez [1] votre objectif spécifique et [2] les problèmes que vous rencontrez avec SQL Server.

Answer 4

J'ai de l'expérience avec Infobright Community edition --- column-or. db, basé sur mysql.

Pro:

• vous pouvez utiliser les interfaces mysql/odbc pilotes MySQL, de R aussi
• requêtes assez rapide sur de gros morceaux de sélection de données (en raison de paquets de données KnowledgeGrid &)
• très rapide chargeur de données natif et connecteurs pour ETL (talend, bouilloire)
• optimisé exactement que les opérations ce que je (et je pense que la plupart d'entre nous) utiliser (sélection par les niveaux de facteur, joindre etc)
• option "recherche" spéciale pour optimiser le stockage des variables de facteur R;) (ok, char/variables varchar avec le numéro/le nombre de lignes de niveau relativement faible)
• FOSS
• option de support payé
• ?

Moins:

• pas d'insertion/opérations de mise à jour dans l'édition communautaire (encore?), Chargement de données uniquement via des connecteurs chargeur de données natives/ETL
• pas utf-8 soutien officiel (collation/trier etc), prévu pour le troisième trimestre 2009
• aucune fonction dans l'ensemble des requêtes fe select month (date) from ...) encore, prévu pour juillet (?) 2009, mais en raison du stockage des colonnes, je préfère simplement créer des colonnes de date pour tous les niveaux d'agrégation (numéro de semaine, mois, ...) J'ai besoin
• ne peut pas installé sur le serveur mysql existant en tant que moteur de stockage (à cause de son propre optimiseur, si j'ai bien compris), mais vous pouvez installer Infobright & mysql sur différents ports si vous avez besoin
• ?

Bonne solution FOSS pour les tâches analytiques quotidiennes et, je pense, vos tâches aussi.

Answer 5

4 millions de lignes fois 20 colonnes fois 8 octets pour un double est de 640 mb. En suivant la règle empirique que R crée trois copies temporaires pour chaque objet, nous obtenons environ 2 Go. Ce n'est pas beaucoup par rapport à la norme d'aujourd'hui. Cela devrait donc être réalisable en mémoire sur une machine 64 bits appropriée avec une quantité de RAM «décente» (disons 8 Go ou plus). Installer Ubuntu ou Debian (éventuellement dans la version du serveur) peut être fait en quelques minutes.

Answer 6

Voici mes 2 cents: le serveur SQL ne se met pas bien à l'échelle. Nous avons tenté d'utiliser le serveur SQL pour stocker des données financières en temps réel (c'est-à-dire des coches de prix pour 100 symboles). Cela a fonctionné parfaitement pendant les deux premières semaines - puis il est allé de plus en plus lentement au fur et à mesure que la taille de la base de données augmentait, et finalement s'arrêtait, trop lent pour insérer chaque prix tel qu'il était reçu. Nous avons essayé de contourner ce problème en déplaçant les données de la base de données active vers le stockage hors ligne chaque nuit, mais finalement, le projet a été abandonné car il ne fonctionnait tout simplement pas.

Bottom line: si vous prévoyez de stocker beaucoup de données (> 1 Go), vous avez besoin de quelque chose qui évolue correctement, et cela signifie probablement une base de données de colonnes.