INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

Transcription

1 I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation

2 INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES EN MéMoIRE Introduction Pour dépasser les limites de performances des bases de données relationnelles traditionnelles, les applications allant de celles installées sur une seule machine, à celles utilisant de vastes grilles interconnectées utilisent souvent des bases de données résidentes en mémoire pour accélérer leurs accès aux données. Bien que les bases de données résidentes en mémoire et les produits basés sur les caches mémoire améliorent la bande passante, ils souffrent d un certain nombre de limites dont le manque de support pour les grands ensembles de données, des besoins excessifs en matériel, et des limites en matière d évolution. InterSystems Caché est une base de données objets à hautes performances, disposant d une architecture unique, qui la rend appropriée pour des applications qui normalement utiliseraient des bases de données résidentes en mémoire. Les performances de Caché sont comparables à celles des bases de données résidentes en mémoire, mais de plus Caché offre : la persistance les données ne sont pas perdues à l arrêt ou au crash de la machine un accès rapide à de vastes ensembles de données la possibilité de gérer jusqu à plusieurs centaines d ordinateurs et centaines de milliers d utilisateurs accès simultanés aux données via SQL et les objets : Java, C++,.NET, etc. Ce document explique pourquoi Caché est une alternative attractive aux bases de données résidentes en mémoire pour les entreprises qui ont besoin d un accès à haute vitesse à de grandes quantité de données. Un moteur de données unique permettant la persistance et des performances élevées Caché est une base de données persistante, ce qui signifie que les données gérées en RAM sont écrites sur disque par des tâches de fond. Alors, comment se fait-il que Caché offre des performances similaires aux bases de données résidentes en mémoire, tout en écrivant périodiquement des données sur des systèmes de stockage persistants? Une partie de la réponse se trouve dans l architecture unique de Caché. A la place des lignes et colonnes d une base de données traditionnelle, Caché utilise des matrices multidimensionnelles, dont les structures s appuient sur les définitions des objets. Les données sont stockées telles que l architecte le souhaite, et des structures identiques sont utilisées à la fois pour la cache mémoire et le stockage sur disque. Les informations qui devraient être stockées ensemble le sont. Ce qui induit pour Caché un accès ultra-rapide aux données sur disque. La nécessité de synchroniser de multiples caches mémoire lors de la mise à jour des données réduit également les performances de nombreux produits s appuyant sur des caches distribués. Avec Caché, la mise à jour des données et leur 1

3 distribution sur les caches sont séparées logiquement. Cela permet un déroulement des opérations plus simple induisant des performances supérieures. Caché offre également des «liens intra-processus» vers C++ et Java, qui permettent aux applications écrites dans ces langages de remplir directement les structures de données internes de Caché. Les avantages de la persistance Sachant que Caché offre des performances comparables, ses possibilités d accéder aux données sur disque lui confèrent des avantages significatifs par rapport aux bases de données résidentes en mémoire. Le plus évident est l inutilité d un système supplémentaire de stockage permanent des données. Caché est ce système, et est toujours à jour. Les données ne sont jamais perdues à l arrêt ou au crash de la machine. Un autre avantage de Caché est que les volumes ne sont pas limités à la taille de la mémoire RAM disponible. Si les données ne sont pas dans le cache local, elles peuvent être obtenues de façon transparente d un autre cache ou du disque. N étant pas limité par la RAM, un système Caché peut gérer des petaoctets de données, ce qu une base de données résidente en mémoire ne peut faire. Ajouter de la RAM à un système pour tenter d accroitre ses capacités est plus cher que d ajouter des disques. (Un téraoctet de stockage disque est moins cher qu un téraoctet de stockage RAM). de plus, de nombreux systèmes résidents en mémoire doivent garder des copies redondantes des données sur plusieurs machines pour se protéger d un éventuel crash. Gérer des systèmes de caches distribués avec une base de données persistante comme Caché génère souvent des économies en matériel. Accès transparent aux données via SQL et les objets Le problème commun aux bases de données résidentes en mémoire est, du fait de l optimisation de leurs structures de données pour un traitement rapide, l impossibilité d un accès transparent via SQL. Pour être compatibles avec la plupart des outils d analyse et de rapports, les données doivent d abord être «traduites» en tables relationnelles. Cela est fait en général lors du transfert de la base en mémoire vers son système de stockage persistant et implique un processus ETC (Extraction, Transformation, Chargement). (Le surcoût en charge processeur et en temps nécessaire pour ce transcodage est la raison principale pour laquelle les bases de données relationnelles ne sont pas assez rapides pour des applications distribuées à hautes performances, et pourquoi les bases de données résidentes en mémoire sont utilisées à leur place). Quelques bases de données résidentes en mémoire utilisent le modèle relationnel et offrent un accès SQL aux données. Ces systèmes souffrent des maux opposés, c est à dire l absence d accès direct aux technologies orientées objet qui sont utilisées traditionnellement pour les développements applicatif. de plus, la plupart des bases relationnelles résidentes en mémoire ne sont pas conçues pour des configurations multi-machines. Elles ne fonctionnent que sur un ordinateur unique et sont limitées en RAM. Caché est différent car ses tableaux multidimensionnels peuvent être vus simultanément comme des tables relationnelles ou des objets. L Architecture de données Unifiée de Caché gère à la fois les vues objet et relationnelles des données à tout moment sans traduction. 2

