Constant Konan, consultant avant-vente Sybase
Jusqu’à présent, les performances des cubes OLAP primaient sur ces handicaps, et, bien qu’il soit possible d’organiser les données de façon multidimensionnelle dans une base de données relationnelle, cette approche par cubes (MOLAP) l’emportait très largement. Par définition, un cube OLAP stocke un périmètre synthétique de données puis précalcule et sauvegarde toutes les combinatoires associées : c’est la matérialisation des données. Toutes les réponses aux questions potentielles des utilisateurs sont alors directement disponibles dans le système et les performances sont par conséquent inégalables. En revanche, il existe d’évidentes limitations en termes d’exploration (pas d’accès aux données de détail), de fraîcheur des données (les valeurs datent du dernier chargement) et de flexibilité.
Assez tôt, les fournisseurs de cubes ont pris conscience de ces faiblesses en permettant à leurs produits de tirer profit de la puissance croissante des bases de données relationnelles. Ainsi, depuis de nombreuses années, il est possible d’interfacer un cube avec un moteur relationnel de façon à ne matérialiser que partiellement les données du cube, voire pas du tout, auquel cas le cube sert essentiellement de support de présentation et de filtre. Mais, malgré sa faisabilité, le couplage des cubes OLAP avec les bases de données relationnelles n’a jamais vraiment convaincu en raison de performances insuffisantes. Toutefois, la tendance actuelle de l’industrie et des clients à s’orienter vers des bases de données en colonnes pour un usage décisionnel opère un net rééquilibrage.
Il n’existe que deux façons de stocker des tables (à deux dimensions) sur un support informatique forcément unidimensionnel : soit ligne à ligne, soit colonne par colonne. Ces deux options possèdent chacune leur intérêt en fonction du type d’application considéré. Historiquement, la majorité des applications étant de nature transactionnelle, ce sont les bases de données en ligne qui ont été privilégiées car elles s’accordent très bien à cet usage. Mais pour les applications décisionnelles, qui nécessitent de parcourir un très grand nombre d’enregistrements, le stockage en colonne est nettement plus efficace, offrant des performances jusqu’à cinquante fois supérieures. Et la complexité croissante des applications décisionnelles ne fait qu’amplifier ce ratio.
Optimisées pour la lecture (indexation totale) et le chargement en masse des données, les bases de données en colonnes actuelles redonnent dès lors un véritable choix entre les architectures décisionnelles, MOLAP et ROLAP essentiellement, et, dans biens des situations, la combinaison cubes et bases en colonnes impose ses avantages.
Dans l’approche MOLAP, on tire bénéfice de la conception des SGBD en colonnes pour des traitements analytiques sur de forts volumes, ce qui permet de déporter tout ou partie des calculs du cube vers la base. En outre, leurs bonnes performances accroissent les possibilités de drill-through, c’est-à-dire d’accès aux données de détail depuis le cube. Ainsi, l’utilisateur bénéficie de données à jour, plus fines, ce qui lui permet des analyses, des simulations et des planifications plus précises.
L’approche ROLAP (Relational OLAP) permet quant à elle de pallier les limites de volumes caractéristiques du cube en raccordant directement celui-ci au data warehouse. Dans ce type de configuration, une base de données en colonnes permet d’héberger un volume de données quasi-illimité tout en garantissant des temps de réponse satisfaisants. Les développements les plus récents des cubes OLAP portent précisément sur l’amélioration et l’extension du mode ROLAP car cette approche permet de conserver la même ergonomie pour l’utilisateur tout en lui ouvrant un périmètre de données bien plus vaste et perpétuellement à jour.
Pour les applications qui réclament une performance maximale, ou celles dont les indicateurs sont bien connus (communications financières, rapports d’activité…), les cubes demeurent pertinents et les bases en colonnes viennent alors les renforcer en apportant une réponse à certains enjeux d’accès aux données et d’exploitation. L’utilisateur gagne en richesse (In-Database Analytics, exploration détaillée), en précision (données à jour, échantillons élargis) et en souplesse (requêtes libres, évolutivité). Quant à l’informatique, elle tire des bénéfices significatifs : outils moins coûteux, infrastructures plus légères, ressources moins nombreuses, compétences plus courantes, architecture plus lisible et évolutive… Globalement, la mise en œuvre est plus économique et les risques sont mieux maîtrisés.
En permettant ainsi de résoudre certaines contraintes liées aux cubes, les bases de données en colonnes redonnent la priorité aux exigences métier dans le choix de l’architecture décisionnelle. Leur utilisation permet de replacer les besoins utilisateur et l’exploitation des données au centre des préoccupations, et, en somme de revenir à l’essence de l’OLAP.
Assez tôt, les fournisseurs de cubes ont pris conscience de ces faiblesses en permettant à leurs produits de tirer profit de la puissance croissante des bases de données relationnelles. Ainsi, depuis de nombreuses années, il est possible d’interfacer un cube avec un moteur relationnel de façon à ne matérialiser que partiellement les données du cube, voire pas du tout, auquel cas le cube sert essentiellement de support de présentation et de filtre. Mais, malgré sa faisabilité, le couplage des cubes OLAP avec les bases de données relationnelles n’a jamais vraiment convaincu en raison de performances insuffisantes. Toutefois, la tendance actuelle de l’industrie et des clients à s’orienter vers des bases de données en colonnes pour un usage décisionnel opère un net rééquilibrage.
Il n’existe que deux façons de stocker des tables (à deux dimensions) sur un support informatique forcément unidimensionnel : soit ligne à ligne, soit colonne par colonne. Ces deux options possèdent chacune leur intérêt en fonction du type d’application considéré. Historiquement, la majorité des applications étant de nature transactionnelle, ce sont les bases de données en ligne qui ont été privilégiées car elles s’accordent très bien à cet usage. Mais pour les applications décisionnelles, qui nécessitent de parcourir un très grand nombre d’enregistrements, le stockage en colonne est nettement plus efficace, offrant des performances jusqu’à cinquante fois supérieures. Et la complexité croissante des applications décisionnelles ne fait qu’amplifier ce ratio.
Optimisées pour la lecture (indexation totale) et le chargement en masse des données, les bases de données en colonnes actuelles redonnent dès lors un véritable choix entre les architectures décisionnelles, MOLAP et ROLAP essentiellement, et, dans biens des situations, la combinaison cubes et bases en colonnes impose ses avantages.
Dans l’approche MOLAP, on tire bénéfice de la conception des SGBD en colonnes pour des traitements analytiques sur de forts volumes, ce qui permet de déporter tout ou partie des calculs du cube vers la base. En outre, leurs bonnes performances accroissent les possibilités de drill-through, c’est-à-dire d’accès aux données de détail depuis le cube. Ainsi, l’utilisateur bénéficie de données à jour, plus fines, ce qui lui permet des analyses, des simulations et des planifications plus précises.
L’approche ROLAP (Relational OLAP) permet quant à elle de pallier les limites de volumes caractéristiques du cube en raccordant directement celui-ci au data warehouse. Dans ce type de configuration, une base de données en colonnes permet d’héberger un volume de données quasi-illimité tout en garantissant des temps de réponse satisfaisants. Les développements les plus récents des cubes OLAP portent précisément sur l’amélioration et l’extension du mode ROLAP car cette approche permet de conserver la même ergonomie pour l’utilisateur tout en lui ouvrant un périmètre de données bien plus vaste et perpétuellement à jour.
Pour les applications qui réclament une performance maximale, ou celles dont les indicateurs sont bien connus (communications financières, rapports d’activité…), les cubes demeurent pertinents et les bases en colonnes viennent alors les renforcer en apportant une réponse à certains enjeux d’accès aux données et d’exploitation. L’utilisateur gagne en richesse (In-Database Analytics, exploration détaillée), en précision (données à jour, échantillons élargis) et en souplesse (requêtes libres, évolutivité). Quant à l’informatique, elle tire des bénéfices significatifs : outils moins coûteux, infrastructures plus légères, ressources moins nombreuses, compétences plus courantes, architecture plus lisible et évolutive… Globalement, la mise en œuvre est plus économique et les risques sont mieux maîtrisés.
En permettant ainsi de résoudre certaines contraintes liées aux cubes, les bases de données en colonnes redonnent la priorité aux exigences métier dans le choix de l’architecture décisionnelle. Leur utilisation permet de replacer les besoins utilisateur et l’exploitation des données au centre des préoccupations, et, en somme de revenir à l’essence de l’OLAP.
Autres articles
-
L’USF lance un appel aux clients Sybase pour qu’ils rejoignent l’association indépendante des utilisateurs SAP
-
Sybase et KXEN vont plus loin dans l’analyse de données avec le ‘Social Network Analysis’ - SNA (Analyse des Réseaux Sociaux)
-
KXEN annonce la certification d’InfiniteInsight pour Sybase IQ v.15
-
Sybase se moque de la tendance "big data"
-
Piloter vos analyses décisionnelles à la voix