Le Grand Guide des Bases de Données (part. 2) : au-delà du relationnel

Introduction

À l’heure du Big Data, du cloud et des données hétérogènes et non structurées, les bases NoSQL – acronyme de « pas seulement SQL » – et leurs cousines « In-Memory » changent le marché et sont plus adaptées à certains usages que les SGBDR traditionnels.

Après avoir abordé dans la première partie de ce « Grand Guide des bases de données », les bases relationnelles, cette deuxième partie distingue les SGBD In-Memory SQL et NoSQL. La tendance NewSQL qui tend à interroger des bases de données NoSQL avec un moteur de requêtes SQL se poursuit. À l’inverse, les SGBDR sont devenus multimodèles. 

Oracle prétend supporter tous les usages, dont le In-Memory, tout comme les mainteneurs de PostgreSQL ne cessent d’adjoindre des extensions. Il faut aussi prendre en compte l’évolution des architectures cloud et celles des équipements. Bon nombre d’éditeurs affirment que leur base de données, relationnelle ou non, ont des capacités In-memory, parce qu’elles supportent la mémoire persistante Intel Optane PMEM, parce qu’elles bénéficient de la vitesse du stockage flash NVMe over fabrics ou encore parce que l’on alloue tout simplement à leurs instances des téraoctets de mémoire vive.

Bref, d’une manière ou d’une autre, certains éditeurs veulent accueillir toutes les structures de données, desservir toutes les applications, peu importe la nature originelle du SGBD.

Et pourtant, il existe bien une dichotomie des usages, parfois dictée par le modèle primaire d’une base de données, parfois par les intentions des éditeurs et des contributeurs.

Ainsi, Redis est devenu la couche de cache par excellence dans les environnements cloud. Et comme le cloud s’impose dans les entreprises, une partie du marché se concentre sur cette technologie, qui continue d’évoluer pour se plier aux besoins des utilisateurs. Une autre tendance anime le marché : le cloud hybride. Dans ces environnements, l’adoption d’un SGBD in-memory est fonction des usages, tout comme c’est encore le cas sur site. Des acteurs comme GridGain, HazelCast et SingleStore (ex-MemSQL) évoquent les besoins des banques et des services financiers qui souhaitent bénéficier d’une couche de cache distribuée, liée à leur mainframe et à leurs applications, capable d’accélérer des traitements transactionnels et analytiques.

La plupart des acteurs du marché souhaitent aussi adapter leurs technologies aux streamings de données en masse, au machine learning et au deep learning, tout en adoptant les modèles d’architecture (ou de consommation) plébiscités par les fournisseurs cloud, notamment le serverless.

Le tableau que ce guide esquisse fait apparaître à l’horizon une autre tendance. Là où certains acteurs du marché In-Memory jugent qu’ils complètent des architectures applicatives existantes, d’autres espèrent faire table rase du passé au bénéfice de leurs produits (et au leur) au fur et à mesure que leurs clients adoptent le cloud. Or des fournisseurs tels AWS et Google Cloud, ainsi que leurs soutiens, estiment que chaque SGBD répond à un usage bien spécifique. Une thématique que nous aborderons plus longuement dans une troisième partie, consacrée au marché NoSQL.

Mais cette deuxième partie ne se contente pas de faire un tour du marché, puisqu’il revient sur les critères et les éléments clés à prendre en compte pour choisir le bon outil In-Memory en fonction de vos besoins précis.

Dossier mis à jour le 17 mai 2022.

1Bien comprendre le In-Memory-

Avant toute chose

2Marché In-Memory relationnel-

SQL et In-memory

3Marché In-Memory NoSQL-

Redis mène la danse

4Glossaire-

Quelques définitions