Serveurs de bases de données et bases de données embarquées

Serveur de base de données

Un serveur de base de données désigne une base de données exécutée en tant que processus serveur indépendant, traitant les requêtes des applications via le réseau. La plupart des SGBDR qui nous sont familiers, tels que MySQL, PostgreSQL et Oracle DB, correspondent à ce modèle. Un 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, facilitant la cohérence, la sécurité, la sauvegarde et la récupération.
• Indépendance des ressources : Il dispose de son propre CPU, de sa mémoire et de son stockage alloués, garantissant des performances stables indépendamment de l'état de l'application.
• Concurrence et évolutivité élevées : Il est optimisé pour l'accès simultané de nombreux utilisateurs, et la mise à l'échelle horizontale via le clustering ou la réplication est relativement aisée.

Grâce à ces caractéristiques, le serveur de base de données s'est imposé comme la norme de l'infrastructure logicielle au cours des dernières décennies. Cependant, en raison des avancées technologiques et des changements environnementaux, les inconvénients des serveurs de base de données ont commencé à apparaître dans certains environnements, et les bases de données embarquées regagnent en attention en tant qu'alternative.

Nouvelle tendance : les bases de données embarquées

Une base de données embarquée est un moteur de base de données inclus sous forme de bibliothèque dans une application et exécuté dans le même processus, sans processus serveur distinct. SQLite, LevelDB et RocksDB sont des exemples typiques de bases de données embarquées. Les raisons pour lesquelles ces bases de données embarquées sont devenues une alternative puissante dans les environnements technologiques modernes sont les suivantes :

• L'émergence des SSD

  Dans les environnements système dominés par les HDD par le passé, les performances d'accès aléatoire étaient considérablement inférieures à celles de la lecture/écriture séquentielle des données. Par conséquent, la clé de l'optimisation des performances était de minimiser les E/S disque et de maximiser la mise en cache en mémoire. Les serveurs de base de données ont surmonté les limites physiques des HDD en exploitant de grands caches et en regroupant les opérations d'écriture pour les traiter.

  Cependant, l'émergence des SSD a complètement changé cette prémisse. Les SSD sont des milliers de fois plus rapides que les HDD en termes de performances d'E/S aléatoires, et leur latence est considérablement plus courte. En conséquence, la perception précédente selon laquelle "les E/S disque sont le plus grand goulot d'étranglement" a disparu, et la latence résultant de l'accès à un serveur de base de données distant via le réseau a commencé à émerger comme un nouveau goulot d'étranglement.

• MSA et indépendance des données

  Par le passé, une application monolithique gigantesque dépendait généralement d'une base de données centralisée unique. Bien que cette approche soit simple, à mesure que la taille du service augmentait, la modification du schéma de données devenait difficile, et le partage de la même base de données par tous les services entraînait un couplage excessivement fort.

  Dans l'architecture de microservices moderne, le principe de "Database per Service" est crucial pour résoudre ces problèmes. En possédant et en encapsulant son propre stockage de données dédié, chaque service garantit l'indépendance entre les services, et l'isolation des pannes et l'évolutivité sont facilitées. Dans ce processus, les bases de données embarquées deviennent un choix idéal pour le stockage de données au niveau du service. Légères et rapides, elles peuvent être déployées avec le code du service, ce qui les rend très adaptées aux environnements MSA.

  Dans les environnements Kubernetes, par exemple, la pratique courante consiste à placer une base de données embarquée à côté du conteneur d'application via le modèle Sidecar pour optimiser le traitement des données locales. Cela a pour effet 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

  Les serveurs de base de données nécessitent des procédures d'exploitation complexes telles que l'installation, les correctifs, la sauvegarde, la récupération après sinistre, la réplication et la surveillance des performances, ce qui exige des DBA dédiés et du personnel d'exploitation spécialisé. Ce fardeau de gestion est particulièrement lourd dans les environnements à grande échelle.

  Les bases de données embarquées atténuent considérablement ces problèmes. Lorsque la base de données est intégrée à l'application, les tests unitaires, la construction, la gestion des versions et le déploiement sont effectués ensemble, éliminant ainsi le besoin d'un fonctionnement serveur distinct. De plus, lorsque l'application s'adapte horizontalement (Scale-out), la base de données embarquée s'étend également, et une gestion automatisée via la culture DevOps et les pipelines CI/CD devient possible. En particulier dans les startups, les petits services et les environnements de développement de prototypes, les bases de données embarquées réduisent considérablement la complexité opérationnelle et augmentent considérablement la vitesse de développement et de déploiement.

• Développement des langages de système haute performance et de leur écosystème

  Par le passé, il était courant que les bases de données et les applications soient écrites dans des langages différents. Par exemple, les moteurs de base de données nécessitant des performances élevées étaient principalement écrits en C, C++, tandis que les applications étaient développées dans des langages tels que Java, Python, PHP. Bien que cette approche soit efficace pour l'optimisation des performances, elle présentait des limites telles que des problèmes de stabilité de la mémoire, un traitement complexe de la concurrence, une latence et des 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 considérablement atténué ces limitations. Go, en particulier, est adapté non seulement aux applications hautes performances, mais aussi à l'écriture de programmes de bas niveau tels que les moteurs de base de données, permettant de gérer la base de données et l'application ensemble au sein d'un même écosystème linguistique.

  En effet, des bases de données embarquées hautes performances telles que BadgerDB et PebbleDB sont activement utilisées en Golang. Cela signifie que les bases de données embarquées ne sont pas seulement une alternative légère aux serveurs de base de données, mais qu'elles sont devenues un choix important avec leur propre compétitivité.

Conclusion

Pour les conditions nécessitant une gestion centralisée de grandes quantités de données, des transactions complexes et une concurrence élevée, le serveur de base de données reste la solution la plus puissante. Cependant, pour les services individuels dans les environnements MSA, les appareils IoT Edge, le prototypage rapide et les projets où l'efficacité opérationnelle est importante, une base de données embarquée peut être un choix plus efficace et raisonnable. En fin de compte, l'important est de choisir l'outil optimal le mieux adapté à la situation et aux exigences données, et le développement des bases de données embarquées nous offre un éventail de choix plus large et plus diversifié.