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

118PARTAGES

9  0 
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.

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 ?
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

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