La clé de l’In-Memory : les performances

La mémoire est le support le plus rapide

Utiliser la mémoire pour accélérer les applications très gourmandes en entrées-sorties n’est pas une idée nouvelle; un traitement de données en mémoire est plus rapide (parfois 1000 fois plus) qu’un traitement qui nécessite d’attendre l’écriture et la lecture sur un support plus lent - y compris la Flash.

Depuis les débuts de l’informatique, les solutions positionnées sur la haute performance ont alloué de la mémoire pour cacher les données. La plupart des bases de données ont été conçues pour utiliser la mémoire autant que possible. Certains peuvent même se rappeler avoir configuré un disque virtuel sur leur PC pour cacher les données temporaires au temps de MS-DOS.

Aujourd’hui, les traitements en mémoire exploitent ce principe à l’extrême : utiliser la mémoire dynamique (Dynamic RAM) pour l’exécution du code de la base et les structures de données actives, et conserver en mémoire la base persistante. Ces bases de données évitent autant que possible de dialoguer avec des supports de stockages internes ou externes. Au lieu de cela, elles optimisent leurs structures de données pour les traitements en mémoire.

Historiquement, la densité de mémoire disponible par serveur et le coût relativement élevé de la mémoire vive ont limité ce type d'approches, mais aujourd’hui la technologies permet d'appliquer les technologies en mémoire des jeux de données de taille bien plus importante; Les serveurs disposent de bien plus de mémoire vive, la déduplication inline/online et la compression tire parti de la puissance des CPU modernes pour placer plus de données en mémoire et enfin l'usage de technologies de cluster permet de distribuer les données sur un nombre accru de noeuds disposant eux même de plus de mémoire.

Les barrettes mémoire sont de moins en moins chères et de plus en plus denses. Les ordinateurs portables modernes sont désormais livrés avec autant de mémoire qu’un ancien mainframe. Aujourd’hui, n’importe qui avec une simple carte de crédit peut louer des serveurs à forte capacité chez les fournisseurs de cloud, comme Amazon Web Services - ses instances R3 sont équipées de 244 Go de RAM pour 2,80$ l’heure. Des serveurs en rack standards comme ceux proposés par HP, Dell, Lenovo ou Fujitsu peuvent héberger de 4 à 6 To de RAM. Et un serveur Unix haut de gamme comme le système Oracle M6-32 peut gérer jusqu'à 32 To de mémoire.

Le In-Memory est très à la mode pour les traitements de données non structurées, tout comme les applications reposant sur les bases de données plus traditionnelles. Les clusters à base de serveurs de commodité, avec 128 Go de RAM sur chaque noeud, peuvent l’adapter aux outils pour les temps réel et pour les requêtes Hadoop.

Cache, analyse et transactionnel

Avec les bases de données transactionnelles traditionnelles, seules les données les plus sollicitées sont placées en mémoire pour optimiser les performances, tandis que des formes de stockage moins coûteuses sont utilisées pour des données plus froides. Le moteur d’une base a pendant longtemps reposé sur ce principe. Aujourd’hui, placer l’ensemble de la base en mémoire peut faire sens. C’est  valable pour les bases de données analytiques notamment et pour les grilles en temps réel pour « l’intelligence opérationnelle ».

Dans les applications Web à fort trafic, des milliers d’utilisateurs se connectent en simultané sur un serveur Web et cela nécessite une certaine persistance; celle des sessions côté serveur, à chaque fois qu’ils interagissent avec une page. Dans ces instances, une base de données transactionnelle centralisée peut créer un goulot d’étranglement important. Des solutions comme Memcached , Pivotal GemFire et Redis offrent des possibilités de caching en mémoire des données, dans un format clé/valeur.

Lorsque une base de données structurée est bombardée de requêtes de façon répétée - comme c’est le cas pour le data mining ou l’analytique, il est préférable d’héberger l’ensemble de la base en mémoire. Les bases de données analytiques en colonnes, conçues généralement pour des opérations de BI, proposent des formats optimisés de stockage de données, même s’ils sont souvent partiellement compressés - moins adaptés aux opérations transactionnelles en volume.

Sur le marché, SAP HANA a ouvert le bal. Cette base In-Memory, dotée de certaines capacités de scale-out, est conçue pour héberger les données critiques de l’entreprise. Elle peut fournir des rapports analytiques en temps réel, ou presque, et elle peut également être utilisée pour d’autres formes de données. Les rapports, dont la création prenait des heures avec des bases de données transactionnelles,  peuvent ne prendre que quelques minutes avec HANA. Ses fonctions lui permettent de plus en plus de s’orienter vers le transactionnel, étendant un peu plus son utilité.

Les autres fournisseurs de bases de données analytiques en colonne, comme Teradata ou HP Vertica, se battent pour optimiser au maximum l’usage de la mémoire (les colonnes compressées sont par exemple cachées en mémoire). Ils ont également la capacité d’analyser d’importants jeux de données, trop volumineux pour des outils In-Memory. Vertica, par exemple, propose une approche hybride de l’In-Memory qui permet de charger rapidement les données en ayant recours à la mémoire, pour un accès en (presque) temps réel à la fois aux données sur disques et en mémoire.

