En matière de structure de base de données, les entreprises ont essentiellement un choix : relationnelle (SQL) ou non relationnelle (NoSQL). Les premiers organisent les données dans une série de tables et ont un schéma prédéfini, tandis que les seconds ont des schémas dynamiques pour les données non structurées. Mais qu’est-ce qui est mieux ?
Avec l’essor de la technologie du cloud et des conteneurs, le système de base de données relationnelle et open source PostgreSQL (ou Postgres comme on l’appelle affectueusement) fait preuve d’une polyvalence remarquable. Bien qu’il existe depuis plus de trois décennies, il n’a pas peur d’apprendre de nouvelles astuces de ses plus jeunes cousins NoSQL.
TechRadar Pro s’est entretenu avec Marc Linster, CTO de la société de bases de données open source EDB, pour découvrir les avantages de Postgres et les qualités qui le distinguent des alternatives propriétaires et non relationnelles.
Sommaire
Quelle est la pertinence des bases de données relationnelles à l’ère du NoSQL ?
NoSQL signifie « pas seulement SQL », et cela explique pourquoi Postgres est clairement le vainqueur du classement de DB-Engines, de l’enquête auprès des développeurs de Stackoverflow et du radar de technologie de base de données de la Cloud Native Computing Foundation.
Postgres, contrairement aux autres bases de données relationnelles, est construit sur une architecture objet-relationnelle. C’est pourquoi il est le leader dans la combinaison de données relationnelles avec des données géospatiales, des paires clé-valeur, des données de document et des types de données personnalisés.
Cette décision de conception clé, prise par Mike Stonebraker il y a plus de 25 ans, favorise l’adoption rapide de Postgres par les développeurs et les administrateurs de base de données. Le classement de DB-Engines montre que l’adoption de Postgres dépasse MongoDB ; la même chose se reflète dans le Tech Radar de la CNCF et dans l’enquête Stackoverflow.
Les bases de données uniquement relationnelles ne présentent pas de tendances d’adoption similaires et peuvent devenir moins pertinentes au fil du temps.
EDB est une boutique Postgres depuis le début des années 2000. Quels changements l’avènement des services natifs du cloud a-t-il eu sur les bases de données traditionnelles comme PostgreSQL au fil des ans ?
Postgres a étonnamment bien passé l’épreuve du temps. En fait, l’héritage de Postgres contribue à le rendre plus fort à mesure qu’il mûrit. C’est la base de données n°1 dans les conteneurs et un composant clé de tous les services de base de données des fournisseurs de cloud. Les offres cloud natives, telles que l’opérateur Cloud Native Postgres d’EDB pour Kubernetes, continuent de rendre Postgres plus facile et plus accessible à un public plus large.
De nombreuses bases de données traditionnelles, commerciales et propriétaires ont connu un déclin, mais Postgres a connu une croissance considérable parallèlement au cloud. Le fait que Postgres soit open source, rentable, innovant, puissant et extrêmement fiable a contribué à cette croissance. Postgres fonctionne également partout sous la même licence permissive, ce qui est une autre raison de sa popularité croissante.
Postgres, l’open source et l’adoption du cloud, ainsi que Kubernetes et les microservices, ont tous une chose en commun : une innovation rapide motivée par le besoin de transformation numérique, une vitesse élevée des fonctionnalités et une meilleure adéquation avec le marché des produits.
Le changement clé que nous avons vu est la maturation de l’infrastructure en tant que code, que ce soit via les opérateurs Kubernetes ou via des outils comme Ansible, qui permettent des déploiements Postgres rapides et reproductibles sur site, dans le cloud et dans les environnements DevOps.
L’évolutivité est l’un des avantages que revendiquent les bases de données NoSQL par rapport aux bases de données relationnelles. Comment Postgres a-t-il évolué dans cet aspect ?
Plus de 95+ % de toutes les bases de données actuelles s’adaptent confortablement aux serveurs informatiques avancés disponibles aujourd’hui dans le cloud ou sur site. Très peu d’applications ont réellement besoin d’une évolutivité horizontale à un moment où 96 cœurs ou plus sont régulièrement disponibles dans le cloud et dans la plupart des centres de données. Un argument historiquement avancé par les partisans de la mise à l’échelle horizontale a été qu’il est difficile de faire évoluer le calcul et la mémoire vers le haut et vers le bas.
L’infrastructure en tant que technologie de code, comme Kubernetes et Ansible, rend la mise à l’échelle des ressources CPU et mémoire très simple et rapide – beaucoup plus facile et plus rapide que la mise à l’échelle.
N’oubliez pas non plus que la mise à l’échelle sur plusieurs serveurs signifie une latence importante, car davantage de données circulent sur le réseau, ce qui est beaucoup plus lent que le fond de panier d’un serveur ou le bus de données d’une puce moderne à haute densité.
Dans le même temps, avec l’avènement des microservices, nous voyons beaucoup plus de conceptions « intelligentes » qui refactorisent de très grandes bases de données en architectures plus petites et plus intelligentes. Il est beaucoup plus facile de résoudre les problèmes dès le départ avec une bonne conception, plutôt que d’essayer de les résoudre par la suite en leur lançant du matériel. Heureusement, Kubernetes et les micro-services encouragent les conceptions intelligentes.
Quels sont les aspects pour lesquels les bases de données relationnelles en général et PostgreSQL en particulier obtiennent des scores par rapport aux bases de données NoSQL ?
Souvent, NoSQL est utilisé comme synonyme de « cohérence à terme », et relationnel signifie en réalité « ACID » (atomique, cohérent, isolé, durable). Les bases de données conformes à ACID sont hautement fiables et les résultats des opérations dans ces environnements sont hautement prévisibles. C’est essentiel pour les transactions commerciales, les opérations comptables et toute autre tâche de gestion de données nécessitant une fiabilité à 100 %. De plus, la plupart des outils d’analyse sont conçus pour fonctionner avec des tables et des relations. Souvent, les formats NoSQL, comme les documents, doivent d’abord être mappés dans des structures tabulaires afin d’effectuer des analyses. Cela est également vrai pour map reduce, qui prend des données non structurées et les met dans un format tabulaire et relationnel structuré pour prendre en charge les requêtes.
La nature du modèle relationnel, en particulier l’utilisation de formulaires normaux, fournit au développeur un outil très puissant pour éviter la redondance des données et créer des modèles de données qui ne sont pas spécifiques à un seul cas d’utilisation.
Alors que de plus en plus d’organisations adoptent une stratégie multi-cloud et mélangent leurs bases de données cloud avec celles hébergées sur site, dans quelle mesure PostgreSQL se prête-t-il à un tel environnement interopérable ?
Postgres a choisi la couche d’abstraction POSIX (Portable Operating System Interface) comme interface avec le système d’exploitation. Cela lui permet de fonctionner pratiquement partout et explique pourquoi il fonctionne dans chaque cloud, dans des conteneurs, avec tous les systèmes d’exploitation clés et avec pratiquement toutes les plates-formes matérielles. EDB compte de nombreux clients qui ont stratégiquement décidé de développer sur la base de l’API Postgres, car cela leur permet de créer des applications pouvant être déployées partout où cela est nécessaire.
Contrairement à d’autres bases de données commerciales qui limitent certaines de leurs fonctionnalités pour une haute disponibilité à leur propre cloud, il n’y a pas de telles restrictions avec Postgres. EDB Postgres fournit le même Postgres hautement disponible et toujours actif sur toutes les plates-formes, et pas seulement sur certaines lignes matérielles sélectionnées ou certains clouds propriétaires.
Cette portabilité extrême fait de Postgres la plate-forme idéale pour les stratégies hybrides ou multi-cloud.
EDB entretient une relation symbiotique avec la communauté open source PostgreSQL depuis le tout début. Quelle est l’importance de cette relation pour les fournisseurs commerciaux avec un modèle commercial basé sur des logiciels open source ?
Rien de ce que nous faisons ne serait possible sans une communauté Postgres dynamique, indépendante et innovante. EDB est un fervent partisan de la communauté. Nous comptons près de 30 EDBers à temps plein qui sont nommés comme contributeurs, commiters ou membres de l’équipe principale de Postgres, et nous avons 300 technologues dédiés à Postgres, le plus au monde de loin. Être des fanatiques de Postgres signifie que nous nous engageons sans relâche à poursuivre notre investissement dans les logiciels open source et la communauté où nous collaborons avec Microsoft, VMWare, NTT, Fujitsu et bien d’autres pour créer la technologie open source la plus transformatrice depuis Linux.
Comme le dit mon collègue Dave Page, membre de l’équipe principale de Postgres, « Nous collaborons sur le code et nous sommes en concurrence sur le marché ». Ce modèle collaboratif et symbiotique est extrêmement important pour le succès d’EDB et pour l’adoption croissante de Postgres.
