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...
[^] # Re: Résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Postgresql en tant que journal de transactions. É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