Gérer les entrepôts de données avec MySQL


Gérer les entrepôts de données avec MySQL

 

Copyright © 2008, MySQL AB Gérer les entrepôts de données avec MySQL Un livre blanc MySQL® Copyright © 2008, MySQL AB Page 2 sur 18 Table des matières 1 INTRODUCTION ....................................................................................................................3 2 UN EXAMEN DU TRAFIC DES ENTREPOTS DE DONNEES ..............................................4 2.1 Analyse des types d?utilisation des entrepôts de données.........................................................................4 2.2 Les défis à venir pour la gestion des entrepôts de données ......................................................................5 3 QU?EST QUE MYSQL?..........................................................................................................6 4 LA STRATEGIE DE MYSQL POUR LES ENTREPOTS DE DONNEES...............................6 4.1 Le schéma technique de l?entrepôt de données chez MySQL ....................................................................7 4.1.1 Open Source signifie un maximum d?innovation ........................................................................................7 4.1.2 L?ensemble des fonctions de base de MySQL facilitant la gestion d?entrepôts de données......................7 4.1.3 Une architecture visionnaire pour l?entrepôt de données ...........................................................................8 4.1.4 Les moteurs de stockage internes de MySQL pour les entrepôts de données........................................10 4.1.5 Les moteurs de stockage externes pour l?entrepôt de données...............................................................11 4.1.6 Tableau de comparaison des moteurs de stockage MySQL pour la gestion des entrepôts de données 12 4.2 Le scale out des entrepôts de données avec MySQL................................................................................14 4.3 Le réseau des partenaires MySQL en informatique décisionnelle ...........................................................15 4.4 Examen du Coût Total de Possession des entrepôts de données MySQL .............................................16 5 ETUDE DE CAS...................................................................................................................18 6 CONCLUSION......................................................................................................................18 Copyright © 2008, MySQL AB Page 3 sur 18 1 Introduction Les entreprises modernes qui mènent le jeu réalisent l?importance cruciale de disposer des informations adéquates pour pouvoir prendre les décisions stratégiques guidant la conduite de l?entreprise. Dans ces conditions, il n?est pas surprenant qu?une enquête du Gartner Group ait souligné en 2006 que les DSI plaçaient l?informatique décisionnelle (Business Intelligence ? BI) en tant que priorité technologique numéro deux, quand elle n?était que dixième il y a trois ans seulement. 1 Cette préoccupation a été confirmée par une enquête effectuée en 2007 par InformationWeek qui a révélé que près de la moitié des décideurs informatiques prévoyaient d?augmenter leur budget de BI au-dessus du niveau de 2006. 2 Ces tendances montrent clairement que les entreprises avisées prennent conscience que leur capacité à être compétitif dépend fortement de leur utilisation judicieuse de la technologie et de l?information, que ce soit pour permettre à leurs clients de mieux communiquer, établir des relations, partager et localiser des informations, ou pour acheter des biens et services de façon plus efficace. Toutefois, cette recherche d?une information plus abondante et de meilleure qualité pour faciliter les décisions a amené un certain nombre de défis intéressants. En premier lieu, le volume d?informations géré par les entrepôts de données d?entreprise devient en lui-même un problème clé. Analysant une enquête menée en 2006 par son cabinet, Philip Russom, directeur de la recherche chez TDWI, a affirmé : ?Les entrepôts de données vont subir une croissance moyenne annuelle de 33% en ce qui concerne leur volume de données, voire même 50% minimum lorsqu?ils sont confrontés à de fortes exigences en matière de données clients, de chaîne logistique, d?e-commerce ou de gestion de conformité des données.? 3 Cette même enquête a révélé que l?on comptait 36% d?entrepôts de données multi téraoctets en 2006 et que 48% le deviendraient avant la fin de 2007. En second lieu, l?appétit croissant pour l?informatique décisionnelle a induit des types d?utilisation spécialisés d?entrepôts de données (des schémas différents de croissance et d?utilisation des données) que l?on peut difficilement centraliser ou gérer dans un seul magasin d?analyse de données. Nous en reparlerons plus loin dans ce document. Enfin, la mise en place et la gestion d?infrastructures complexes d?informatique décisionnelle, avec l?organisation croissante et exigeante qui en résulte, génère des budgets en augmentation constante. D?après l?enquête d?InformationWeek citée ci-dessus, 39% des personnes sondées déploraient le fait que le coût élevé des licences logicielles les entravait dans la réalisation de leurs projets en matière d?entrepôts de données et d?informatique décisionnelle. Pour faire face à ces problèmes et réaliser l?objectif de disposer de systèmes d?entrepôts de données extensibles et réactifs, les entreprises modernes se tournent vers les solutions open source pour satisfaire leurs besoins. Le logiciel open source a prouvé sa valeur dans le domaine du web et s?introduit de plus en plus dans les structures d?entreprises. Ainsi, une étude du cabinet Gartner prévoit que 70% des entreprises utiliseront des bases de données open source dès la fin de 2008. 4 Dans ces conditions, il était naturel que la technologie open source investisse le domaine des entrepôts de données et de l?informatique décisionnelle. Bien que le serveur de base de données MySQL se soit hissé au rang de leader incontesté dans la gestion de données pour les applications en ligne, beaucoup se demandent s?il peut faire de même dans le domaine des entrepôts de données et de l?informatique décisionnelle. Ce document expose la stratégie de MySQL en ce qui concerne les entrepôts de données et démontre les possibilités et avantages exceptionnels de cette base pour les besoins en entrepôts de données et en informatique décisionnelle. 1 http://www.intelligententerprise.com/channels/bi/showArticle.jhtml?articleID=198701576 2 http://www.informationweek.com/showArticle.jhtml?articleID=198001258 3 http://www.netezza.com/releases/2006/release061906.htm. 4 Gartner Group, Enterprise Databases in an Open Source World, September 2006. Copyright © 2008, MySQL AB Page 4 sur 18 2 Un examen du trafic des entrepôts de données Dans son Magic quadrant de la catégorie systèmes de gestion d'entrepôts de données de 2006, Gartner a identifié plusieurs types de trafic liés aux entrepôts de données, établissant ainsi des catégories d?utilisations basées sur les différents cas rencontrés chez des entreprises activement impliquées dans l?informatique décisionnelle. Ces types de trafic s?établissaient ainsi : ? Le chargement continuel de données (proche du temps réel) ? similaire à un trafic de traitement de transactions en ligne (OLTP). ? De grandes quantités de rapports standards allant jusqu?à des milliers par jour, nécessitant une utilisation précise du SQL et la création d?index. ? Un nombre croissant d?utilisateurs de requêtes ad hoc générant une utilisation aléatoire, non prévisible des données. ? Des fonctions d?analyse orientées BI dans des applications OLTP Si l?on traduit concrètement ces différents trafics en installations d?entrepôts de données, on obtient les types d?utilisation suivants : 1. Des petits magasins de données, opérant en temps semi réel 2. Des entrepôts de données répondant en continu à des requêtes en temps réel 3. Des entrepôts de données alimentant un reporting standard traditionnel 4. Du stockage de masses de données historiques soumises à des requêtes ad hoc 5. Des analyses liées à l?informatique décisionnelle, dans les applications OLTP (une tendance émergeante) A présent, examinons en détail chacun de ces types d?utilisation afin d?en comprendre les différences essentielles. 2.1 Analyse des types d?utilisation des entrepôts de données Le premier type d?utilisation de l?entrepôt de données est le magasin de données. Les magasins de données sont habituellement caractérisés par deux choses : (1) leur taille et (2) leur public d?utilisateurs. Les magasins de données ont tendance à gérer des volumes de données inférieurs et à satisfaire un besoin plus restreint, gérant bien souvent ces données pour une zone particulière de l?entreprise ou même une partie seulement de cette zone. La fréquence de mise à jour d?un magasin de données (la cadence journalière ou horaire avec laquelle ses données sont rafraîchies par l?activité transactionnelle) dépend du besoin du secteur qui utilise ces informations pour prendre des décisions. Si les décisions importantes nécessitent de disposer des données les plus récentes possible, on peut rencontrer des systèmes d?alimentation en temps réel. Sinon on trouvera plutôt des systèmes de rafraîchissement quotidiens ou hebdomadaires. L?entrepôt de données en temps réel est devenu populaire ces dernières années, principalement à cause d?un désir croissant de disposer de l?information la plus récente possible pour battre la concurrence. L?entrepôt de données en temps réel implique un arbitrage permanent entre les ressources affectées au rafraîchissement des données et les requêtes adressées au même ensemble de données, une augmentation du volume stocké à une cadence journalière ou horaire, des procédures de purges des données inutiles et un public d?utilisateurs qui peut être large ou restreint suivant le contenu de l?entrepôt de données. L?entrepôt de données traditionnel, comme son nom l?indique, est le type d?utilisation auquel on pense le plus souvent quand on parle d?entrepôts de données. Brassant de gros volumes de données, soumis à des taux de rafraîchissement peu fréquents (qui ne sont pas définis en termes d?heures, et parfois ne sont Copyright © 2008, MySQL AB Page 5 sur 18 même pas quotidiens) et desservant un public important et varié, l?entrepôt de données traditionnel constitue généralement pour les entreprises leur première application (après le magasin de données) lorsqu?ils mettent en place un stockage de données à des fins d?informatique décisionnelle. L?entrepôt de données historiques est relativement nouveau et est apparu à la suite de lois assez récentes qui obligent de nombreuses entreprises à conserver de grandes quantités d?informations à la disposition du gouvernement ou pour répondre à d?autres contraintes de conformité. L?entrepôt de données historiques gère des volumes de données généralement plus importants que les entrepôts de données traditionnels et il est soumis à des rafraîchissements de fréquence moyenne, mais il génère typiquement moins de trafic d?interrogation que les magasins de données, l?entrepôt de données en temps réel ou l?entrepôt de données traditionnel. L?entrepôt d?analyse de données OLTP est parfois considéré comme un retour dangereux aux temps où les bases de données jusqu?alors consacrées à une activité transactionnelle rapide devinrent simultanément la cible d?un flux intensif de requêtes d?analyse. La juxtaposition de ces deux trafics signifia bien souvent la mort d?applications qui nécessitaient des temps de réponse rapides pour satisfaire des clients qui exigeaient d?être servis rapidement. L?entrepôt d?analyse de données OLTP constitue généralement un serveur dorsal d?entrepôt de données pour une application OTLP standard, mais il contient également certains objets qui sont alimentés par les transactions et sont conçus pour permettre les requêtes d?informatique décisionnelle. On pourrait citer d?autres types d?utilisation « niches », mais ce qui précède constitue la grande majorité de ce que l?on trouve aujourd?hui en entreprise. 2.2 Les défis à venir pour la gestion des entrepôts de données Chaque catégorie d?installation identifiée ci-dessus gère au moins l?un des types de trafic défini par Gartner, et parfois plus d?un seul. D?après Gartner, c?est lorsque l?installation d?un entrepôt de données doit gérer un trafic hétérogène que les problèmes commencent, aussi bien en ce qui concerne la gestion que la performance. Gartner affirme ainsi : ?Les quatre types de trafic représentent un challenge pour les fournisseurs, bien plus que la taille des données, quand bien même celle-ci est inférieure à 1 To. Outre les attentes en termes de qualité de service, la taille et la longévité des données « utiles » diffère grandement d?un groupe à un autre, impliquant chaque élément de l?environnement de l?entrepôt de données, depuis l?équilibre entre les entrées et les sorties (I/O) jusqu?à l?allocation de la mémoire et du processeur, en passant par la gestion du disque. Dans les trois prochaines années, la performance en situation de trafic hétérogène sera la question clé lorsque l?on parlera de la performance d?un entrepôt de données.? 5 Lorsque l?on cherche à résoudre une situation de trafic hétérogène, on peut se heurter à des problèmes de budget car cela implique souvent la séparation de l?entrepôt de données par zone d?intérêt entre plusieurs serveurs et bases de données. C?est justement l?une des raisons pour laquelle les professionnels des technologies de l?information se tournent vers l?open source pour répondre à leurs besoins en termes d?entrepôts de données. Cependant le budget n?est pas la seule raison pour porter son choix sur un SGBDR tel que MySQL pour la gestion d?entrepôts de données. De nombreux facteurs font de MySQL un choix intéressant dans ce domaine, y compris un historique d?entreprise solide, une série de fonctions de base particulièrement adaptées à la gestion d?entrepôts de données, une architecture et une conception exceptionnelles qui permettent de répondre au problème du trafic hétérogène et un réseau croissant de partenaires dans le domaine des logiciels et des outils dédiés à l?informatique décisionnelle. 5 Gartner Group, Magic Quadrant for Data Warehouse Database Management Systems, 2006. Copyright © 2008, MySQL AB Page 6 sur 18 3 Qu?est que MySQL? MySQL est la base de données open source la plus populaire au monde utilisée aujourd?hui pour développer des applications d?entreprise en ligne, des applications embarquées et des applications d?informatique décisionnelle. Depuis plus de douze ans, le serveur de bases de données MySQL a constitué le c?ur de systèmes de bases de données desservant un nombre croissant et exigeant de clients. Constituant le ?M? de la pile LAMP (Linux, Apache, MySQL, PHP/Perl/Python), MySQL a été soumis à l?épreuve par des applications dédiées aux traitements transactionnels exigeants, par des entrepôts de données gérant des téraoctets et des sites web à haut trafic. Il s?est affirmé comme le leader dans la technologie des bases de données open source. Des milliers d?entreprises de renom tels que Sabre, Google, Yahoo !, Sagem Monetel, Lafarge, Business Objects, Symantec, Alcatel-Lucent, Nokia, Nortel, Cisco, Skyblog et bien d?autres ont opté pour MySQL pour gérer leurs applications de bases de données. Le même serveur MySQL qui dépasse les espérances dans ces environnements est utilisé pour gérer les informations d?applications s?appuyant sur une base de données embarquée. Ayant fait ses preuves dans l?univers impitoyable des start-up technologiques, des sociétés Web 2.0 et autres activités d?avant-gardes, MySQL est en train de devenir rapidement la base de données embarquée de choix pour les éditeurs de logiciels qui veulent profiter de la nature open source de MySQL, tout en l?utilisant dans un contexte commercial. Avec son double système de licences, MySQL peut satisfaire cette demande avec une solution qui offre tous les avantages financiers et les points forts du modèle de logiciel open source tout en fournissant le filet de sécurité des services et d?un support dont les éditeurs ont besoin pour leurs produits commerciaux. Aucune autre base de données n?approche la popularité de MySQL, avec plus de 11 millions d?installations dans le monde et plus de 50 000 téléchargements quotidiens sur le site web de MySQL. En fait, une étude du Wall Street Journal (Décembre 2005) a révélé que la base de données MySQL n?était dépassée que par le navigateur Mozilla Firefox en termes de téléchargements de logiciels open source (70 millions au total). MySQL a gagné sa popularité en tenant sa promesse de fournir la grande majorité des fonctions nécessaires aux applications de bases de données à un coût bien moindre. A titre d?exemple, Weather.com (le site d?informations N° 1 sur le web ) a migré d?une base de données propriétaires à MySQL et a affirmé que cette transition vers l?open source et un matériel moins onéreux avait généré ?une augmentation de capacité de 30% et une baisse des coûts de 50%? d?après un article dans CIO magazine. 6 4 La stratégie de MySQL pour les entrepôts de données La stratégie de MySQL pour les entrepôts de données peut être formulée simplement comme la satisfaction de trois objectifs : ? Répondre aux scénarios d?utilisation d?entrepôts de données les plus courants ? Etablir des partenariats avec les fournisseurs majeurs de solutions d?informatique décisionnelle et d?intégration /transfert de données ? Offrir un coût total de possession extrêmement attractif pour les installations d?entrepôts de données. Nous allons maintenant explorer en détail chacun de ces objectifs dans les sections ci-dessous. 6 http://www.cioinsight.com/article2/0,1540,2159186,00.asp. Copyright © 2008, MySQL AB Page 7 sur 18 4.1 Le schéma technique de l?entrepôt de données chez MySQL Les caractéristiques techniques de la stratégie de MySQL pour les entrepôts de données comprennent quatre éléments. Tout d?abord, un engagement pour une méthodologie open source qui permet de maximiser l?innovation. En second, une solide série de fonctions de SGBDR adaptées à la gestion d?entrepôts de données. Troisièmement, une architecture exceptionnelle qui sous-tend le serveur de bases de données MySQL, lui permettant de gérer chaque type principal d?utilisation d?entrepôt de données à l?aide d?une seule couche d?interface commune. Enfin, une stratégie pour répartir les données de l?entrepôt et éliminer ainsi le défi des trafics hétérogènes identifié par Gartner. 4.1.1 Open Source signifie un maximum d?innovation La supériorité du modèle de développement open source sur les approches traditionnelles n?est plus contestée, et les analystes du secteur entre autres reconnaissent les avantages liés à l?adoption du modèle open source. L?existence d?une base d?utilisateurs dévoués et loyaux qui utilise, supporte et aident à améliorer le logiciel permet une bien plus grande innovation au sein d?un produit, et cela permet en outre au logiciel d?évoluer et de s?améliorer bien plus rapidement. Dans le cas de MySQL, on retrouve le meilleur des deux mondes. MySQL AB est une entreprise qui possède les droits sur le serveur de bases de données MySQL et développe le produit. Mais à côté de cela, une immense communauté d?utilisateurs de MySQL teste le produit en permanence, envoie des rapports de bugs et soumet des propositions d?amélioration (qui suivent une procédure rigoureuse d?analyse et d?approbation) pour le serveur. Enfin, MySQL possède un réseau important et croissant de partenaires éditeurs de logiciels qui développent également des logiciels et des améliorations pour le serveur MySQL (un point que nous aborderons plus en détail dans la suite de ce document). Avec ces trois solides sources de développement convergeant en un produit, on obtient une innovation plus importante, un rythme de sortie de versions plus rapide et un produit capable de satisfaire plus rapidement les besoins précis des applications d?entrepôts de données. 4.1.2 L?ensemble des fonctions de base de MySQL facilitant la gestion d?entrepôts de données MySQL comprend un ensemble de fonctions de base qui convient particulièrement aux différents types d?utilisation des entrepôts de données. La liste qui suit contient une sélection de fonctions qui permettent de gérer les entrepôts de données : ? La partition de données / index : disponible à partir de MySQL 5.1 ; incluant le partitionnement de type range, hash, key, list, et composite. On dispose du partitionnement de type ?élagage? par lequel MySQL examine uniquement les partitions dont il a besoin pour satisfaire une requête particulière au lieu de parcourir une table ou un index entier. La gestion du partitionnement est également supportée (ADD PARTITION, DROP PARTITION, etc.) ? Virtuellement aucune limite de stockage : par exemple, une seule table peut occuper jusqu?à 110 To ? La gestion automatique du stockage : des fichiers de données à croissance autonome, etc. ? Un support ANSI-SQL pour tous les types de données : y compris BLOB et XML ? Une réplication intégrée : simple et facile à configuration ? Des tables en mémoire principales : servent à conserver toutes les données résidentes dans la RAM ; parfait pour les tables de dimension ? Le support d?index variés : B-tree, texte complet, cluster, hash, GIS ? Des caches de données et d?index multiples et configurables ? Le chargement anticipé d?index de données dans les caches de données Copyright © 2008, MySQL AB Page 8 sur 18 ? Un cache de requêtes unique : cache le résultat plus la requête, et non les données seulement, ce qui permet des temps de réponse presque instantanés pour des requêtes répétitives fréquentes dans l?utilisation des entrepôts de données ? Le chargement de données en parallèle : pour charger des fichiers multiples simultanément ? L?insertion multiple DML : qui permet un traitement de type array à l?aide des commandes INSERT habituelles ? La compression de données : permettant des économies d?espace très importantes ? Les tables en lecture seulement : pour protéger les données sensibles ? L?encryptage : une protection supplémentaire pour les données sensibles ? Un optimiseur basé sur les coûts : il élimine la nécessité d?écrire des requêtes basées sur des règles ? Le support de nombreuses plateformes : pas de contraintes en termes de matériel ou de systèmes d?exploitation D?autres fonctions d?entrepôts de données telles que les vues matérialisées et d?autres outils similaires seront ajoutées dans les versions futures du serveur. 4.1.3 Une architecture visionnaire pour l?entrepôt de données De nombreux professionnels des technologies de l?information choisissent MySQL comme base de données pour leur entrepôt de données parce que MySQL offre un paradigme nouveau et souple de la gestion d?entrepôts de données. L?une des principales différences techniques entre MySQL et d?autres plateformes de bases de données ? qu?elles soient propriétaires ou open source ? repose sur l?architecture à moteurs de stockage modulaire de MySQL. L?architecture à moteurs de stockage modulaire de MySQL permet à un développeur de base de données de sélectionner un moteur de stockage spécialisé pour le besoin particulier d?une application tout en restant complètement exempté de gérer des contraintes de codage spécifiques. L?architecture fournit une série standard de services de gestion et de support qui sont communs à tous les moteurs de stockage de la base. Les moteurs de stockage eux-mêmes constituent les composants du serveur de bases de données qui exécute des actions sur les données sous-jacentes gérées au niveau physique du serveur. Illustration 1 ? L?architecture MySQL Copyright © 2008, MySQL AB Page 9 sur 18 Cette architecture efficace et modulaire offre des avantages importants en termes de performance et de gestion à ceux qui ont des besoins spécifiques pour un type d?utilisation de l?entrepôt de données. Le fournisseur d?application profite d?un avantage technique évident dans la mesure où l?on évite des lourdeurs inutiles grâce à la sélection de certains moteurs seulement pour le fonctionnement de l?application. De plus, l?encombrement du serveur peut être réduit soit en compilant, soit en excluant tout simplement certains moteurs de l?ensemble. Par exemple, le serveur MySQL comprend des moteurs de stockage intégrés qui sont destinés à : ? Des applications transactionnelles ACID ? Des applications non transactionnelles (qui permettent d?insérer et de lire des données plus rapidement) ? Des opérations en mémoire principale pour des temps de lecture très rapides ? Des environnements de bases de données en cluster ou à haute disponibilité ? Compresser l?historique des données dans un très faible espace ? Référencer les fichiers plats non DBMS au sein de la base de données MySQL ? Ainsi que bien d?autres usages De plus, une base de données ou application unique peut utiliser simultanément différents moteurs de stockage avec un résultat performant, sachant qu?une seule commande suffit à passer d?un moteur à l?autre. Enfin, une entreprise créative peut développer son propre moteur de stockage personnalisé pour répondre à un besoin précis de son application. La structure des moteurs de stockage de MySQL permet de rassembler dans un même contenant des bases de données différentes tout en disposant de vraies capacités ?de n?écrire qu?une seule fois? quant à l?écriture du code de l?application. Aucun système de gestion de base de données hormis MySQL n?offre une architecture visionnaire qui permet une telle puissance et une telle souplesse dans la conception d?une application d?entrepôt de données. 4.1.3.1 Les moteurs de stockage sont-ils utiles ? Certains pourraient se demander si les divers moteurs de stockage apportent réellement un plus en termes de performance, d?utilisation d?espace, etc? Juste un simple exemple: le moteur de stockage Archive de MySQL a été conçu pour réduire efficacement de gros volumes de données insérées et comprimées pour un faible encombrement. On peut examiner ci-dessous la différence de performance que peut résulter de l?emploi du moteur de stockage Archive par rapport à deux autres moteurs de stockage populaires de MySQL : Charge d?utilisateur MyISAM Insertions par seconde InnoDB Insertions par seconde Archive Insertions par seconde 1 3 203,00 2 670,00 3 576,00 4 9 123,00 5 280,00 11 038,00 8 9 361,00 5 044,00 13 202,00 16 8 957,00 4 424,00 13 066,00 32 8 470,00 3 934,00 12 921,00 64 8 382,00 3 541,00 12 571,00 Le moteur de stockage Archive effectue 50 % d?insertions de plus que MyISAM (le moteur de stockage par défaut de MySQL) et 255 % de plus qu?InnoDB (un moteur de stockage transactionnel aujourd?hui propriété d?Oracle). Copyright © 2008, MySQL AB Page 10 sur 18 De plus, une table de 11 millions de lignes structurée à l?identique occupe 1 Go d?espace en utilisant InnoDB, 795 Mo avec MyISAM, mais seulement 148 Mo si on utilise le moteur de stockage Archive. Comme le montre ce simple exemple, les moteurs de stockage de MySQL peuvent créer la différence dans les applications d?entrepôts de données. Maintenant donnons une brève description des moteurs de stockage utilisables pour des entrepôts de données, qu?il s?agisse de moteurs internes de MySQL (ceux que MySQL AB développe en interne) ou de moteurs développés par des tiers. 4.1.4 Les moteurs de stockage internes de MySQL pour les entrepôts de données Bien que n?importe quel moteur puisse être utilisé pour la gestion d?entrepôts de données, ceux qui se prêtent particulièrement à l?activité d?entrepôt de données comprennent : ? MyISAM ? Archive ? Memory ? CSV ? Merge ? Federated 4.1.4.1 MyISAM Le moteur de stockage MyISAM est le moteur de stockage par défaut de MySQL. Il offre des capacités de requêtes / insertions à haute vitesse, il est non transactionnel, dispose du verrouillage au niveau des tables (bien qu?il comprenne une fonction concurrente d?insertion qui permet d?effectuer des insertions sans bloquer les requêtes) et fournit un bon support des index (B-tree, texte plein, etc.). MyISAM est un bon moteur général pour les magasins de données et les entrepôts de données traditionnels. 4.1.4.2 Archive Le moteur de stockage Archive a déjà été présenté brièvement. Il compresse les données d?un rapport allant jusqu?à 80% et permet par conséquent des économies d?espace conséquentes. De plus, il dispose de scans rapides pour les tables importantes (>1 Go), ainsi que les verrouillages MVCC et au niveau des lignes. Archive est aussi unique en ce qu?il permet seulement les insertions et lectures de données, mais pas les modifications sélectives (c?est-à-dire pas d?UPDATE ou DELETE), ce qui le rend particulièrement adapté pour l?audit de données ou pour les informations sensibles qui ne devraient pas être manipulées. 4.1.4.3 Memory Le moteur Memory est exactement ce que son nom indique ? un moteur qui conserve toutes les données en mémoire à tout moment. Dans les entrepôts de données, les tables en mémoire principale sont particulièrement utiles dans le cas de tables de dimensions qui sont soumises à des scans de tables jointes ou uniques, car les tables en mémoire de MySQL permettent des temps de réponse très rapides pour les scans de tables complètes et les recherches d?index (les index B-tree et hash sont supportés). 4.1.4.4 CSV Les tables CSV permettent d?accéder via SQL à des fichiers plats de données depuis le serveur MySQL. Les données en format CSV peuvent être chargées instantanément dans MySQL en créant simplement un objet table qui reproduit le format du fichier plat CSV, en renommant sur le système le fichier plat CSV du nom de l?objet table CSV MySQL, toutes les données devenant alors immédiatement accessibles pour le serveur MySQL. Peu importe si le fichier contient un milliard ou 100 milliards d?enregistrements, les données sont disponibles instantanément pour l?utilisation. De plus, les données en tables CSV peuvent Copyright © 2008, MySQL AB Page 11 sur 18 être manipulées via DML à l?intérieur de MySQL ou éditées hors du serveur avec des éditeurs de fichiers (et les privilèges adéquats). 4.1.4.5 Merge Le moteur Merge représente la manière dont le partitionnement de base était effectué dans les versions de MySQL inférieures à 5.1. Un DBA peut combiner ensemble de 1 à n tables MyISAM identiques pour former un objet table unique sur laquelle on peut effectuer des insertions, des mises à jour, des suppressions et des requêtes. Chaque table MyISAM sous-jacente peut être placée sur un disque physique spécifique et posséder ses propres index. A partir de MySQL 5.1, le moteur Merge est toujours là, cependant les DBA peuvent également utiliser le partitionnement de données normal (un partitionnement horizontal des lignes supportant les fonctions range, hash, key, list, et composite). 4.1.4.6 Federated Enfin, le moteur Federated permet aux concepteurs d?entrepôts de données de créer une seule base de données logique à partir de plusieurs serveurs physiques de bases de données. Travaillant d?une façon similaire aux liens de bases de données Oracle ou aux serveurs liés sur SQL Server, le moteur Federated permet de créer des liens distribués vers d?autres serveurs physiques de bases de données et référence leurs objets comme s?ils étaient présents sur le serveur initial source. D?autres moteurs de stockage internes sont développés et maintenus par MySQL (Falcon, Blackhole, etc.), mais ceux qui précèdent représentent les moteurs les plus utiles dans une installation d?entrepôts de données. 4.1.5 Les moteurs de stockage externes pour l?entrepôt de données On peut faire appel à trois moteurs de stockage développés et maintenus par des fournisseurs de stockage tiers pour répondre à quelques uns des types d?utilisations des plus communs. Il s?agit de InnoDB, NitroEDB, et BrightHouse. 4.1.5.1 InnoDB En premier, on trouve InnoDB qui est un moteur de stockage transactionnel maintenu par Oracle. InnoDB supporte évidemment les applications OLTP, mais il peut aussi servir à des fins d?analyse et peut par conséquent convenir au type d?utilisation hybride OLTP/analyse identifié par Gartner. 4.1.5.2 NitroEDB Nitrosecurity est un fournisseur de solutions de gestion d?informations de sécurité qui sont soutenues par un puissant système de gestion de bases de données. La base de données Nitrosecurity a été dotée d?un certain nombre de caractéristiques très spéciales pour pouvoir traiter les énormes volumes de données et de requêtes simultanées qui émanent d?un logiciel de gestion de la sécurité. Nitrosecurity (www.nitrosecurity.com) et MySQL ont établi un partenariat pour produire le moteur de stockage NitroEDB qui a été conçu pour traiter les besoins de clients d?entrepôts de données en temps réel. Le moteur NitroEDB est capable de recevoir de très gros volumes d?insertions tout en traitant des requêtes simultanées concernant les mêmes données, le tout sans pénaliser la performance le moins du monde. De plus, NitroEDB contient des index spécialisés (N-tree, Microcluster) qui sont destinés à fournir des réponses extrêmement rapides pour des requêtes de style ?aggregate? (SUM, AVG, etc.) grâce au fait que l?information agrégée est en réalité conservée dans l?index lui-même. 4.1.5.3 BrightHouse BrightHouse est le troisième moteur de stockage édité par un tiers utilisable pour les entrepôts de données MySQL ; il est produit en partenariat par MySQL et Infobright (www.infobright.com). Pour Copyright © 2008, MySQL AB Page 12 sur 18 l?essentiel, BrightHouse est un magasin de données hautement compressé orienté colonnes qui intègre une technologie MySQL, bien que le moteur utilise ses propres modes de chargement et de déchargement plutôt que ceux de MySQL car (1) la compression et la décompression se produisent pendant le chargement et le déchargement et (2) la Grille de Connaissance BrightHouse est créée au moment du chargement. En outre, BrightHouse utilise également un optimiseur qui lui est propre car il sait comment utiliser l?information enregistrée dans sa Grille de Connaissance pour optimiser l?exécution de requêtes à l?aide du moteur BrightHouse. Le moteur Brighthouse consiste principalement en 4 couches : 1. BrightHouse est un magasin de données orienté colonnes. Cela signifie que les données sont stockées colonne par colonne au lieu de l?être par ligne. Les avantages de l?orientation colonnes sont nombreux, au nombre desquels une compression de données plus efficace dans la mesure où, chaque colonne contenant un seul type de données (par opposition aux lignes qui contiennent typiquement plusieurs types de données), la compression peut être optimisée spécifiquement pour chaque type de donnée. Les données des colonnes elles-mêmes sont stockées par groupes de 65K éléments. Nous nommons chacun de ces groupements ?paquets de données?. L?utilisation des paquets de données améliore la compression de données et c?est un élément essentiel dans la résolution de requêtes complexes par Infobright. 2. Data Pack Nodes (DPN) contient un ensemble de statistiques relatives aux données stockées et compressées dans chacun des paquets de données. Il y a toujours une relation 1 à 1 entre les paquets de données et les DPN. 3. Les Noeuds de Connaissance sont un autre ensemble de méta données relatives aux paquets de données, aux colonnes ou aux combinaisons de tables. L?ensemble de ces N?uds de Connaissances pris collectivement s?appelle la Grille de Connaissances. 4. L?Optimiseur BrightHouse utilise la Grille de Connaissances pour déterminer le nombre minimum de paquets de données nécessaires pour répondre à une requête déterminée. Dans certains cas, l?information contenue dans la Grille de Connaissance est suffisante pour résoudre la requête, auquel cas rien n?est décompressé. La conception du moteur de stockage Brighthouse est parfaitement adaptée aux quantités massives de données et de requêtes qui sont le lot habituel des entrepôts de données traditionnels ou historiques. 4.1.6 Tableau de comparaison des moteurs de stockage MySQL pour la gestion des entrepôts de données Vous trouverez ci-dessous un guide de référence des moteurs de stockage MySQL concernant les entrepôts de données donnant un bref aperçu des différents moteurs internes et externes fournis par Copyright © 2008, MySQL AB Page 13 sur 18 MySQL ; il contient une brève description de leurs caractéristiques et des types d?utilisation en entrepôt de données auxquels ils conviennent le mieux. Moteur Coût de stockage Verrouillage Index Chargement Fonctions spéciales Convient à MyISAM Bas Table avec insertions libres B-Tree, R-tree, Texte complet Rapide Pas de transactions, requêtes rapides Magasin, DW (Entrepôt de données) taille moyenne InnoDB Haut Ligne avec MVCC Clustered, B- Tree Lent Transactions Magasin, DW taille moyenne Archive Plus bas Ligne avec MVCC B-Tree Plus rapide Données compressées, scans rapides des tables DW historique, Audit Memory N/A Table Hash, B-Tree Rapide Tables conservées en RAM Tables de dimension CSV Haut Table Aucun Niveau fichier Édition directe du fichier ou via SQL Toute utilisation de fichiers plats NitroEDB Haut Dynamique (pas de vrai verrouillage) N-Tree, Hash, Microcluster Plus rapide Chargements /requêtes simultanés sans ralentissement DW temps réel Infobright Le plus bas Table Grille de Connaissance Le plus rapide Tables orientées colonnes, compression de données DW traditionnel ou historique Copyright © 2008, MySQL AB Page 14 sur 18 4.2 Le scale out des entrepôts de données avec MySQL L?une des stratégies techniques de MySQL les plus performantes est le ?scale out?. Le terme recouvre un concept d?architecture dans laquelle, plutôt que de renforcer un seul serveur (?scale up?) avec des CPU et de la mémoire additionnelle pour pouvoir traiter une charge plus importante, une application gérant des données peut croître par croissance externe (?scale out?) en séparant et en répartissant le travail de la base de données sur des machines standards, obtenant ainsi une tolérance aux pannes et une performance bien meilleures. Beaucoup parmi les sites web à fort trafic utilisent MySQL avec une infrastructure de scale out pour atteindre les hauts niveaux de disponibilité et de performance requis. Ce schéma de scale out peut également être repris pour les entrepôts de données et l?informatique décisionnelle, cette disposition permettant de résoudre le fameux problème de performance dû aux trafics hétérogènes que Gartner a identifié comme le plus gros défi à venir dans la gestion d?entrepôts de données. Plutôt que d?opter pour le ?scale up? avec un serveur unique et des extensions onéreuses et/ou d?utiliser différents systèmes de bases de données pour répondre à chaque type d?utilisation d?entrepôt de données, les architectes en technologies de l?information peuvent standardiser leur installation avec MySQL, sélectionner le moteur de stockage approprié pour chaque type d?utilisation d?entrepôt de données, et, grâce au scale out, séparer les différents trafics de façon à satisfaire les attentes des clients en termes de performance. Par exemple, les architectes de l?informatique décisionnelle d?une entreprise peuvent créer un ETL et des flux de cleansing de données à partir des divers systèmes opérationnels /OTLP et alimenter les différents ?shards? (magasin individuel analytique MySQL) qui ciblent un sujet particulier de l?informatique décisionnelle ou satisfont un besoin décisionnel spécifique. Un petit magasin de données au service par exemple d?une unité d?analyse financière restreinte pourrait utiliser MySQL à l?aide des moteurs MyISAM et mémoire pour constituer un shard. Une équipe de marketing peut utiliser un autre shard d?entrepôt de données MySQL pour explorer des tonnes de données historiques grâce au moteur de stockage de BrightHouse, tandis que des tableaux de bord pour la direction sont alimentés en temps réel par un autre shard MySQL via les moteurs NitroEDB ou MyISAM (voir l?illustration 2). Illustration 2 ? Exemple de configuration de scale out d?un entrepôt de données MySQL Copyright © 2008, MySQL AB Page 15 sur 18 Un entrepôt de données MySQL en configuration de scale out peut constituer le coeur d?un schéma d?informatique décisionnelle moderne. Voir l?exemple figurant dans l?illustration 3. Illustration 3 ? Une infrastructure d?informatique décisionnelle moderne 4.3 Le réseau des partenaires MySQL en informatique décisionnelle Ne se contentant pas de fournir un serveur de bases de données solide adapté à la gestion d?entrepôts de données, MySQL possède également un vaste réseau de partenaires qui développent des logiciels d?informatique décisionnelle, aussi bien sous forme propriétaire qu?open source. Qu?il s?agisse du domaine des outils de reporting et de tableaux de bord, (par exemple Business Objects, SAS, Jaspersoft), de l?ETL et des flux de données (exemple Informatica, DataStage, Talend, Pentaho), ou du développement et de l?administration (par exemple Quest, Microstrategy, etc.), on trouve des partenaires MySQL qui peuvent intervenir dans toutes les phases de la construction et de la gestion des entrepôts de données. L?illustration 4 présente quelques uns des principaux partenaires en informatique décisionnelle qui supportent MySQL et les solutions qu?ils proposent. Copyright © 2008, MySQL AB Page 16 sur 18 Illustration 4 ? Un échantillon des partenaires de MySQL en entrepôts de données / informatique décisionnelle 4.4 Examen du Coût Total de Possession des entrepôts de données MySQL Les économies budgétaires très importantes sont l?un des principaux facteurs expliquant la popularité et l?adoption croissante des logiciels de bases de données open source dans les entreprises. Le modèle open source est une façon bien plus intelligente de produire et de maintenir des logiciels de haute qualité que les méthodes propriétaires traditionnelles, cette approche ayant l?avantage de maintenir les budgets dans des limites raisonnables. Les clients qui choisissent MySQL économisent couramment 90 % des coûts de licence, de maintenance et d?assistance par rapport aux bases propriétaires. Comme l?a observé le PDG de RightNow, un fournisseur important de CRM : "Grâce à MySQL et à d?autres technologies open source, RightNow a développé un environnement d?hébergement pour une application professionnelle de CRM qui supporte plus de 3 000 déploiements pour certaines des plus grosses entreprises. Par l?intermédiaire de nos clients, nos systèmes ont traité plus d? un milliard d?interactions de consommateurs tout en maintenant une fiabilité de 99,97 % minimum. Lorsqu?il existe une alternative open source viable, l?argent dépensé pour des bases propriétaires est de l?argent gaspillé. ? - Greg Gianforte, PDG et fondateur de RightNow. Voici ci-dessous un exemple de comparaison des coûts entre l?utilisation de MySQL et d?autres plateformes propriétaires (en se basant sur les paramètres par défaut du calculateur de ROI sur le site web de MySQL) : Copyright © 2008, MySQL AB Page 17 sur 18 Avec MySQL Enterprise ? la solution de MySQL pour les entreprises qui utilisent le serveur de bases de données MySQL dans des environnements de production et d?informatique décisionnelle ? les clients bénéficient d?un logiciel de bases de données de la plus haute qualité, assorti de services intelligents qui apportent une aide automatique dans le monitoring et l?optimisation des entrepôts de données, et d?une assistance technique 24 h x 7 j pour résoudre les problèmes quels qu?ils soient et apporter une réponse rapide à toutes les questions. On peut obtenir tout cela pour une fraction du coût des licences et de l?assistance des bases de données propriétaires. En particulier, le MySQL Enterprise Monitor (un élément de la solution MySQL Enterprise) fournit une réelle valeur ajoutée pour les professionnels en entrepôts de données qui doivent surveiller et maintenir de nombreux magasins de données analytiques. La nature automatique du MySQL Enterprise Monitor supprime la nécessité d?un pilotage manuel des entrepôts de données, dans la mesure où le service surveille en permanence chaque magasin de données MySQL et évalue sa disponibilité et sa performance (à la fois pour la base de données et le serveur) suivant des règles intégrées que les experts de MySQL recommandent comme Copyright © 2008, MySQL AB Page 18 sur 18 meilleures pratiques .Tout écart en ce qui concerne la disponibilité ou la performance est immédiatement communiqué aux responsables, accompagné d?un avis expert sur la façon de résoudre les problèmes identifiés. 5 Etude de Cas BlueLithium, une des sociétés de marketing en ligne les plus en vue, a développé à l?aide de MySQL et du moteur de stockage BrightHouse une application d?entrepôt de données analysant des données cruciales pour les entreprises. BlueLithium, qui fait partie des cinq premiers réseaux de publicité en ligne aux US, traite des données émanant de 145 million de consommateurs dans le monde, combinées avec des analyses sophistiquées et des technologies de ciblage avancées qui créent de la valeur pour les professionnels du marketing comme de la publicité. "Notre analyse poussée permet de mieux cibler les publicités, ce qui est de grande valeur pour nos clients et procure une utilisation plus satisfaisante," a déclaré Jay Webster, Directeur général de BlueLithium Performance Network. "BrightHouse nous permet d?effectuer des analyses très complexes sur plus de 30 téraoctets de données tout en perfectionnant nos compétences sur MySQL." 6 Conclusion Les entreprises modernes qui réussissent ont réalisé qu?elles avaient besoin d?une infrastructure d?entrepôt de données et d?informatique décisionnelle performante pour pouvoir battre la concurrence, et elles commencent à comprendre comment elles peuvent utiliser la technologie open source pour atteindre cet objectif. MySQL peut répondre à chacun des types communs d?utilisation des entrepôts de données en vigueur aujourd?hui et peut également tirer son épingle du jeu en ce qui concerne la question des entrepôts de données à trafic hétérogène via l?architecture à moteurs de stockage modulaire du serveur et ses capacités de scale out. En outre, les clients peuvent profiter de tous les filets de sécurité en termes de support et de mises à jour grâce à MySQL Enterprise, sans que cela ne leur demande de faire exploser leurs budgets. Lorsqu?on considère le serveur puissant et innovant MySQL Enterprise, l?assistance technique, les services tels que le MySQL Enterprise Monitor, et un coût total de possession qui n?a tout simplement pas d?égal dans le secteur des bases de données, MySQL devient un choix évident pour les entreprises modernes à la recherche de capacités de pointe dans le domaine des entrepôts de données et de l?informatique décisionnelle.

PARTAGER SUR

Envoyer le lien par email
6498
READS
128
DOWN
8
FOLLOW
3
EMBED
DOCUMENT # TAGS
#datawarehouse  #mysql 

licence non indiquée


DOCUMENT # INDEX
Database 
img

Partagé par  dude

 Suivre

Auteur:
Source:Non communiquée