Oracle Hybrid Columnar Compression (HCC) est un bon exemple de compression de données transactionnelles en fonction de leur date de création, tout en accélérant les capacités d’analyse. A l’automne dernier, Oracle a annoncé une option de traitement de mémoire qui conserve les données dans un format HCC pour accélérer l’analytique, et les lignes transactionnelles en mémoire pour accélérer en parallèle les traitements transactionnels l’OLTP.

Récemment, Microsoft a aussi optimisé SQL Server pour que son SGDB puisse supporter davantage de transitionnel en mémoire. Le projet Hekaton doit permettre à un administrateur de choisir les tables à placer en mémoire plutôt que sur disque - elles fonctionneront et interagiront de façon transparente avec les tables sur disques. IBM a lui aussi doté son SGBD DB2 de capacités de traitement in-memory.

Les données en mémoire peuvent-elles être protégées ?

L’une des principales préoccupations avec les bases In-Memory est de protéger les données. La DRAM est certes rapide, mais si vous coupez l'alimentation électrique, tout est perdu. Et même si les données sont sauvegardées sur un support persistant, la question se pose de savoir à quelle vitesse vous allez pouvoir les restaurer.

Une approche assez classique consiste à utiliser un espace disque local ou un SSD, comme sauvegarde locale pour les données les plus récentes. Malheureusement, ce n’est pas suffisant, si le serveur hôte plante sévèrement ou s’il est perdu.

Un bon exemple d’une protection complète d’une base de données In-Memory comme HANA consiste à utiliser une version récente de Data Protector et StoreOnce Federated Deduplication de HP. Data Protector recueille les données HANA  via une API tierce et cible ensuite la sauvegarde dans les outils de stockage dédupliqués de StoreOne.

En cas de problème, HANA peut être directement remis en place (ou migré) depuis Data Protector, via les API HANA, soit au niveau local ou vers un site distant avec la réplication de StoreOnce.

L’exemple de grilles

Les entreprises de la finance utilisent depuis longtemps les applications In-Memory bâties sur des solutions de grille de données en mémoire. Cela leur permet  de disposer d’une intelligence opérationnelle en temps réel sur de grands volumes de données (streaming). Les offres de Tibco, ScaleOut Software, Pivotal et GridGain vont au-delà des fonctions proposées par les bases In-Memory. Ils proposent une plate-forme plus étendue au sein de laquelle les opérations de bases des données, le traitement des Big Data et d’autres opérations qui manipulent intensivement les données peuvent toutes s’effectuer en temps réel. Si vous développez votre propre application In-Memory, vous utilisez probablement déjà cette approche en grille.

Les plates-formes de grille visent également à garantir des fonctions de protection des données, la récupération après sinistre et de haute-disponibilité. Par exemple, GridGain supporte la défaillance de noeuds, propose des fonctions de réplication native et la mise à jour sans interruption.

ScaleOut quant à lui offre une licence gratuite (jusqu’à une certaine limite), tandis que GridGain a récemment décidé de créer une édition communautaire Open Source.

Et pour terminer

Avant d’acheter un système In-Memory pour ses gains en matière de performance, évaluez d’abord vos besoins et identifiez les goulots d’étranglement. La mémoire n’est pas encore aussi bon marché que le disque dur ou la Flash et il se peut qu’il existe d’autres moyens pour obtenir les performances souhaitées à moindre coût, moins d’effort et moins de rupture.

Si vous disposez d’une base de données MySQL ou MongoDB, une option rapide et plutôt bon marché, consiste à mettre à jour le moteur de base de données pour un autre plus optimisé, comme la technologie d’index fractal de Tokutek. Il est intéressant de considérer une mise à jour gratuite qui n’implique aucune rupture dans l’infrastructure et les applications.

La bonne nouvelle est que les prix de la mémoire vont continuer de baisser et la densité par serveur augmenter. La gestion de la mémoire devrait aussi pouvoir se faire de façon plus granulaire, et les taille de cache des processeurs vont continuer  augmenter. De même, l'usage de cache Flash va se banaliser. Autant d'évolutions qui devraient accélérer un peu plus la migration des traitements de données en mémoire.

Le petit bémol est que la croissance des données devrait dépasser les avancées réalisées dans la mémoire. Il y aura donc toujours besoin de repartir les données entre de multiples classes de stockage. L’optimisation des environnements complexes de données représentera une réelle opportunité pour le marché de l’IT, l'enjeu étant de contrôler de façon dynamique les flux de données et d’identifier la bonne donnée pour le bon support.

La progression en cours des bases de données distribuées et In-Memory dans le monde des données structurées, ainsi que celle des architectures scale-out pour le traitement des données non structurées, témoigne d'ailleurs des bouleversements en cours dans le traitement des données. Alors que la donnée devient plus dynamique, est davantage « streamée », hébergée sur des clusters, les traitements informatiques vont devoir eux aussi être routés de façon dynamique vers la bonne donnée.

En d’autres mots, le traitement doit évoluer avec la donnée. La gestion et l’intelligence nécessaire pour optimiser ces routages  pourraient bien être le prochain Graal pour le marché.