1 pièce(s) jointe(s)
Red Hat Satellite va se séparer de MongoDB Community Edition et conservera PostgreSQL
Red Hat Satellite va se séparer de MongoDB Community Edition et conservera PostgreSQL
comme base de données unique
Ce 12 février, Red Hat a fait une annonce selon laquelle l’entreprise abandonnera dans les prochains mois MongoDB pour normaliser le backend PostgreSQL. Dans son intention de passer à une base de données unique, l’équipe de développement de Red Hat Satellite a donc porté son choix sur PostgreSQL. La raison évoquée par Red Hat pour cette suppression de MongoDB est que, PostgreSQL serait une meilleure solution pour les types de données et d’utilisations requis par Satellite. L’équipe de Red Hat Satellite invite à cet effet la communauté à se préparer à ce changement.
Red Hat Satellite, décrit l’entreprise, est une solution de gestion de système qui simplifie le déploiement et la gestion de l’infrastructure Red Hat dans des environnements physiques, virtuels et en nuage. Cet outil de gestion aide les utilisateurs à provisionner, configurer et mettre à jour les systèmes afin de les maintenir efficaces, sécurisés et conformes à diverses normes. D’après Red Hat, en automatisant la plupart des tâches de maintenance du système, Red Hat Satellite aide les organisations à accroître leur efficacité, à réduire leurs coûts d'exploitation et à permettre à l'informatique de mieux répondre aux besoins stratégiques de l'entreprise.
Pourquoi supprimer MongoDB Community Edition ?
L’entreprise a répondu que jusque là, Red Hat Satellite utilisait deux bases de données sous-jacentes : MongoDB et PostgreSQL. Mais depuis 2016, l’équipe aurait trouvé un avantage à utiliser une base de données relationnelle avec annulation et transactions pour les fonctionnalités nécessaires dans Pulp et finalement Satellite. PostgreSQL qui était déjà présent répondait donc à ses avantages. Pour rappel, Pulp est une plate-forme permettant de gérer les référentiels de progiciels et de les rendre disponibles pour un grand nombre de consommateurs. Pulp peut mettre en miroir localement tout ou partie d'un référentiel, héberger vos propres progiciels dans des référentiels et gérer de nombreux types de contenu provenant de plusieurs sources en un seul endroit.
« Les raisons de cette orientation sont que nous estimons que PostgreSQL est une meilleure solution pour les types de données et d’utilisation requis par Satellite. En outre, l'unification sur un système de base de données unique simplifie l'architecture globale de Satellite et peut faciliter la reprise en charge, la sauvegarde et la reprise après un crash », a expliqué l’équipe. Cependant, certains internautes voient la chose autrement. Sur Reddit par exemple, un parmi eux estime que ce retrait, pour lui, commence à annoncer la chute de MongoDB à l’image de RethinkDB, avec son nouveau modèle commercial à code source fermé. D'autres par contre souhaiteraient plutôt que Red Hat trouve une alternative à MongoDB dans Red Hat Satellite dans ses prochaines versions.
Quel impact aura ce changement sur les fonctionnalités ou les performances reconnues à Red Hat Satellite ?
Pour cela, l’équipe a assuré qu’elle ne prévoyait aucun impact significatif sur les performances de Red Hat Satellite avec la suppression de MongoDB. Un effort considérable a été déployé, dit l’équipe, pour éviter tout dommage sur les fonctionnalités du logiciel avec le retrait de MongoDB afin que ses utilisateurs bénéficient toujours du meilleur de la solution. Une autre question qui subsiste est : qu’adviendra-t-il des versions actuelles de Red Hat Satellite qui prennent en charge MongoDB Community Edition ? À cela, l’équipe a indiqué que les versions actuelles de Red Hat Satellite qui intègrent MongoDB continueront d’être prises en charge et bénéficieront de correctifs de problèmes en cas de nécessité.
Voici ce qu’elle a écrit à propos : « la version intégrée de MongoDB continuera à être prise en charge dans les versions de Red Hat Satellite dans lesquelles elle a déjà été publiée. MongoDB est incorporé dans les versions actuellement prises en charge de Red Hat Satellite 6. Si un correctif est nécessaire, plutôt que de passer à une nouvelle version de MongoDB, l'équipe créera un correctif pour le problème. Ainsi, l'équipe Satellite corrigera MongoDB selon les besoins jusqu'à sa suppression progressive ».
Cette annonce de Red Hat vient peut-être donner un avantage à PostgreSQL qui aurait traîné une mauvaise configuration depuis 20 ans. En effet, c’est au FOSDEM de cette année qui a eu lieu ces 2 et 3 février à Bruxelles que le sujet a été abordé à nouveau par Thomas Vondra, un ingénieur de base de données et contributeur au projet PostgreSQL. Il s’agit de l’implémentation de fsync() au sein du gestionnaire de base de données PostgreSQL. D’après ces propos, fsync() ne marche pas réellement comme on le pense sur Linux et d’autres systèmes BSD et peut ainsi avoir des conséquences potentiellement désastreuses pour la durabilité/cohérence des données.
Rappelons que le paramètre fsync() permet de transférer toutes les données internes modifiées d’un fichier référencé par le descripteur de fichier fd (c'est-à-dire les pages de cache tampon modifiées) vers le périphérique de disque (ou un autre périphérique de stockage permanent), de sorte que toutes les informations modifiées puissent être récupérées même après une panne du système ou son redémarrage. Cela inclut l'écriture ou le vidage d'un cache de disque, le cas échéant. L'appel est bloqué jusqu'à ce que l'appareil signale que le transfert est terminé. Seulement, ce n’est pas exactement ce que fait la fonction avec le serveur de base de données PostgreSQL.
Si ce paramètre est activé, indique la documentation du serveur PostgreSQL, ce dernier essayera de s’assurer que les mises à jour sont écrites physiquement sur le disque en émettant des appels fsync() système ou diverses méthodes équivalentes. Cela garantit que le cluster de base de données peut retrouver un état cohérent après une panne matérielle ou du système d'exploitation. Toujours dans cette documentation, il est noté que, bien que la désactivation de fsync() soit souvent un avantage en termes de performances, cela peut entraîner une corruption irrémédiable des données en cas de panne de courant ou de panne du système. Il y a eu bien évidemment des propositions de corrections pour palier à ce problème.
Source : Red Hat
Et vous ?
:fleche: Que pensez-vous de cette annonce de Red Hat ?
Voir aussi
:fleche: Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données, des solutions ont été proposées au FOSDEM 2019
:fleche: Disponibilité générale de PostgreSQL 11 : un aperçu des principales fonctionnalités du SGBDRO libre
:fleche: Microsoft fait l'acquisition de Citus Data l'extension qui transforme PostgreSQL en une base de données distribuée
:fleche: Emploi développeur 2017 : les SGBD les plus demandés et les mieux payés, MySQL, MongoDB et PostgreSQL plus demandés mais MongoDB et DB2 mieux payés
:fleche: DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017, quels étaient vos SGBD préférés en 2017 ?