4 Fig. 1: L'Architecture de Données Unifiée de Caché offre divers types d'accès aux données L accès SQL de Caché est compatible avec odbc et JdBC. du coté objet, Caché offre des liens avec de nombreux langages orientés objets tels Java,.NET et C++. La représentation des objets de Caché est complète et supporte les concepts orientés objets tels l héritage, le polymorphisme et l encapsulation. Enterprise Cache Protocol Pour les applications multi-machines, Caché gère les caches automatiquement en utilisant son Enterprise Cache Protocol TM (ECP). Avec ECP, les instances de Caché peuvent être configurées comme serveurs de données ou serveurs d applications. Chaque bloc de données appartient à un serveur de données. Les serveurs d applications sont conscients de la localisation des données et gardent un cache local des données les plus récemment utilisées. Si un serveur applicatif ne peut pas satisfaire certaines requêtes à partir de son cache local, il demandera les données à un serveur distant. ECP gère automatiquement la synchronisation des caches. ECP n a besoin d aucune modification des applications les applications considèrent toute la base de données comme si elle était locale. Ceci est une différence majeure avec quelques gestionnaires de caches distribués, dans lesquels chaque client doit spécifier à quel sous-ensemble de données il s intéresse avant chaque requête. Une machine, un cache Une autre différence majeure entre Caché et d autres gestionnaires de caches distribués réside dans le fait que ces autres produits gèrent un cache séparé pour chaque processus de chaque machine. Par exemple, si 8 clients accèdent à une machine donnée, alors huit caches seront gérés sur cette machine. 3

5 A l inverse, Caché gère son cache en mémoire partagée et offre des liens pour permettre aux processus d accéder aux données à partir de leur propre espace d adresses mémoire. Il est possible d accéder aux données en utilisant des protocoles basés sur TCP comme JdBC, à travers des liens directs aux langages, et également pour des performances extrêmement élevées via des liens permettant à l application de manipuler directement le cache. Permettre à plusieurs clients de partager un cache unique offre un grand nombre d avantages. L un réside dans le fait qu un système utilisant un cache partagé nécessite moins de mémoire. Quand, et c est souvent le cas, plusieurs clients souhaitent un accès aux mêmes données, les autres systèmes de caches distribués gèrent plusieurs copies des données. Avec Caché, une seule copie est nécessaire sur chaque machine. Avoir un cache par machine entraine également une réduction de la charge réseau. dans les applications à hautes performances, le trafic réseau induit par la gestion des caches est souvent un souci majeur. Cependant, avec un cache unique par machine, un seul cache doit être mis à jour pour refléter les modifications de données sous-jacentes, au lieu des mises à jour redondantes des systèmes à caches multiples. Même avec un processeur multi cœurs, un système Caché n utilise qu un cache partagé par machine, ce qui entraine un meilleur effet d échelle que sur les autres systèmes de caches distribués. Par exemple, dans un système Caché de 250 machines, chacune avec 8 cœurs, la communication ne se fait qu entre 250 caches pour maintenir la cohérence du système. Mais les architectures qui nécessitent un cache séparé pour chaque cœur devraient coordonner 2000 caches. Comme les ordinateurs modernes peuvent avoir huit voire seize cœurs ou plus, l avantage de Caché en terme d évolutivité devient de plus en plus important. Fig. 2a: Gestion du cache sans l'enterprise Cache Protocol d'intersystems. 4

