IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Neon PostgreSQL, une nouvelle approche moderne du développement bases de données, est disponible :
Autogéré, extensibilité automatique, calculs et stockage séparé pour être plus évolutif

Le , par Jade Emy

54PARTAGES

9  0 
Neon dévoile une nouvelle approche du développement de bases de données : Neon PostgresSQL. Neon permet de réduire les coûts de démarrage, d'arrêt, de création et de clonage des bases de données de plusieurs heures à quelques secondes.

Postgres reste l'une des bases de données de développement les plus populaires jamais créées. Alors que MySQL a perdu de son éclat après son rachat par Oracle, Postgres continue de gagner la confiance des développeurs. En 2023, elle est arrivée en tête du sondage StackOverflow Developers Survey et, la même année, a été élue SGBD de l'année par DBEngines. Le mème internet actuel est "Just Use Postgres" pour tout.

Malgré sa popularité, Postgres souffre des deux problèmes qui affectent presque toutes les bases de données relationnelles. Il est difficile d'augmenter ou de diminuer la taille de la base de données sans interruption. Pire encore, il faut beaucoup de temps pour rétablir les opérations de production lorsque des bogues logiciels affectent les données.

En effet, avec Postgres, il est difficile de créer un environnement de développement très fidèle, car il faut copier l'état complet de la base de données. De plus, le maintien de plusieurs copies des données et du schéma pour chaque développeur est une véritable plaie. La base de données devient le point névralgique du développement pour la plupart des équipes et constitue invariablement le goulot d'étranglement qui limite la vélocité des développeurs.



Les besoins des développeurs

Lorsque l'équipe d'ingénieurs de Neon a abordé ces questions, elle savait qu'elle devait résoudre plusieurs problèmes liés au cycle de vie actuel du développement des bases de données :

  1. Ils voulaient que la création d'un cluster Postgres soit rapide (moins d'une seconde).
  2. Ils voulaient que les clusters Postgres soient capables d'évoluer automatiquement vers le haut ou vers le bas en fonction de la charge. Vous n'avez pas à vous soucier d'un provisionnement excessif ou insuffisant.
  3. Ils voulaient pouvoir créer des branches avec des données complètes copiées instantanément afin que les développeurs puissent travailler indépendamment tout en étant capables de collaborer efficacement.
  4. Ils voulaient pouvoir restaurer un point dans le temps en quelques secondes au lieu d'heures ou de jours.

Presque toutes les applications ont besoin d'une base de données, et alors que les outils et les flux de travail des développeurs ont évolué avec des plateformes comme GitHub et Vercel, les bases de données n'ont pas évolué pour correspondre à l'expérience des développeurs de ces systèmes. L'évolution de l'expérience des développeurs autour de la base de données nécessite de repenser fondamentalement l'architecture de la base de données. Mais il ne s'agit pas d'un moteur "regardez notre nouvelle base de données cool". les développeurs aiment et veulent utiliser l'authentique logiciel open-source Postgres.

C'est pourquoi, chez Neon, ils ont cherché à modifier l'expérience de développement sur Postgres sans perdre tout ce qui fait la qualité de Postgres.

Nous avons emprunté une idée à Amazon Aurora, la séparation du stockage et de l'informatique, et nous ne parlons pas de la simple utilisation d'un disque connecté au réseau comme EBS. Une véritable séparation du stockage et du calcul a ouvert la possibilité de faire évoluer les deux parties du service de manière indépendante. Contrairement à AWS Aurora, nous avons décidé de mettre en open source toutes les modifications apportées à Postgres et de les envoyer en amont, ainsi que de mettre en open source notre stockage natif dans le nuage.

Nous avons pris des décisions architecturales qui garantissent à nos utilisateurs une expérience complète de Postgres, y compris les extensions, les éléments internes, la ligne de commande et les outils de gestion. Tout ce qui fonctionne sur site devrait fonctionner dans notre service en nuage.


Un autre avantage de la séparation du stockage et du calcul est qu'on dispose d'une toute nouvelle implémentation de stockage natif dans le nuage et qu'il est possible de "faire des choses" dedans. Le contrôle du stockage permet d'implémenter le branching, une fonctionnalité phare qui améliore l'expérience des développeurs dans la création d'applications de bases de données.

Qu'est-ce que cela signifie pour l'utilisateur ?

Cela signifie qu'on peut créer des branches à tout moment et démarrer une instance de calcul pointant vers cette version de base de données. Ainsi, chaque développeur peut travailler sur une branche différente sans empiéter sur le travail de ses collègues.


L'informatique peut désormais évoluer indépendamment du stockage, de sorte que la taille et le nombre de CPU peuvent correspondre précisément à la charge. Même les charges de bases de données importantes connaissent des pics et des creux. L'équipe de Neon voulait éviter aux développeurs d'avoir à dimensionner leur système en fonction de la plus grande charge attendue.

