DOSSIERS

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

Par La rédaction, publié le 25 mai 2012

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.

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

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. »

Dans l'actualité

Verified by MonsterInsights