6 Fig. 2b: Gestion du cache avec Caché. Le remplissage du cache dans de nombreuses applications avec un cache distribué, pré-remplir le cache peut être un processus long. Simplement dû au volume brut de données et/ou au temps passé à traduire les données d un système relationnel vers la structure objet utilisée par l application. Pour certaines applications utilisant beaucoup de données, on passe plus de temps à remplir le cache qu à faire tourner les applications l utilisant. Rien de tout ça avec Caché. Les capacités SQL exceptionnelles de Caché lui permettent d extraire aisément les données des sources primaires relationnelles. Et naturellement, étant lui-même une base persistante, Caché peut être la source primaire des données. dans ce cas, aucun besoin de pré-chargement des caches. Les caches locaux se rempliront automatiquement au fur et à mesure de l exécution des requêtes. Une autre considération est le nombre de machines impliquées dans la tâche de remplissage des caches. Avec Caché, la gestion primaire des données est gérée par un petit pourcentage des machines dans une grille distribuée. Remplir cet environnement ne nécessite que l accès aux serveurs de données ECP, et ils peuvent être chargés en arrière plan, pendant que les autres machines sont utilisées à autre chose. Quand on met en ligne les serveurs d applications, leurs caches seront à nouveau remplis automatiquement quand ces données seront demandées. A l inverse, lors du chargement des données de la plupart des produits résidents en mémoire, celles-ci sont partitionnées pour être diffusées dans le cache distribué afin que toutes, ou presque toutes, les données soient dans la mémoire d au moins une machine. Le résultat est souvent l impossibilité de charger les données avec un petit sous-ensemble des ordinateurs, tout en mettant les autres en ligne suivant les besoins. 5

7 Conclusion La principale raison pour utiliser des bases de données résidentes en mémoire est la vitesse. Mais malgré leur rapidité, les bases de données résidentes en mémoire souffrent d une mauvaise évolutivité, d un manque de support de SQL, d un besoin excessif en capacité hardware, et du risque de perte des données lors d arrêts imprévus. Caché est la seule base persistante qui offre des performances identiques aux bases de données résidentes en mémoire. Il gère également de vastes quantités de données, permet un accès transparent aux données via SQL ou les objets, gère des systèmes distribués de centaines de machines, tout en assurant une fiabilité maximum. Tout cela fait de Caché une alternative attractive pour les applications gérant de grands volumes de données à très grande vitesse. A propos d InterSystems InterSystems Corporation est un leader global de l industrie du logiciel, dont le siège est à Cambridge, Massachusetts, et qui dispose de bureaux dans 23 pays. InterSystems offre des produits innovants qui permettent le déploiement rapide et l intégration d applications à la taille de l entreprise. InterSystems Caché est une base de données orientée objet qui rend les applications plus rapides et évolutives. InterSystems Ensemble est une plateforme de développement et d intégration rapide qui enrichit les applications de nouvelles fonctionnalités, et permet leur inter-connectivité. InterSystems HealthShare est une plateforme offrant la création extrêmement rapide d'une base de données médicales au niveau des bourses de santé régionales ou nationales. InterSystems DeepSee est un logiciel permettant l intégration de fonctionnalités de business intelligence en temps réel dans les applications transactionnelles, pour de meilleures décisions opérationnelles. Pour plus d informations, visitez InterSystems.fr.

8 InterSystems France Le Dôme 1 rue de la Haye BP Tremblay en France Tel: +33 (0) Fax: +33 (0) InterSystems.fr InterSystems Ensemble and InterSystems Caché are registered trademarks of InterSystems Corporation. InterSystems DeepSee and InterSystems HealthShare are trademarks of InterSystems Corporation. Other product names are trademarks of their respective vendors. Copyright 2010 InterSystems Corporation. All rights reserved. 1 10