intersystems caché comme alternative aux bases de données

I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
INTERSYSTEMS CACHÉ
COMME ALTERNATIVE AUX BASES DE DONNÉES
RÉSIDENTES EN MÉMOIRE
David Kaaret
InterSystems Corporation
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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 ProtocolTM (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
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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
I N T
W H
E R
S
I T E
Y S T E M S
P
A P E R
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.
InterSystems France
Le Dôme
1 rue de la Haye
BP 12910
95731 Tremblay en France
Tel: +33 (0)1 49 19 49 09
Fax: +33 (0)1 49 19 21 00
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