• # Neon c'est bon.

    Posté par  . É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  . Évalué à 2.

      Neon is a serverless PostgreSQL service that separates storage and compute.

      🤔

      • [^] # Re: Neon c'est bon.

        Posté par  . É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  . É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  . Évalué à 2.

            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 ».

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Neon c'est bon.

              Posté par  . É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  . Évalué à 3.

                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.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Neon c'est bon.

                  Posté par  . Évalué à 3.

                  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.

      • [^] # Re: Neon c'est bon.

        Posté par  . É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  . É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  . É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  . É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.