Une branche de base de données est copiée à l'écriture, ce qui signifie qu'elle pointe uniquement vers un ensemble de pages déjà créées et stockées. La création d'une branche prend donc moins d'une seconde. Parce qu'elles sont copiées en écriture, les branches ne subissent aucune surcharge d'espace jusqu'à ce que des données leur soient écrites.

Supposons qu'un développeur mette fin à une table ou à une base de données à l'aide d'un "fat finger" ? Pas de problème, il suffit de déplacer la branche à la seconde précédant cet événement. Le démarrage d'une nouvelle base de données ou la reprise d'une production défaillante se fait en quelques secondes, car l'architecture Neon ne nécessite pas l'envoi de centaines de gigaoctets de données pour créer de nouvelles instances de bases de données et de serveurs.

Les utilisateurs ne veulent pas de bases de données, ils veulent des données. Neon est conçu pour réduire les coûts de démarrage, d'arrêt, de création et de clonage des bases de données de plusieurs heures à quelques secondes. La base de données relationnelle est le principal frein à la vélocité du développement moderne. Imaginez que les données soient faciles à obtenir, quel serait l'impact sur la productivité de vos développeurs ?

Avec Neon, le branchement des bases de données est intégré directement dans le flux de travail du développeur, sans interruption. Lorsque les modifications des données et/ou du schéma de la base de données prennent des heures à se propager au sein de l'équipe de développement, tout le monde en pâtit.

Neon est le prochain grand pivot de Postgres, et tous ces changements ont été proposés en amont à la communauté Postgres. Ils sont disponibles dans notre repo public dès aujourd'hui. Notre mission est de fournir tout ce dont les développeurs Postgres ont besoin et moins. Moins d'attente pour le démarrage des clusters, moins d'attente pour la restauration des bases de données, moins d'attente pour le déploiement des changements entre collègues, moins d'attente pour la programmation des mises à jour par l'équipe DBA.


Comment Neon en est arrivé là ?

Au cours de son avant-première, l'équipe de Neon s'est concentré sur la construction d'une base technique solide pour Neon. Voici quelques-unes de ses étapes :

  • En décembre 2022, ils ont supprimé l'accès à Neon sur invitation uniquement. Aujourd'hui, des milliers de nouvelles bases de données Neon sont créées chaque semaine. Neon comprend un niveau gratuit généreux qui est là pour rester : l'architecture de Neon permet de la supporter efficacement.
  • Ils ont rendu le branchement de bases de données accessible à tous. Aujourd'hui, des dizaines de milliers de branches sont créées chaque semaine par les utilisateurs de Neon. Les branches Neon incluent les données et les schémas, ce qui permet aux développeurs de créer des copies isolées de leurs données en une seconde.
  • Neon a également inclus la prise en charge de l'API dès le départ. L'API de Neon est aujourd'hui devenue un outil robuste qui permet aux partenaires de Neon de gérer facilement des parcs de centaines de milliers de bases de données. Ils automatisent toutes les opérations de base de données via l'API, ce qui supprime le besoin de DevOps dédiés à la gestion des parcs Postgres.
  • Ils ont également lancé un pilote sans serveur. Aujourd'hui, le pilote sans serveur Neon compte plus de 100 000 téléchargements hebdomadaires. Les développeurs l'utilisent pour accélérer leurs déploiements JavaScript et Typescript.
  • En ce qui concerne l'accélération des déploiements, ils ont lancé l'intégration Vercel, qui crée une branche de base de données pour chaque prévisualisation. Aujourd'hui, des milliers de branches de base de données Neon ont été créées via l'intégration Vercel.
  • Quelques mois après le début de la Preview, ils ont publié la première version de l'autoscaling, une fonctionnalité fondamentale qui élargit l'expérience sans serveur de Neon. Aujourd'hui, des milliers d'événements de mise à l'échelle automatique se produisent chaque semaine, évitant aux développeurs le travail de redimensionnement manuel.
  • Ils ont également mis le CLI de Neon à la disposition de tous les utilisateurs, afin que les développeurs puissent simplifier leurs intégrations et leurs automatismes en gérant Neon directement depuis leur terminal. Aujourd'hui, ce CLI compte des centaines d'utilisateurs actifs hebdomadaires.
  • Au cours des mois d'avant-première, ils ont mis l'accent sur l'amélioration du comportement de mise à zéro et de démarrage à froid. Aujourd'hui, des dizaines de milliers de bases de données Neon sont mises à zéro chaque jour, ce qui permet aux développeurs d'économiser de l'argent. Ils continuent à travailler sur les mesures de démarrage à froid : on est maintenant à un P50 de 500 ms pour démarrer une base de données, et ils travaillent à le réduire encore plus.

