Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
C'est une architecture qui a le vent en poupe actuellement principalement pour optimiser son déploiement dans les clouds providers mais pas que.
Pour le déploiement dans les clouds ça permet d'utiliser un stockage objet pour la donnée et des fonctions (faas) pour le calcul (à minima le query planner mais ça peut être plus). En terme de prix ça fait une grande différence quand tu es chez un cloud provider.
Tu simplifie aussi le déploiement. Au lieu de te demander sur combien de machines de quelle taille et avec quelles forme de réplication tu as besoin, tu va tirer parti des garanties que te fourni chacun des 2 services et tu n'a plus qu'à te soucier des répartitions géographiques (et c'est une simple configuration).
Pour des requêtes complexes comme de l'OLAP ou autre. Le fait de tout exécuter au même endroit peu créer des contentions qui peuvent disparaître quand tu utilise le modèle d'exécution des fonctions.
Par contre si tu connais bien ta base et que ta charge est prédictive ça ne vaut pas forcément le coup. Les faas sont intéressantes quand tu sais que tu as de grands moments inutilisés ou que tu as besoin de parallélisme poussés (avec beaucoup de threads, mais complètements indépendants).
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
Je comprends bien mais le commentaire au quel je répondais n'y faisait pas référence.
La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Tout à fait, mais ce n'est pas la seule façon de le faire. CouchDB par exemple (qui n'est pas un SQL, mais ça ne change pas grand chose) se déploie avec différents types de nœuds pour gérer la partie calcul de la partie stockage. C'est bien plus simple à mettre en œuvre quand tu n'a pas de stockage objet et de fonctions (ce qui tu demande un kubernetes généralement, etc).
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
La dernière fois que j'avais regardé chez AWS, dès qu'on parlait de ressources garanties ça devenait toute de suite très chère. Pas au point de le rendre exorbitant mais juste pour rappeler qu'il faut parfois faire attention entre « je peux utiliser pleins de fonctions dans la journée » et « je veux avoir 150k fonctions disponibles à 20h00 ».
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Oui je me doutais que c'est des snapshots montés.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Ça va dépendre des usages et des contraintes (parce qu'accéder aux données de prod peut ne pas être légales), une autre solution que j'avais vu consistait à avoir une instance locale l'ajouter à la réplication et une fois la réplication terminé la sortir du cluster. Je ne sais pas si c'est facile à faire avec PG (mais oui ça demande tout de même de dumper toute la base).
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans.
J'en doute pas. Mon commentaire était plus pour rappeler qu'il faut bien faire attention et qu'il peut y avoir des détails qui font que ça n'est pas aussi rentable. D'ailleurs ça ne remet pas forcément tout en cause des fois il suffit de pas grand chose pour faire de grosses économies sur sa facture.
Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
Ouai faut lire avec attention les garanties fournies par le service.
Je me demande tout de même à quel point ça a dû être complexe d'implémenter les garanties ACID en stateless.
Je me demande tout de même à quel point ça a dû être complexe d'implémenter les garanties ACID en stateless.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
Si ce qui te gêne c'est le mot serverless, c'est un nom commercial pour parler des fonctions as service et il entends par là que tu ne gère pas de server.
Mon précédent commentaire a dû prêter à confusion car les réponses expliquent ce qu'est le serverless, et je connais.
Je m'étonnais simplement du commentaire de @wilk qui dit parle d'une fonctionnalité de gestion de branche ala git pour Neon alors que la fiche que j'ai trouvé ne dit pas du tout cela.
Je m'attendais plus à des réponses qui pointe la doc du produit décrit par @wilk.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
# Neon c'est bon.
Posté par wilk . Évalué à 2.
Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
[^] # Re: Neon c'est bon.
Posté par steph1978 . Évalué à 2.
🤔
[^] # Re: Neon c'est bon.
Posté par barmic 🦦 . Évalué à 3.
C'est une architecture qui a le vent en poupe actuellement principalement pour optimiser son déploiement dans les clouds providers mais pas que.
Pour le déploiement dans les clouds ça permet d'utiliser un stockage objet pour la donnée et des fonctions (faas) pour le calcul (à minima le query planner mais ça peut être plus). En terme de prix ça fait une grande différence quand tu es chez un cloud provider.
Tu simplifie aussi le déploiement. Au lieu de te demander sur combien de machines de quelle taille et avec quelles forme de réplication tu as besoin, tu va tirer parti des garanties que te fourni chacun des 2 services et tu n'a plus qu'à te soucier des répartitions géographiques (et c'est une simple configuration).
Pour des requêtes complexes comme de l'OLAP ou autre. Le fait de tout exécuter au même endroit peu créer des contentions qui peuvent disparaître quand tu utilise le modèle d'exécution des fonctions.
Par contre si tu connais bien ta base et que ta charge est prédictive ça ne vaut pas forcément le coup. Les faas sont intéressantes quand tu sais que tu as de grands moments inutilisés ou que tu as besoin de parallélisme poussés (avec beaucoup de threads, mais complètements indépendants).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Neon c'est bon.
Posté par wilk . Évalué à 3.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
[^] # Re: Neon c'est bon.
Posté par barmic 🦦 . Évalué à 2.
Je comprends bien mais le commentaire au quel je répondais n'y faisait pas référence.
Tout à fait, mais ce n'est pas la seule façon de le faire. CouchDB par exemple (qui n'est pas un SQL, mais ça ne change pas grand chose) se déploie avec différents types de nœuds pour gérer la partie calcul de la partie stockage. C'est bien plus simple à mettre en œuvre quand tu n'a pas de stockage objet et de fonctions (ce qui tu demande un kubernetes généralement, etc).
La dernière fois que j'avais regardé chez AWS, dès qu'on parlait de ressources garanties ça devenait toute de suite très chère. Pas au point de le rendre exorbitant mais juste pour rappeler qu'il faut parfois faire attention entre « je peux utiliser pleins de fonctions dans la journée » et « je veux avoir 150k fonctions disponibles à 20h00 ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Neon c'est bon.
Posté par wilk . Évalué à 3.
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
[^] # Re: Neon c'est bon.
Posté par barmic 🦦 . Évalué à 3.
Oui je me doutais que c'est des snapshots montés.
Ça va dépendre des usages et des contraintes (parce qu'accéder aux données de prod peut ne pas être légales), une autre solution que j'avais vu consistait à avoir une instance locale l'ajouter à la réplication et une fois la réplication terminé la sortir du cluster. Je ne sais pas si c'est facile à faire avec PG (mais oui ça demande tout de même de dumper toute la base).
J'en doute pas. Mon commentaire était plus pour rappeler qu'il faut bien faire attention et qu'il peut y avoir des détails qui font que ça n'est pas aussi rentable. D'ailleurs ça ne remet pas forcément tout en cause des fois il suffit de pas grand chose pour faire de grosses économies sur sa facture.
Ouai faut lire avec attention les garanties fournies par le service.
Je me demande tout de même à quel point ça a dû être complexe d'implémenter les garanties ACID en stateless.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Neon c'est bon.
Posté par wilk . Évalué à 3.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
[^] # Re: Neon c'est bon.
Posté par barmic 🦦 . Évalué à 4.
Il y a beaucoup de marketing, mais cockraoch en parle ici :
https://www.cockroachlabs.com/blog/what-is-serverless-sql/
Si ce qui te gêne c'est le mot serverless, c'est un nom commercial pour parler des fonctions as service et il entends par là que tu ne gère pas de server.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Neon c'est bon.
Posté par steph1978 . Évalué à 3.
Mon précédent commentaire a dû prêter à confusion car les réponses expliquent ce qu'est le serverless, et je connais.
Je m'étonnais simplement du commentaire de @wilk qui dit parle d'une fonctionnalité de gestion de branche ala git pour Neon alors que la fiche que j'ai trouvé ne dit pas du tout cela.
Je m'attendais plus à des réponses qui pointe la doc du produit décrit par @wilk.
[^] # Re: Neon c'est bon.
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 06 septembre 2023 à 10:55.
Pardon Branching - Neon Docs
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Neon c'est bon.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Merci beaucoup.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Neon c'est bon.
Posté par steph1978 . Évalué à 2.
Non non, my bad. Mon commentaire manquait de clarté.
[^] # Re: Neon c'est bon.
Posté par wilk . Évalué à 2.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.