Serveurs de bases de données et bases de données embarquées : comparaison de l'architecture et des caractéristiques d'E/S

Serveur de base de données

Un serveur de base de données désigne une base de données fonctionnant comme un processus serveur indépendant et traitant les requêtes des applications via le réseau. La plupart des SGBDR bien connus, tels que MySQL, PostgreSQL ou Oracle DB, correspondent à ce modèle. Le serveur de base de données présente les avantages suivants.

• Gestion centralisée: les données sont gérées de manière intégrée en un seul endroit, ce qui facilite la cohérence, la sécurité, la sauvegarde et la restauration.
• Indépendance des ressources: il dispose de son propre processeur, de sa propre mémoire et de son propre stockage, ce qui garantit des performances stables indépendamment de l'état des applications.
• Forte concurrence et extensibilité élevée: il est optimisé pour l'accès simultané de nombreux utilisateurs et se prête relativement bien à une extension horizontale grâce au clustering ou à la réplication.

Grâce à ces caractéristiques, le serveur de base de données s'est imposé comme la norme de l'infrastructure logicielle pendant plusieurs dizaines d'années. Toutefois, sous l'effet de l'évolution technologique et des changements d'environnement, certaines limites du serveur de base de données sont apparues dans certains contextes, et les bases de données embarquées suscitent de nouveau l'attention en tant qu'alternative.

Nouvelle tendance : la base de données embarquée

Une base de données embarquée est un moteur de base de données intégré à une application sous forme de bibliothèque, sans processus serveur distinct, et s'exécutant au sein du même processus. SQLite, LevelDB et RocksDB en sont des exemples représentatifs. Les raisons pour lesquelles ces bases de données embarquées s'imposent comme une alternative puissante dans l'environnement technologique actuel sont les suivantes.

• L'avènement des SSD

  Dans les systèmes fondés sur les HDD, les performances d'accès aléatoire étaient nettement inférieures à celles de la lecture et de l'écriture séquentielles. Par conséquent, réduire les E/S disque et maximiser la mise en cache en mémoire constituaient le cœur de l'optimisation des performances. Les serveurs de base de données ont alors exploité de vastes caches et regroupé les opérations d'écriture afin de surmonter les limites physiques des HDD.

  Toutefois, l'avènement des SSD a entièrement bouleversé ces hypothèses. Les SSD offrent des performances d'accès aléatoire supérieures de plusieurs milliers de fois à celles des HDD, et leur latence est sensiblement plus faible. Il en résulte que la conviction selon laquelle « les E/S disque constituent le principal goulot d'étranglement » a disparu, et que la latence liée à l'accès réseau à un serveur de base de données distant a commencé à apparaître comme le nouveau goulot d'étranglement.

• MSA et indépendance des données

  Auparavant, la structure la plus courante consistait en une application monolithique unique reposant sur une base de données centralisée unique. Bien que simple, cette approche présentait un inconvénient : à mesure que la taille du service augmentait, les modifications du schéma de données devenaient difficiles, et le fait que tous les services partagent la même base de données entraînait un couplage excessivement fort.

  Dans l'architecture microservices moderne, le principe « Database per Service » est considéré comme essentiel pour résoudre ce problème. Chaque service possède et encapsule son propre espace de stockage de données dédié, ce qui garantit l'indépendance entre les services et facilite l'isolation des pannes ainsi que l'extension. Dans ce contexte, la base de données embarquée devient un choix idéal comme espace de stockage à l'échelle d'un service. Légère et rapide, elle peut être déployée avec le code du service, ce qui la rend parfaitement adaptée à un environnement MSA.

  Dans les environnements Kubernetes, on utilise largement le motif sidecar, qui consiste à placer une base de données embarquée à côté du conteneur applicatif afin d'optimiser le traitement local des données. Cette approche permet de réduire les goulots d'étranglement réseau et de minimiser la latence d'accès aux données.

• Simplification de l'environnement d'exploitation

  Un serveur de base de données exige des procédures d'exploitation complexes, notamment l'installation, l'application de correctifs, la sauvegarde, la reprise après incident, la réplication et la surveillance des performances, et nécessite pour cela des administrateurs de bases de données dédiés ainsi que des équipes d'exploitation spécialisées. Dans les environnements de grande envergure, cette charge de gestion est particulièrement lourde.

  La base de données embarquée atténue fortement ces difficultés. Lorsque la base de données est intégrée à l'intérieur de l'application, les tests unitaires, la compilation, la gestion des versions et le déploiement sont réalisés conjointement, de sorte qu'aucune exploitation de serveur distinct n'est nécessaire. En outre, lorsque l'application est mise à l'échelle horizontalement, la base de données embarquée est étendue en même temps, et une gestion automatisée grâce à la culture DevOps et aux pipelines CI/CD devient possible. En particulier, dans les startups, les petits services et les environnements de développement de prototypes, la base de données embarquée réduit considérablement la complexité opérationnelle et accélère nettement le développement et le déploiement.

• Langages système performants et évolution de l'écosystème

  Auparavant, il était courant que la base de données et l'application soient écrites dans des langages différents. Par exemple, les moteurs de bases de données exigeant de hautes performances étaient principalement écrits en C et C++, tandis que les applications étaient développées en Java, Python, PHP, etc. Cette approche était efficace pour l'optimisation des performances, mais présentait des limites : problèmes de sécurité de la mémoire, gestion complexe de la concurrence, latence, et difficultés d'intégration et de déploiement des bibliothèques.

  Cependant, l'émergence récente de langages de programmation système modernes tels que Go et Rust a fortement atténué ces limites. En particulier, Go, qui convient aussi bien aux applications hautes performances qu'à l'écriture de programmes de bas niveau tels que les moteurs de bases de données, permet désormais de traiter la base de données et l'application au sein d'un même écosystème linguistique.

  En effet, dans l'écosystème Golang, des bases de données embarquées hautes performances telles que BadgerDB et PebbleDB sont activement utilisées. Cela signifie que la base de données embarquée ne se limite pas à une alternative légère au serveur de base de données, mais s'impose comme un choix important doté de sa propre compétitivité.

Conclusion

Pour les exigences de gestion centralisée de données volumineuses, de transactions complexes et de forte concurrence, le serveur de base de données demeure la solution la plus puissante. Cependant, pour les services individuels d'une architecture MSA, les dispositifs IoT en périphérie, le prototypage rapide et les projets où l'efficacité opérationnelle est essentielle, la base de données embarquée peut constituer un choix plus efficace et plus rationnel. En définitive, l'essentiel est de sélectionner l'outil optimal, le mieux adapté à la situation et aux besoins donnés, et l'évolution des bases de données embarquées nous offre des choix plus larges et plus variés.