Fournir des rapports en temps réel, rapidement et à grande échelle

Lorsqu'une grande entreprise de logistique britannique a voulu améliorer le reporting pour ses grands comptes, elle s'est tournée vers Actian pour concevoir, mettre en œuvre et support système de base de données sous-jacent ("LARS") en utilisant les produits Ingres, HVR et Vector pour son architecture.

La brève

Le client disposait d'une centaine de chargés de clientèle dédiés aux grands comptes, chaque chargé de clientèle produisant manuellement son propre ensemble de rapports quotidiens, biquotidiens et ad hoc basés sur des feuilles de calcul pour les envoyer par courrier électronique à leurs interlocuteurs, sur la base d'une série d'extraits quotidiens d'une base de données Ingres de niveau opérationnel.

Le client souhaitait normaliser le format des rapports et automatiser leur production afin de faire gagner du temps aux représentants, de fournir des rapports à leurs comptes de manière cohérente et en temps voulu et, enfin, de rendre possible l'externalisation de la fonction.

Le défi consistait non seulement à produire le volume de rapports analytiques complexes programmés (plus de 1000 par jour, étroitement regroupés autour des heures critiques du milieu de la matinée et du milieu de l'après-midi) et à soutenir simultanément la production de rapports complexes ad hoc pour 200 utilisateurs avec un temps de réponse de quelques secondes, mais aussi a) à le faire sans surcharge significative sur la base de données de niveau opérationnel source et b) à réduire le besoin de la gamme d'extraits existants de la base de données de niveau opérationnel. Une exigence supplémentaire était qu'il devait être possible de "basculer" d'autres applications existantes de la base de données de niveau opérationnel vers cette nouvelle base de données à un stade ultérieur, ce qui imposait que la conception de la base de données soit aussi similaire que possible à la base de données de niveau opérationnel existante.

En raison de retards dans le démarrage du projet (dus à des changements au sein de l'organisation du client), une pression considérable s'est exercée pour que le projet soit réalisé dans un délai aussi court que possible.

L'architecture

Pour fournir à l'utilisateur un outil d'analyse et de reporting utilisateur en amont, un logiciel semi-personnalisé d'une organisation partenaire a été choisi, basé sur le produit Logi Analytics.

La conception du schéma de la base de données a été contrainte par la conception du schéma de la base de données source, ce qui a entraîné la nécessité de fournir une série de vues de la base de données impliquant des jointures sur 12 tables, certaines des tables ayant plus de 300 millions de lignes. Afin de fournir aux utilisateurs interactifs des temps de réponse réalistes tout en répondant aux besoins des rapports programmés, Vector a été choisi comme le SGBD idéal pour cette base de données, en raison de sa très grande vitesse de traitement des requêtes de recherche complexes et de sa capacité à refléter la structure de la base de données source d'Ingres pratiquement inchangée.

La base de données Ingres source et la base de données Vector cible ayant des schémas essentiellement similaires, HVR (High Volume Replicator) a été choisi comme solution logicielle pour maintenir la base de données Vector en ligne avec la base de données Ingres source. Le processus HVR Capture lit le journal des transactions de la base de données source Ingres, transmet les opérations d'insertion et de mise à jour via le HVR Hub à la machine cible où le processus HVR Integrate reflète les insertions et les mises à jour en tant que "upserts" dans la base de données Vector (les "suppressions" ont été supprimées dans HVR, pour éviter que les purges régulières de la base de données source n'entraînent également des purges de la base de données cible), ce qui impose une charge très faible à la machine de la base de données source.

La mise en œuvre

La base de données source Ingres fonctionnant sur une ancienne plateforme HP-UX, HVR a été installé sur un serveur Linux dédié pour lui servir de hub. La base de données Vector est installée sur un autre serveur Linux dédié. Un composant de "capture" HVR s'exécute sur la machine Ingres, capture les modifications de la base de données source à partir du journal des transactions et les envoie via le Hub HVR au composant "d'intégration" HVR s'exécutant sur le serveur Vector qui applique les mêmes modifications (via des "upserts") à la base de données Vector cible.

Pour répondre aux besoins du client en matière de réduction des délais de développement, le projet a été livré prêt pour les tests d'acceptation des utilisateur en 3 mois à compter du début du développement, grâce à la capacité de Vector à reproduire un schéma Ingres avec peu de changements.

Afin de réduire le nombre de jointures de tables dans les vues de 12 à 9, une tâche programmée régulièrement (exécutée toutes les 10 minutes) a été créée pour maintenir une table dé-normalisée.

La tâche de mise à jour de la dénormalisation, la tâche "upsert" de HVR, le grand nombre de rapports programmés et les utilisateurs interactifs coexistent heureusement sur le serveur Vector.

Performance vectorielle

Il est souvent difficile d'indiquer les temps de réponse d'un système en raison du grand nombre de variables en jeu, mais nous pouvons vous donner un aperçu des performances de la base de données Vector par rapport à la base de données Ingres qui en est la source. Un membre de l'équipe informatique du client a dû exécuter une requête SQL ad hoc excessivement lourde sur la base de données source Ingres, qui a duré 10 minutes avant qu'elle ne la tue, la jugeant insoutenable. Nous avons exécuté la même requête SQL sur la base de données Vector en direct, aux heures de grande écoute, et l'opération s'est déroulée en 0,05 seconde. Bien qu'il ne s'agisse pas d'une comparaison directe, puisque les deux bases de données fonctionnaient sur des plateformes et des configurations matérielles différentes, elle illustre la vitesse d'extraction spectaculaire dont Vector est capable.

En fait, les performances de Vector ont été si impressionnantes qu'elles ont modifié les exigences spécifiées par l'équipe en charge du client. La pratique de travail envisagée était de permettre l'exécution d'environ 200 rapports complexes entre 10h et 10h30, mais Vector était si rapide et si confortable à l'échelle que ces rapports sont maintenant tous exécutés dans les 5 minutes suivant 10h, et cela n'était limité que par les ressources (cœurs, mémoire, etc.) de la machine.

Satisfaction des clients

Le client a été suffisamment impressionné par l'architecture novatrice de la mise en œuvre de LARS pour commander un deuxième projet plus ambitieux basé sur un vecteur et alimenté par un flux de messages continu. Ce projet fera l'objet d'un prochain article sur le blog.

À propos d'Emma McGrattan

En tant que directrice de la technologie chez Actian, Emma McGrattan dirige la stratégie technologique, l'innovation et le développement de produits de l'entreprise, à support mission d'Actian qui consiste à simplifier la façon dont les entreprises connectent, gèrent, gouvernent et analysent les données afin de transformer les entreprises. Depuis qu'elle a rejoint l'entreprise il y a trois décennies, Emma a joué un rôle essentiel dans l'évolution et le progrès de ses solutions d'analyse, d'intégration des données et de gestion des données , y compris la plateforme de données Actian. Emma est titulaire d'un diplôme d'ingénieur en électronique de la Dublin City University en Irlande.