Neon est une startup qui travaille sur une adaptation de Postgresql pour séparer la partie stockage de la partie calcul. Le stockage étant au final de type objet S3. Entre les deux il y a une partie cache pour les lectures.
Une grande partie est écrite en Rust, une partie est destinée à être intégrée à la branche commune de Postgresql. En licence Apache v2.0.
Le fait de séparer le stockage du calcul permet de lancer des instances à la demande en haute dispo, y compris de zéro (en cas d'inactivité). Le stockage objet permet d'avoir une excellente durabilité.
Autre avantage, le stockage est de type "copy on write" qui permet de faire des branches à n'importe quel endroit dans le temps. Comme PITR puisque mais instantané, plutôt plus proche des instantanés ZFS.
L'objectif est double.
A la fois de rendre Postgresql encore plus adapté au cloud, comme Aurora d'AWS.
A la fois de faciliter la vie des développeurs avec le système de branches.
Concrètement d'après ce que j'ai pu essayer :
On peut créer une base de données en une ou deux secondes.
La base de données s'arrête et redémarre tout seule, en une ou deux secondes également. Je l'ai testé avec une application CloudRun qui s'arrête également seule, c'est assez impressionnant.
Le plus intéressant pour moi c'est le système de branches. On peut avoir la branche principale qui est la version en production et créer instantanément une branche de développement, travailler dessus et la supprimer, repartir sur une autre branche pour refaire des essais etc. C'est beaucoup plus rapide que des faire des dumps/restore. Y a une API au besoin.
C'était en beta sur invitation, aujourd'hui ça passe en beta pour tout le monde, avec un free tiers sympa. Ca tourne pour l'instant dans quelques régions AWS desquelles il vaut mieux se rapprocher (j'ai testé Frankfort) mais à priori ça devrait se répandre chez d'autres hébergeurs et régions.
https://neon.tech/blog/neon-serverless-postgres-is-live/
https://neon.tech/docs/introduction/architecture-overview/
https://github.com/neondatabase/neon
# Serverless ?
Posté par Aldebaran (site web personnel) . Évalué à 3.
C'est intéressant, surtout la partie concernant les branches, mais en quoi c'est serverless ? C'est à cause du découplage stockage / calcul ?
Ou alors le mot n'a pas la signification que je lui donne ?
[^] # Re: Serverless ?
Posté par wilk . Évalué à 3.
Oui, en tout cas c'est comme ça qu'ils le décrivent https://neon.tech/blog/hello-world/
Vu que le stockage est à part la base et les branches existent même si aucun moteur n'est lancé.
[^] # Re: Serverless ?
Posté par Aldebaran (site web personnel) . Évalué à 3.
Ok, ça voudrait dire que l'on peut imaginer un cluster, avec X instances de postgres qui tournent et présentés par une api unique qui module la charge sur ces instances et à laquelle on a indiqué (au niveau de la session?) l'emplacement (S3 ou autre) du stockage BDD ?
Si c'est ça je comprend le côté 'serverless' si c'est un service, et seulement du point de vue de l'utilisateur du service, qui ne tapera que dans une api et ne gèrera jamais lui même les serveur. Et encore, si on dit ça j'imagine que le cloud est serverless alors.
[^] # Re: Serverless ?
Posté par wilk . Évalué à 3.
Y a les deux côtés, le côté interne c'est ça, l'instance POstgresql est découplée du stockage voir inexistante, c'est le vrai serverless si on considère que le stockage ça n'est pas du serveur.
Et le côté service, là c'est serverless pour le client mais pas pour le fournisseur où là pour le coup c'est du servermore vu qu'il va avoir un serveur pour le stockage, un pour la couche intermédiaire, un pour le moteur, un pour l'api etc !
ps: pour l'instant je ne crois pas qu'il y ait de read-replicas, donc une seule instance ou zéro, mais c'est prévu ainsi que le scaling vertical automatique (pour ne pas avoir à choisir le type d'instance).
[^] # Re: Serverless ?
Posté par barmic 🦦 . Évalué à 4.
De ce que je comprends c'est pas du serverless. Ils appellent serverless leur déploiement, mais c'est pas du tout ce qu'on entends généralement par serverless.
Ils ont un déploiement élastique, mais on peut lire ça dans leur description d'archi :
Compute Lifecycle
Garder une fonction en vie 5 minutes à rien faire c'est compliqué à faire et ce n'est pas souhaitable.
C'est un postgress probablement mieux taillé pour être déployé sur du cloud/kubernetes en tirant parti des pods stateless et d'un stockage objet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Serverless ?
Posté par Yth (Mastodon) . Évalué à 6.
L'idée c'est que le « cloud » en lui-même a des serveurs, mais ton appli dessus n'en a pas, il est exécuté magiquement par de la puissance de calcul brute sortie du ciel, et le stockage est global sans espace dédié.
Donc de ton point de vue c'est sans serveur, que de la magie, tu alloues de la puissance d'un côté, du stockage de l'autre, et bingo.
Bien sûr derrière c'est très terre à terre avec des fermes de centaines de milliers de serveurs…
Mais le sens est là.
[^] # Re: Serverless ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
La grosse différence est que tu as des milliers de serveurs qui bossent. Dans l'ancien monde du datacenter, une grosse partie des serveurs ne font rien la plus part du temps. J'avais vu un taux d'usage de VM de AWS de 5% il y a quelques temps.
"La première sécurité est la liberté"
# S3 ?
Posté par Dring . Évalué à 5.
Mais… euh… question sans doute idiote, mais S3, c'est pas essentiellement accessible par des APIs REST? Y'a moyen d'avoir un accès plus bas niveau ?
Parce que sinon, pour gérer le stockage "live" d'une base de données, c'est quand même pas ultra-optimal, non ? Quand le journal de transaction est appliqué, c'est essentiellement des écritures en accès aléatoire.
Ou alors cette solution est essentiellement pour des (toutes) petites bases de données ?
Sur le schéma d'architecture, je n'ai pas trouvé d'information éclairante à ce sujet.
[^] # Re: S3 ?
Posté par wilk . Évalué à 3.
Il y a une couche intermédiaire qui sert de cache. J'imagine que le problème va se poser sur des grosses bases où d'un coup on va vouloir tirer des infos "froides"…
Pour l'instant en beta test on a droit qu'à des toutes petites bases.
[^] # Re: S3 ?
Posté par Dring . Évalué à 3.
Du coup, ça va bien avec les autres services dits "serverless". Parfait pour démarrer et des petits volumes / usage rare, mais à oublier quand on commence à taper sur des gros volumes et/ou une charge constante.
[^] # Re: S3 ?
Posté par wilk . Évalué à 2.
Non, au contraire, c'est comme ça que fonctionne Aurora (AWS). Quelque soit l'architecture utilisée il y a toujours une gestion de cache d'ailleurs.
Plus la charge va être forte plus le cache va jouer à priori. Inversement c'est surtout pour les petites charges qu'il y a du démarrage à froid (Aurora v2 ne scale plus à zéro comme la v1 du coup).
A suivre…
[^] # Re: S3 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Idem pour cosmos db de azure.
"La première sécurité est la liberté"
[^] # Re: S3 ?
Posté par wilk . Évalué à 2.
https://cloud.google.com/blog/products/databases/announcing-the-general-availability-of-alloydb-for-postgresql
Idem chez l'autre.
[^] # Re: S3 ?
Posté par Dring . Évalué à 3.
Ouais, bof…
Si tu fais surtout de l'écriture, pas tant que ça… Si tu fais de la lecture dans une très grosse base de données, avec une bonne distribution des lectures (genre chaque utilisateur tape dans ses propres enregistrements), pas tant que ça.
Maintenant, ça dépend de plein de paramètres - et notamment de quelle infrastructure tu disposes. Si tu est quasi-illimité en mémoire, tu peux. Mais je doute que le modèle (économique) du serverless soit alors le plus pertinent. Parce que le cache en lecture, il faut le remplir avant qu'il puisse être efficace…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.