En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour vous proposer des services et offres adaptés à vos centres d’intérêts.FERMER  x
Pour en savoir plus et paramétrer les cookies...

Forces et faiblesses des bases de données en mémoire

La technologie offre de très bonnes performantes et réduit grandement la préparation des données. Mais elle exige des nouvelles compétences en matière d’administration.

laisser un avis
agrandir la photo
Les bases en mémoire (in memory), c’est-à-dire fonctionnant totalement en RAM, ont toujours existé. Mais elles restaient l’apanage des plus riches. La donne a changé, avec la baisse du prix de la mémoire. Nous sommes désormais sous la barre des 0,10 dollar le gigaoctet contre 100 000 dollars en 1975. Résultat, les spécialistes historiques comme Redis, SolidDB ou TimesTen sont aujourd’hui rejoints par des géants tels que SAP (avec Hana) ou Oracle (avec Exalytics). Au-delà de ces mastodontes, il faut aussi compter avec la vague de solutions regroupées sous la bannière noSQL et popularisées par des outils libres comme Cassandra ou Mango DB.
Les bases en mémoire laissent entrevoir de nouveaux usages, aussi bien sur le terrain décisionnel qu’opérationnel. Notamment dans le domaine financier, grâce à des informations plus précises et plus fraîches que par le passé.

Plusieurs points forts

1. Un ratio performance/coût imbattable
agrandir la photo
Comme l’ensemble de la base de données fonctionne en mémoire, les temps d’accès sont évidemment réduits – la vitesse de lecture de la RAM est plus de 6 millions de fois plus rapide que celle du disque. Avec la baisse des prix, il n’est plus rare de trouver des serveurs dotés d'un téraoctet de mémoire RAM. Cette technologie est une aubaine pour au moins deux types d’entreprises, explique Julien Cabot, directeur marché et finance chez Octo Technology : « Celles amenées à réaliser plus de 100 000 transactions par jour, comme c'est dans le cas dans la finance ou les transports et pour celles qui comptent des centaines de milliers d’utilisateurs, tels les spécialistes de l’e-commerce. »
2. Réduire voire supprimer les étapes de préparation
Qu’elles servent des besoins transactionnels ou décisionnels, les bases en mémoire réduisent drastiquement les étapes de préparation des données. Rappelons qu’il est toujours plus rapide de calculer une valeur à la volée en mémoire, que d’accéder à cette même valeur précalculée sur un disque. Fini donc les indispensables opérations d’agrégat, puisque les bases en mémoire ne s’appuient que sur les données de détail. Exit aussi l’élaboration d'axes d’analyses définis a priori. Désormais, ils sont calculés sur le vif, à la demande de l’utilisateur, ce qui lève une des principales contraintes des projets décisionnels.
 

Quelques limites

1. Une administration matérielle encore perfectible
Les étapes traditionnelles d'optimisation de la performance, telles que l’élaboration du modèle de données ou la pose d’index, sont nettement réduites en mode in memory. Mais les autres opérations d’administration, notamment celles qui sont proches du matériel, requièrent davantage d'attention.
Car si ces bases sont bien en mémoire, une partie des données reste toujours stockée sur disque. L’optimisation du cache est donc essentielle. Il convient alors de spécifier avec précision les tables, les portions de table ou les colonnes qui iront sur l’un ou l’autre des supports. L’enjeu est également de garantir une bonne synchronisation entre les deux niveaux. Enfin, la plupart des bases en mémoire étant hautement distribuées, l’administrateur devra optimiser finement la répartition des clusters en fonction du trafic des requêtes.
Au final, tout cela exige de nouvelles compétences d’exploitation. Malheureusement, avec les bases en mémoire, les administrateurs ne disposent pas d’outils aussi éprouvés que ceux livrés par exemple avec Oracle ou DB2.
2. Obligation de circonscrire des processus métier
La plupart des bases en mémoire reposent donc sur une architecture distribuée. Une seule base peut ainsi tourner sur plusieurs clusters répartis dans le monde, en haute disponibilité. Mais cette redondance fait une victime : la cohérence des données. Les systèmes in memory ont parfois du mal à gérer les écritures simultanées, surtout lorsqu’elles sont effectuées depuis des points géographiques éloignés. « Je recommanderais aux utilisateurs d’une même région de travailler sur un périmètre qui leur est propre. Les dossiers français pour le site de Paris, les dossiers asiatiques pour celui de Singapour conseille Julien Cabot. Lorsque tous les utilisateurs sont potentiellement amenés à exploiter l’ensemble les données, une base traditionnelle sera bien plus adaptée. »
envoyer
par mail
imprimer
l'article


@01Business_fr sur
à lire aussi
SUR LES MÊMES THÈMES
Hana devient le logiciel phare de SAP
Bases de données : NimbusDB réunit les concepts SQL et NoSQL
4D monte en puissance
Twitter délaisse MySQL pour une base de données non SQL
Oracle supporte Android et Blackberry... via l’open source
IBM se pose en futur gardien de la qualité de l’information
Oracle-Sun : la Commision européenne repousse sa décision d'une semaine
Les consortiums open source OSA et OW2 fusionnent
Oracle met la main sur les technologies d'HyperRoll
Oracle 11 G R2 intègre le stockage hybride
Les grandes ambitions de MySQL dans le transactionnel
Un nouveau souffle pour l’impression en entreprise
Halte aux gaspillages
Les multifonctions : le trait d'union entre l'impression et la GED
Externaliser la gestion de son parc d'imprimantes pour se concentrer sur son coeur de métier
Les trois dimensions d’un projet offshore
Dossier relation-client : les Français aiment leur banque... digitale
Les offres 4G s'adaptent aussi aux besoins des entreprises
Résultats annuels : les SSII sortent la tête de l'eau