Bases de données émergentes : de nombreuses possibilités, mais à expérimenter

Le domaine des technologies de bases de données est en pleine évolution. Auparavant, les bases de données relationnelles (RDBMS), misant sur l’usage de SQL, constituaient souvent la seule architecture de données envisagée pour le développement d’applications.
La normalisation des données induite par ces bases de données relationnelles constitue une architecture très performante pour l’écriture des données. Cependant, cette architecture représente un obstacle en analyse de données, en raison des exigeantes opérations de jointures qui sont alors requises. La solution classique de contournement, à savoir les entrepôts de données requérant un processus ETL, est très couteuse à déployer et dispendieuse à exploiter.
Profitant de la baisse constante du prix des unités de stockage de données et de l’augmentation de leurs performances techniques, nombre d’entreprises osent remettre en question les RDBMS. L’offre des technologies qui s’affranchissent de ce paradigme a explosée au cours des dernières années. Parmi les plus connues des bases de données émergentes citons MongoDB (NoSQL / documents), Cassandra (orientée-colonne), Redis (clef-valeur) ou bien Neo4J (graphique). Un monde de nouvelles possibilités à explorer.
Les entreprises doivent toutefois s’assurer que les promesses que ces nouvelles technologies leur font miroiter sont crédibles. Elles doivent se préparer à relever les défis technologiques qu’elles représentent. Voici un aperçu des défis que posent certaines d’entre elles.

MongoDB
(4ième base de données la plus utilisée, 1ière parmi les non-RDBMS)
L’avantage de cette technologie dite « orientée-documents » est qu’elle offre une flexibilité de conception inégalée et se marie très bien à la programmation orientée-objet, au point qu’un ORM n’est pas requis (un objet est directement sérialisé dans une structure JSON, et vice-versa).
Les performances de MongoDB en analyse sur des ensembles de données volumineux ont tendance à se dégrader. MongoDB a introduit le concept de « MapReduce » pour s’affranchir de cette limitation, mais son fonctionnement est loin d’être satisfaisant. Les opérations de recherches complexes (équivalant à des jointures en SQL) sont particulièrement difficiles à exécuter en MongoDB, ce qui contraint à implémenter une architecture de données fortement dénormalisée. Par suite, les opérations en écritures deviennent alors plutôt lentes.

Cassandra
(7ième base de données la plus utilisée, 2ième parmi les non-RDBMS)
Cassandra est maintenant la base de données « orientée-colonne » la plus populaire du marché.
Pour offrir des performances optimales, Cassandra exige une infrastructure complexe et particulièrement importante (au principe que « hardware is cheap »). Dans une infrastructure traditionnelle, les performances de Cassandra ont la réputation de décliner avec le temps, en raison de la répartition des enregistrements sur plusieurs SStables. Il est possible d’éviter ces enjeux, mais cela requiert de développer une architecture applicative innovatrice. Miser sur Cassandra ne se résume donc pas seulement à utiliser un autre type de base de données; il faut aussi concevoir et implémenter une autre manière d’accéder aux données.

Redis
(9ième base de données la plus utilisée, 3ième parmi les non-RDBMS)
Le fonctionnement « en mémoire » de cette technologie la rend très populaire en tant qu’antémémoire sophistiquée ou système de stockage de variables globales dans le contexte d’applications complexes. Cependant son utilisation en tant que base de données crée un enjeu dû au fait que Redis ne sauvegarde physiquement les données qu’à certains intervalles (par exemple aux 15 minutes). Dans un contexte dynamique (plusieurs changements aux données), la persistance des données de Redis exigera assurément un travail d’innovation technologique.

Neo4J
(21ième base de données la plus utilisée, 8ième parmi les non-RDBMS)
L’intérêt de cette technologie repose sur son modèle graphique, qui se prête bien au développement d’applications impliquant des relations complexes, pratiquement de nature sémantique. Pour cette raison, Neo4J est souvent utilisée pour le développement d’applications de type « réseaux sociaux ».
Mais ces propriétés viennent avec leurs défis. Dans sa version courante, Neo4J se prête difficilement aux opérations de synchronisation entre ses nœuds de même qu’au partitionnement horizontal (« sharding »). Elle n’est pas non particulièrement performante lors des opérations d’écriture.
La conception d’infrastructures de serveurs particulièrement complexes et l’ajout de mécanismes sophistiqués de synchronisation seront requis pour compenser ces faiblesses.

En résumé
Chacune de ces nouvelles base de données pose des défis, qu’il s’agisse de la performance (en lecture ou en écriture), de la synchronisation ou de la réplication des données, de l’usage en « nuage », de la sécurité, etc.
Les entreprises souhaitent bénéficier du formidable potentiel que représentent ces nouvelles technologies, mais cela passe souvent par des phases d’expérimentation. Nos équipes pourront vous dire de quelle manière ce développement expérimental peut être admissible au crédit d’impôt pour la R&D.