Neon Postgres est généralement disponible. La mise à l'échelle automatique sans serveur et le branchement instantané sont conçus pour les développeurs modernes qui doivent itérer rapidement.

Source : Annonce de Neon

Et vous ?

Quel est votre avis sur le sujet ?
Pensez-vous que Neon PostgresSQL est crédible ou pertinent ?

Voir aussi :

Le projet PostgreSQL étudie un changement majeur qui pourrait sacrifier des fonctionnalités importantes. Pour les bénéfices attendus, cela vaut-il la peine ?

Postgres 16 est désormais disponible dans Azure Cosmos DB for PostgreSQL, alimenté par Citus

La Grande Migration de MongoDB vers PostgreSQL : comment Infisical a réussi le passage. Quelles sont les raisons qui l'ont motivée à quitter MongoDB et pourquoi s'est-elle orientée vers PostgreSQL ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 17/04/2024 à 3:31
En dépit de ses défauts, pgSQL reste le meilleur choix à l'heure actuelle pour démarrer un nouveau projet. L'expérience récente nous l'a montré, utiliser des solutions propriétaires peut s'avérer dangereux, les coûts d'utilisation peuvent exploser du jour au lendemain, suite à un rachat ou si le développeur a besoin de cash.
8  1 
Avatar de ced
Rédacteur/Modérateur https://www.developpez.com
Le 17/04/2024 à 10:19
Bonjour,

Citation Envoyé par SQLpro Voir le message
Ceci est normal sous PostGreSQL qui ne sait pas faire des sauvegardes binaires mais seulement des copies de fichier avec interruption de service, ou ien des sauvegardes immédiatement obsolète car le point de restauration d'un DUMP PG est le moment du début de la sauvegarde et non la fin...
Encore une fois, vous écrivez n'importe quoi !
Bien sûr que PostgreSQL sait faire des sauvegardes physiques à chaud et complètes à la fin de la sauvegarde : ça s'appelle la sauvegarde PITR. Vous vous limitez à la sauvegarde logique (via pg_dump), mais ce n'est pas la seule solution...

Citation Envoyé par SQLpro Voir le message
En sus la haute disponibilité AlwaysOn propage toutes les transactions, y compris les modifications de schéma sur tous les réplicas ce que PostGreSQL est toujours incapable de faire...
Là aussi, ce que vous écrivez n'est pas exact (en tout cas tel qu'affirmé en ces termes). Les modifications de schéma sont bien propagées sur tous les réplicats avec la réplication physique. C'est la réplication logique qui, plus récente dans l'historique des versions de PostgreSQL, n'est pas encore capable de le faire...

ced
7  1 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 16/04/2024 à 19:20
Malgré sa popularité, Postgres souffre des deux problèmes qui affectent presque toutes les bases de données relationnelles. Il est difficile d'augmenter ou de diminuer la taille de la base de données sans interruption. Pire encore, il faut beaucoup de temps pour rétablir les opérations de production lorsque des bogues logiciels affectent les données.
Aucune interruption n'est nécessaire sous MS SQL Server qui peut être "agrandie" à chaud dans tous les domaines (RAM, CPU, disques, volumes... voir sp_configure) et dont les patch et CU ne nécessite aucun arrêt de service.... Et dans le pire des cas, les Patch système ne nécessite pas non plus d'arrêt des applicatifs si l'on opte pour la haute disponibilité synchrone à basculement automatique (AlwaysOn), les applications ne voyant aucunement le passage de l'une à l'autre des instances....

... avec Postgres, il est difficile de créer un environnement de développement très fidèle, car il faut copier l'état complet de la base de données. De plus, le maintien de plusieurs copies des données et du schéma pour chaque développeur est une véritable plaie.
Ceci est normal sous PostGreSQL qui ne sait pas faire des sauvegardes binaires mais seulement des copies de fichier avec interruption de service, ou ien des sauvegardes immédiatement obsolète car le point de restauration d'un DUMP PG est le moment du début de la sauvegarde et non la fin...
Sous SQL Server, la sauvegarde d'une base est binaire se fait à chaud, son point de restauration est le moment de la fin de la sauvegarde et sa restauration strictement identique au bit près pour toutes les tables et index de productions comme les tables et index système. Et SQL Server est entre 3 et 8 fois plus rapide que PostGreSQL pour les sauvegardes et restaurations...
En sus la haute disponibilité AlwaysOn propage toutes les transactions, y compris les modifications de schéma sur tous les réplicas ce que PostGreSQL est toujours incapable de faire.... Les réplicas AlwaysOn étant lisibles...

Enfin le clonage des bases par DBCC CLONEDATABASE est instantané....

A +
3  6