Le fait de se baser sur les journaux de transaction permet sans dupliquer les données et de manière quasiment instantanée de :
- Créer des branches indépendantes
- Lancer des requêtes à un instant antérieur (en créant une branche de manière transparente)
- Lancer un read-replica
C'est incroyablement pratique en dev et à priori très résilient en prod (à vérifier à l'usage…).
Il y a eu quantité d'article de blog sur leur infra mais celui-là me semble particulièrement pédagogique.
L'infra est codée en Rust et la partie qui concerne spécifiquement le moteur est libre.
What you get when you think of Postgres storage as a transaction journal
et
Créer des branches indépendantes
Lancer des requêtes à un instant antérieur (en créant une branche de manière transparente)
Si j'ai bien compris, c'est un mensonge. Ce n'est pas pg, c'est neon. C'est probablement très bien mais c'est ce que eux ils apportent.
Il me semble qu'il y a 1 an ou 2, doctolib communiquait beaucoup sur le fait qu'ils utilisaient juste postgresql (et donc si eux utilisent du SQL le NoSQL ne sert à rien) et puis ils se sont rendu compte qu'ils n'utilisent pas PostgreSQL, mais Amazon RDS et que la charge géré par Amazon RDS et celle qu'ils arrivent à gérer avec une installation pgsql à eux n'est pas la même. Quand on a l'ambition de pouvoir quitter son cloud provider si besoin, ça fait tâche.
C'est pour ça que ça me parait important de faire la distinction.
Ce qui est intéressant avec cet article c'est justement de montrer que c'est le principe des WAL de PostgreSQL qui permet de faire toutes sortes de choses dès l'instant où on raisonne en terme de journaux et non de stockage fixe. Il y a plusieurs manières ensuite de l'automatiser, Neon en est une mais ça fait longtemps qu'on peut faire du PITR.
Pour la comparaison avec RDS, comme avec Neon il n'y à aucune différence au niveau de l'utilisation, c'est un PostgresSQL tout ce qu'il y a de plus classique, (au pire il manquera des extensions ?), je ne vois pas où tu vois un problème pour quitter le service ?
Neon est open source à part la GUI. C'est surtout le fait que ce soit encore récent qui limite la prod et les éventuelles reprises par d'autres.
Pour la comparaison avec RDS, comme avec Neon il n'y à aucune différence au niveau de l'utilisation, c'est un PostgresSQL tout ce qu'il y a de plus classique, (au pire il manquera des extensions ?), je ne vois pas où tu vois un problème pour quitter le service ?
Ça dépend de ce que tu entends par aucune différence. Eux s'ils réinstallent leur prod ailleurs ça ne marche pas en l'état car il ne savent pas faire une installation aussi performante que RDS et ils ont pris des mesures pour moins s'appuyer sur les capacités de scaling propre à RDS et à découper leur base pour savoir eux-même opérer un pg dont ils ont besoin. Parce que la dépendance à Amazon est un point problématique pour eux.
Tu parles de Aurora plutôt que RDS non ?
Neon a dépassé Aurora du côté des fonctionnalités pour les devs mais je ne pense pas qu'ils s'approchent encore des performances et du reste leur infra est encore uniquement sur AWS. Mais espérons qu'un jour ça permette d'autres alternatives sur d'autres clouds et avec d'autres fournisseurs.
Ah peut être j'avoue ne pas connaître l'offre AWS au point de savoir qu'ils ont 2 pg as a service et de pouvoir décrire leurs différences. Si j'ai bien compris RDS c'est une sorte de base de données sur EC2 et aurora c'est "complètement" managé ça veut dire qu'avec RDS tu provisionne des instances EC2 ?
RDS c'est juste une installation et une maintenance sur des resources fixes que tu choisis, y a pas de scaling automatique. Aurora c'est exactement le même principe que Neon (ou plutôt l'inverse !), le stockage est dissocié du moteur ce qui fait que le moteur peut changer à la volée. J'imagine que niveau perf tout est dans la gestion du cache entre les deux. Mais je ne crois pas que les perfs soient le premier objectif de Neon, c'est plutôt le côté dev, enfin du moins dans un premier temps.
Ce qui est intéressant avec cet article c'est justement de montrer que c'est le principe des WAL de PostgreSQL qui permet de faire toutes sortes de choses dès l'instant où on raisonne en terme de journaux et non de stockage fixe. Il y a plusieurs manières ensuite de l'automatiser, Neon en est une mais ça fait longtemps qu'on peut faire du PITR.
J'ai du mal à comprendre. Le lien décris une forme pas très propre d'event sourcing1. Mais il décrit le très bas niveau puis le très haut niveau sans parler de ce qu'il y a entre. Comment tu accède au WAL en pratique ?
C'est là qu'est la force de kafka, il est décrit comme un log distribué pour cette raison. Il est tellement centré sur le log qu'il ne fait que ça et à toi d'avoir le comportement que tu souhaite derrière :
réagir aux évènements
créer des vues de tes données qui sont mises à jour au fil des évènements
Je dis pas très propre parce que l'élément atomique semble être le changement. Le WAL décrit des opérations bas niveau interne à pg (dans les faits je ne sais même pas à quel point c'est considéré comme une API). L'event sourcing propose de stocker des évènements métier, l'opération atomique sera « Création de l'utilisateur 'John Doe' avec l'email 'john@example.com' » (l'idée étant de travailler la notion d'agrégat pour que ce soit un évènement aussi petit que possible tout en étant cohérent). ↩
Ce qui se rapprocherait plus de l'event sourcing au niveau Pg ce serait plutôt la réplication logique.
La on est sur du très bas niveau et il n'était pas prévu au départ d'en faire autre chose que du stockage sur FS, d'où le boulot qui est fait en ce moment pour en faire autre chose côté cloud.
En pratique le WAL c'est juste une série de fichiers sur disque. Quand on veut faire de la réplication il suffit de les copier sur un autre disque au fur et à mesure. Si on veut revenir dans le temps il suffit de partir d'un snapshot et d'appliquer uniquement les fichiers jusqu'à une certaine date (c'est lent parce qu'il faut repartir d'un snapshot).
L'astuce de Neon c'est que le stockage lui-même est effectué sous forme incrémentale ce qui fait qu'on a des snapshots prêts instantanément et on gagne en fiabilité (les données sont immuables). Comme ZFS, c'est de là qu'est venue l'idée.
Neon s'interface entre les WAL et le stockage (je pense que c'est une partie qui va remonter dans le core).
Ensuite toute la difficulté va être de jouer sur le cache avec une partie des données périmées d'un côté et les données en cours de l'autre…
Wow j'ai vraiment galéré à te suivre (ça fait 3 fois que je réécris mon commentaire). Ce qui est incrémental c'est pas véritablement lié au WAL de pg, c'est que les PITR sont construit incrémentalement les uns par rapport aux autres et c'est fait grâce à du CoW sur les pages qui sont donc immuables (à la base je croyais que tu disais que le WAL était immuable). Et ce qui est rapide c'est l'accès à n'importe quel point du temps (pareil je croyais que tu disais que c'était la réplication qui était instantané).
Mais du coup comme je le disais c'est complètement Neon (et peut être d'autres) qui fournissent ce service de branche et pas pg (même si oui ça s'appuie sur pg). Ce n'est pas un mal que ce soit Neon. C'est juste le côté "vous pouvez-faire ça avec PG" qui me semble être plus "vous pouvez faire ça avec Neo ou si vous réécrivez la partie stockage de PG".
Le lien par contre parle de remplacer les sauvegardes par du PITR et je dirais que non. Des sauvegardes doivent être hors ligne. Peut être qu'on peut se contenter de sauvegarder les bucket S3, mais du coup c'est une sauvegarde.
Pour le sujet de docto et d'Aurora, la performance dont ils ont besoin c'est, je pense de pouvoir manipuler beaucoup de données pas tant le temps de réponse par requête (dis autrement ils veulent pouvoir faire 1 millions de requête dans la seconde pas forcément que les requêtes prennent 1µs) et ça me parait cohérent avec ce que je vois (en imaginant que qu'à fait Amazon en comparaison de Neon).
En tout cas merci c'est intéressant de comprendre comment ils font.
J'aime beaucoup ces articles pour techos: "on a fait comme ci et comme ça" ; à la différence des articles pour daicideurs: "on va faire de vous les maîtres de l'univers". Mais j'imagine qu'il en faut pour tous.
Il y a beaucoup d'initiatives pour transformer les DB classiques et bien rodées - open source de préférence, comme PG, MySQL et SQLite - en DB "cloud ready" : planetscale, neon, oackroach, turso, timescale, YugabyteDB (de tête).
On démonte toutes les pièces, on garde ce qui peut servir, on replug le tout sur un stockage objet … et on va chercher des investisseurs :)
# Résumé
Posté par wilk . Évalué à 5.
Le fait de se baser sur les journaux de transaction permet sans dupliquer les données et de manière quasiment instantanée de :
- Créer des branches indépendantes
- Lancer des requêtes à un instant antérieur (en créant une branche de manière transparente)
- Lancer un read-replica
C'est incroyablement pratique en dev et à priori très résilient en prod (à vérifier à l'usage…).
Il y a eu quantité d'article de blog sur leur infra mais celui-là me semble particulièrement pédagogique.
L'infra est codée en Rust et la partie qui concerne spécifiquement le moteur est libre.
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 4.
et
Si j'ai bien compris, c'est un mensonge. Ce n'est pas pg, c'est neon. C'est probablement très bien mais c'est ce que eux ils apportent.
Il me semble qu'il y a 1 an ou 2, doctolib communiquait beaucoup sur le fait qu'ils utilisaient juste postgresql (et donc si eux utilisent du SQL le NoSQL ne sert à rien) et puis ils se sont rendu compte qu'ils n'utilisent pas PostgreSQL, mais Amazon RDS et que la charge géré par Amazon RDS et celle qu'ils arrivent à gérer avec une installation pgsql à eux n'est pas la même. Quand on a l'ambition de pouvoir quitter son cloud provider si besoin, ça fait tâche.
C'est pour ça que ça me parait important de faire la distinction.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par wilk . Évalué à 3.
Ce qui est intéressant avec cet article c'est justement de montrer que c'est le principe des WAL de PostgreSQL qui permet de faire toutes sortes de choses dès l'instant où on raisonne en terme de journaux et non de stockage fixe. Il y a plusieurs manières ensuite de l'automatiser, Neon en est une mais ça fait longtemps qu'on peut faire du PITR.
Pour la comparaison avec RDS, comme avec Neon il n'y à aucune différence au niveau de l'utilisation, c'est un PostgresSQL tout ce qu'il y a de plus classique, (au pire il manquera des extensions ?), je ne vois pas où tu vois un problème pour quitter le service ?
Neon est open source à part la GUI. C'est surtout le fait que ce soit encore récent qui limite la prod et les éventuelles reprises par d'autres.
https://github.com/neondatabase
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2.
Ça dépend de ce que tu entends par aucune différence. Eux s'ils réinstallent leur prod ailleurs ça ne marche pas en l'état car il ne savent pas faire une installation aussi performante que RDS et ils ont pris des mesures pour moins s'appuyer sur les capacités de scaling propre à RDS et à découper leur base pour savoir eux-même opérer un pg dont ils ont besoin. Parce que la dépendance à Amazon est un point problématique pour eux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par wilk . Évalué à 3.
Tu parles de Aurora plutôt que RDS non ?
Neon a dépassé Aurora du côté des fonctionnalités pour les devs mais je ne pense pas qu'ils s'approchent encore des performances et du reste leur infra est encore uniquement sur AWS. Mais espérons qu'un jour ça permette d'autres alternatives sur d'autres clouds et avec d'autres fournisseurs.
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2.
Ah peut être j'avoue ne pas connaître l'offre AWS au point de savoir qu'ils ont 2 pg as a service et de pouvoir décrire leurs différences. Si j'ai bien compris RDS c'est une sorte de base de données sur EC2 et aurora c'est "complètement" managé ça veut dire qu'avec RDS tu provisionne des instances EC2 ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par wilk . Évalué à 3.
RDS c'est juste une installation et une maintenance sur des resources fixes que tu choisis, y a pas de scaling automatique. Aurora c'est exactement le même principe que Neon (ou plutôt l'inverse !), le stockage est dissocié du moteur ce qui fait que le moteur peut changer à la volée. J'imagine que niveau perf tout est dans la gestion du cache entre les deux. Mais je ne crois pas que les perfs soient le premier objectif de Neon, c'est plutôt le côté dev, enfin du moins dans un premier temps.
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2.
J'ai du mal à comprendre. Le lien décris une forme pas très propre d'event sourcing1. Mais il décrit le très bas niveau puis le très haut niveau sans parler de ce qu'il y a entre. Comment tu accède au WAL en pratique ?
C'est là qu'est la force de kafka, il est décrit comme un log distribué pour cette raison. Il est tellement centré sur le log qu'il ne fait que ça et à toi d'avoir le comportement que tu souhaite derrière :
Je dis pas très propre parce que l'élément atomique semble être le changement. Le WAL décrit des opérations bas niveau interne à pg (dans les faits je ne sais même pas à quel point c'est considéré comme une API). L'event sourcing propose de stocker des évènements métier, l'opération atomique sera « Création de l'utilisateur 'John Doe' avec l'email 'john@example.com' » (l'idée étant de travailler la notion d'agrégat pour que ce soit un évènement aussi petit que possible tout en étant cohérent). ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par wilk . Évalué à 2.
Ce qui se rapprocherait plus de l'event sourcing au niveau Pg ce serait plutôt la réplication logique.
La on est sur du très bas niveau et il n'était pas prévu au départ d'en faire autre chose que du stockage sur FS, d'où le boulot qui est fait en ce moment pour en faire autre chose côté cloud.
En pratique le WAL c'est juste une série de fichiers sur disque. Quand on veut faire de la réplication il suffit de les copier sur un autre disque au fur et à mesure. Si on veut revenir dans le temps il suffit de partir d'un snapshot et d'appliquer uniquement les fichiers jusqu'à une certaine date (c'est lent parce qu'il faut repartir d'un snapshot).
L'astuce de Neon c'est que le stockage lui-même est effectué sous forme incrémentale ce qui fait qu'on a des snapshots prêts instantanément et on gagne en fiabilité (les données sont immuables). Comme ZFS, c'est de là qu'est venue l'idée.
Neon s'interface entre les WAL et le stockage (je pense que c'est une partie qui va remonter dans le core).
Ensuite toute la difficulté va être de jouer sur le cache avec une partie des données périmées d'un côté et les données en cours de l'autre…
https://neon.tech/blog/architecture-decisions-in-neon
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2.
Wow j'ai vraiment galéré à te suivre (ça fait 3 fois que je réécris mon commentaire). Ce qui est incrémental c'est pas véritablement lié au WAL de pg, c'est que les PITR sont construit incrémentalement les uns par rapport aux autres et c'est fait grâce à du CoW sur les pages qui sont donc immuables (à la base je croyais que tu disais que le WAL était immuable). Et ce qui est rapide c'est l'accès à n'importe quel point du temps (pareil je croyais que tu disais que c'était la réplication qui était instantané).
Mais du coup comme je le disais c'est complètement Neon (et peut être d'autres) qui fournissent ce service de branche et pas pg (même si oui ça s'appuie sur pg). Ce n'est pas un mal que ce soit Neon. C'est juste le côté "vous pouvez-faire ça avec PG" qui me semble être plus "vous pouvez faire ça avec Neo ou si vous réécrivez la partie stockage de PG".
Le lien par contre parle de remplacer les sauvegardes par du PITR et je dirais que non. Des sauvegardes doivent être hors ligne. Peut être qu'on peut se contenter de sauvegarder les bucket S3, mais du coup c'est une sauvegarde.
Pour le sujet de docto et d'Aurora, la performance dont ils ont besoin c'est, je pense de pouvoir manipuler beaucoup de données pas tant le temps de réponse par requête (dis autrement ils veulent pouvoir faire 1 millions de requête dans la seconde pas forcément que les requêtes prennent 1µs) et ça me parait cohérent avec ce que je vois (en imaginant que qu'à fait Amazon en comparaison de Neon).
En tout cas merci c'est intéressant de comprendre comment ils font.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# ça fourmille
Posté par steph1978 . Évalué à 2.
J'aime beaucoup ces articles pour techos: "on a fait comme ci et comme ça" ; à la différence des articles pour daicideurs: "on va faire de vous les maîtres de l'univers". Mais j'imagine qu'il en faut pour tous.
Il y a beaucoup d'initiatives pour transformer les DB classiques et bien rodées - open source de préférence, comme PG, MySQL et SQLite - en DB "cloud ready" : planetscale, neon, oackroach, turso, timescale, YugabyteDB (de tête).
On démonte toutes les pièces, on garde ce qui peut servir, on replug le tout sur un stockage objet … et on va chercher des investisseurs :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.