Mixage de bases de données orientées colonnes et lignes?

Question

J'essaie actuellement d'améliorer les performances d'une application web. Le but de l'application est de fournir (real time) analytics. Nous avons un modèle de base de données semblable à un star schema, peu de tables de faits et de nombreuses tables dimensionnelles. La base de données fonctionne avec le moteur Mysql et le moteur MyIsam.
La taille de la table Fact peut facilement atteindre les millions supérieurs et certaines tables de dimension peuvent également atteindre les millions.
Maintenant, le point est que les requêtes select peuvent être terriblement lentes si les tables de dimension sont jointes sur les tables de faits et que les agrégation sont effectuées. La première chose qui vient à l'esprit en entendant cela est, pourquoi ne pas précalculer les données? Cela n'est pas possible car les utilisateurs sont autorisés à utiliser plusieurs filtres librement personnalisables.

Donc, ce dont j'ai besoin est un système tout-en-un adapté à tous les usages;) Malheureusement, il n'a pas encore été inventé. J'ai donc eu l'idée de combiner 2 systèmes existants. Mélanger un row oriented et une base de données column oriented (par exemple, comme infinidb ou infobright). Conserver la solution mysql MyIsam (pour les insertions rapides et les requêtes par ligne) et ajouter une base de données orientée colonne (pour les opérations d'agrégation rapide sur quelques colonnes) et la remplir périodiquement (tous les soirs) via cronjob. Le problème serait lorsque les données actuelles (il doit être en temps réel) sont interrogées, donc je devrais peut-être obtenir des données des deux bases de données qui peuvent compliquer les choses.

Les premiers tests avec infinidb ont montré de très bonnes performances sur l'agrégation de quelques colonnes, donc je pense vraiment que cela pourrait m'aider à accélérer l'application. Donc, la question est: est-ce une bonne idée? Est-ce que quelqu'un a peut-être déjà fait ça? Peut-être qu'il y a de meilleures façons de le faire.

Je n'ai pas encore d'expérience dans les bases de données orientées colonnes et je ne sais pas non plus comment le schéma devrait ressembler. Les premiers tests ont montré de bonnes performances sur la même structure star schema like mais également dans une structure big table like.

J'espère que cette question correspond à SO.

Answer 1

GreenplumGreenplum, qui est une extension propriétaire de PostgreSQL (mais majoritairement libre dans la bière), prend en charge les tables orientées colonnes et orientées ligne avec une compression hautement personnalisable. En outre, vous pouvez mélanger les paramètres dans la même table si vous pensez que certaines parties subiront une charge transactionnelle importante alors que d'autres ne le feront pas. Par exemple, vous pouvez faire en sorte que l'année la plus récente soit orientée ligne et non compressée, l'année précédente en colonne et comprimée rapidement, et toutes les années historiques en colonnes et bz2 compressées. Greenplum est gratuit pour une utilisation sur des serveurs individuels, mais si vous avez besoin d'étendre ses fonctionnalités MPP (qui sont son principal argument de vente), il coûte beaucoup d'argent, car il cible les grandes entreprises.

(Disclaimer: Je fais affaire avec Greenplum professionnellement, mais seulement dans le cadre de l'évaluation de leur logiciel à l'achat.)

Quant à la question de savoir comment mettre en place le schéma, il est difficile de dire beaucoup sans En connaissant les détails de vos données, mais en général, avoir des tables axées sur les colonnes compressées devrait faire sortir toutes vos intuitions sur la conception de schéma par la fenêtre.

En particulier, la normalisation ne vaut presque jamais l'effort, et vous pouvez parfois obtenir de gros gains de performance en dénormalisant les niveaux de redondance limite-comique.Si les données ne rencontrent jamais le disque dans un état non compressé, vous pourriez ne pas vous soucier de répéter 40 000 fois le nom de chaque client. Les algorithmes de compression de Infobright sont conçus spécifiquement pour ce type d'application, et il n'est pas rare de se retrouver avec des ratios de 40 pour 1 entre les tailles logiques et physiques de vos tables.