Journal Tour d'horizon de l'état des bases NoSQL

• # PostgreSQL partout

  Posté par wilk le 22 décembre 2023 à 18:15. Évalué à 10.

  

  J'ai également été utilisateur de ZODB, j'ai encore une petite app dessus, c'était assez extraordinaire ! Mais ça fait bien longtemps que je ne me pose plus la question, c'est PostgreSQL partout.

  Depuis quelques années PostgreSQL est tout à fait capable d'effectuer toutes sortes d'opérations et d'indexages sur du JSON (j'en apprend tous les jours). Il y a également tout un tas d'options pour passer à l'échelle, pour l'installer sur un simple poste de dev, pour scaler à zéro, faire des branches (Neon) etc. Il existe même des bases NoSQL sur PostgreSQL (FerretDB).
  Est-ce que tu peux nous préciser en quoi PostgreSQL serait "rigide" ?
  Avec toutes les solutions NoSQL tellement nombreuses, est-ce que le risque n'est pas d'avoir à changer à nouveau par la suite ?

  • [^] # Re: PostgreSQL partout

    Posté par srb (site web personnel) le 22 décembre 2023 à 21:10. Évalué à 2.

    

    Est-ce que tu peux nous préciser en quoi PostgreSQL serait "rigide" ?

    En utilisant des bases SQL, on se retrouve à faire des scripts de migration à chaque fois qu'on veut changer la structure de données. On en fait régulièrement, au fur et à mesure de la compréhension du métier.
    Je connaissais l'existence du type JSON dans PostgreSQL mais je ne voyais pas trop l'intérêt si c'est pour tout sérialiser dans du JSON pour retrouver la souplesse et en sacrifiant l'intérêt d'une base relationnelle. Apparemment, c'est plus puissant que je ne pensais, je note ça comme élément à évaluer.

    On utilise déjà PostgreSQL sur certains services que l'on maintient. On en est content tant que le service bouge peu (ou que c'est une exigence client).

    Avec toutes les solutions NoSQL tellement nombreuses, est-ce que le risque n'est pas d'avoir à changer à nouveau par la suite ?

    Oui c'est un risque. Faire le tour des solutions présentes est une tentative de minimiser le risque d'erreur plutôt que juste prendre la première qui passe, la plus populaire, etc.

    • [^] # Re: PostgreSQL partout

      Posté par wilk le 23 décembre 2023 à 11:14. Évalué à 9.

      

      J'ai toujours trouvé au contraire beaucoup plus délicates les mises à jour de schema sur du NoSQL, encore plus sur ZODB (c'est ce qui m'en a écarté), que sur du SQL où c'est vraiment simple, fiable et standard.

      • [^] # Re: PostgreSQL partout

        Posté par srb (site web personnel) le 26 décembre 2023 à 13:04. Évalué à 3.

        

        On utilise une surcouche maison (sheraf) sur ZODB qui fait un peu l'équivalent d'un ORM. Ajouter un attribut sur un objet se fait sans migration, en supprimer un pareil (mais dans ce cas les données restent en base jusqu'à la prochaine écriture de l'objet). Renommer un attribut peut aussi se faire sans migration en ajoutant un paramètre (mais une migration pour renommer l'attribut est évidemment possible). Évidemment, des migrations restent nécessaires si on veut découper un objet en deux, etc. Dans ce cas, il faut écrire un script Python, ce qui permet d'avoir accès à l'ensemble des attributs, méthodes sur les objets à transformer.

        Je suis tout à fait d'accord sur la qualité des migrations SQL. Par contre, on a l'impression de perdre du temps à les faire. Notre pire cas d'usage est avec Django: certaines migrations sont inutiles car elles touchent des paramètres inutilisés en base, les migrations ne permettent pas l'utilisation des méthodes attachées aux objets. C'est plus lié à Django lui-même qu'à PostgreSQL, mais c'est une mauvaise expérience. On a aussi des cas avec Flask/SQLAlchemy qui sont plus agréables, sans soulever l'enthousiasme.

        Peut-être que la conclusion sera que PostgreSQL reste le meilleur choix. Pour l'instant, on explore les pistes.

        • [^] # Re: PostgreSQL partout

          Posté par LeBouquetin (site web personnel, Mastodon) le 27 décembre 2023 à 09:21. Évalué à 4.

          

          Les migrations auto générées peuvent être problématiques en terme de performance.

          Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.

          À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.

          Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.

          J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.

          Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.

          À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).

          Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.

          Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

          • [^] # Re: PostgreSQL partout

            Posté par Cyprien (site web personnel) le 28 décembre 2023 à 21:21. Évalué à 3.

            

            Le principe de se définir en "non quelque chose" n'a pas de sens pour moi

            Je crois que NoSQL ne veut pas dire Non SQL, mais Not Only SQL

            • [^] # Re: PostgreSQL partout

              Posté par tisaac (Mastodon) le 28 décembre 2023 à 21:31. Évalué à 3.

              

              Si l'on croit ce site, c'est une réinterprétation de l'acronyme initial:

              So the misleading term "nosql" (the community now translates it mostly with "not only sql") should be seen as an alias to something like the definition above.

              Surtout, ne pas tout prendre au sérieux !

              • [^] # Re: PostgreSQL partout

                Posté par LeBouquetin (site web personnel, Mastodon) le 28 décembre 2023 à 21:50. Évalué à 4. Dernière modification le 28 décembre 2023 à 21:50.

                

                Dans tous les cas c'est une manière de se définir par la négation d'autre chose au lieu de dire ce que c'est vraiment. Et du coup c'est un fourre-tout.

                #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • [^] # Re: PostgreSQL partout

    Posté par BohwaZ (site web personnel, Mastodon) le 31 décembre 2023 à 01:31. Évalué à 4.

    

    SQLite propose aussi du NoSQL avec le stockage sous forme de JSON, et même sous forme de JSON binaire pour de meilleures performances : https://sqlite.org/draft/jsonb.html

    (à venir dans la version 3.45.0 pour le JSON binaire)

    Ça marche très bien, on peut faire des index sur des chemins JSON etc.

    C'est bien plus simple à mettre en œuvre que les autres NoSQL pour des petits projets :

    CREATE TABLE data (data TEXT);
    
    INSERT INTO data VALUES (
      json_object('titre', 'Super document', 'date', datetime())
    );
    
    CREATE INDEX data_title ON data (json_extract(data, '$.titre')) COLLATE NOCASE;
    
    SELECT json_extract(data '$.titre') AS title FROM data ORDER BY title;
    

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

• # elasticsearch ?

  Posté par nouknouk (site web personnel) le 22 décembre 2023 à 18:18. Évalué à 4. Dernière modification le 22 décembre 2023 à 18:21.

  

  Ne manque-t-il pas dans cette liste:
  - elasticsearch
  - opensearch
  - apache Lucene ?

  PS: On commence notre 'kafka journey' dans notre boulot (on en est encore au stade préliminaire de la decouverte). On se fait accompagner par une entreprise tierce, spécialisée dans le domaine. Un des enseignements est que l'utilisation de Kafka comme "pseudo-bdd" est très rarement une bonne idée.

  • [^] # Re: elasticsearch ?

    Posté par groumly le 24 décembre 2023 à 01:26. Évalué à 4.

    

    Ce sont des index, pas des bases de données. C’est fait pour trouver rapidement une aiguille dans une botte de foin, c’est pas vraiment fait pour le stockage long terme de données.

    l'utilisation de Kafka comme "pseudo-bdd" est très rarement une bonne idée.

    Dur de leur en vouloir cela dit, c’est une plateforme d’event streaming 😃

    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: elasticsearch ?

      Posté par Jean Roc Morreale le 02 janvier 2024 à 09:21. Évalué à 3.

      

      Pourtant je peux constater, depuis plus d'une décennie, que l'usage d'elastic search comme base de données est un réflexe courant chez les prestataires disposant de devs applicatifs et pas de dba, l'éditeur lui-même entretient cet usage en expliquant qu'il "centralise le stockage de vos données". C'est la même motivation qu'avec d'autres technos, celle de ne pas avoir à poser des schémas relationnels qui sont perçus comme une rigidité handicapant l'agilité.

      • [^] # Re: elasticsearch ?

        Posté par BAud (site web personnel) le 02 janvier 2024 à 10:26. Évalué à 5.

        

        ne pas avoir à poser des schémas relationnels qui sont perçus comme une rigidité handicapant l'agilité.

        faut vraiment ne pas tenir à ses données et privilégier le « jetable » :/

        à mettre dans le même panier que ceux qui prétendent qu'il n'y a pas de spécifications, suffit de reprendre les user stories /o\

      • [^] # Re: elasticsearch ?

        Posté par barmic 🦦 le 02 janvier 2024 à 13:24. Évalué à 2.

        

        agilité

        Au sens flexible. L'agilité au sens scrum/kanban/safe n'ont rien à voir là dedans. C'est un peu comme mélanger free speech et free beer.

        D'ailleurs ils posent tout de même des mappings ou ils espèrent qu'ES va savoir de lui même la manière optimale d'indexer ?

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

    • [^] # Re: elasticsearch ?

      Posté par barmic 🦦 le 02 janvier 2024 à 13:19. Évalué à 2.

      

      C'était le cas à l'origine et depuis un certain temps Elastic assume que c'est une base de données.

      D'ailleurs ce n'est pas une critique qui est faite à redis qui dit clairement qu'il peut être utilisé comme base de données.

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

• # je pense aussi à ..

  Posté par totof2000 le 22 décembre 2023 à 18:43. Évalué à 5.

  

  influxdb ou etcd

  Tout dépend du besoin.

  • [^] # Re: je pense aussi à ..

    Posté par totof2000 le 22 décembre 2023 à 18:49. Évalué à 4.

    

    Et j'allais oublier couchbase.

• # t'es si Minio Minio Minio mais gros

  Posté par devnewton 🍺 (site web personnel) le 22 décembre 2023 à 19:23. Évalué à 5.

  

  Puisqu'il y a des bases clefs/valeurs, est-ce que tu as pensé à utiliser un stockage objet?

  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

• # Tout se paye un jour ou l'autre

  Posté par Dring le 22 décembre 2023 à 20:37. Évalué à 10.

  

  en éliminant la rigidité des bases de données relationnelles, permettant de livrer plus rapidement en s'économisant des contraintes liées aux bases relationnelles

  Les bases relationnelles et leurs "contraintes", leur "rigidité", ont fait suite au stockage fichier simple (type VSAM), pour répondre à une problématique récurrente : on se retrouvait systématiquement dans des situations d'incohérence, parce que le code au-dessus des données ne gérait pas bien l'intégrité.

  Donc, pouf, on crée les bases relationnelles et le SQL.

  Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".

  Alors, c'est venu de vrais besoins dans des situations bien particulières. Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées. Mais au lieu que cette structure soit garantie par le moteur de stockage, tout s'est retrouvé déporté dans le code applicatif, qui évidemment ne fait pas le taf, laisse passer plein de merdes, et on se retrouve avec des données vérolées jusqu'à l'os.

  "Ouiiiii, mais c'est pour faire du prototypage". Mais bien sûr. Et le prototype, y'a toujours un gars qui va dire qu'il fait le taf, donc faut le pousser jusqu'à la prod. Pourquoi réécrire quelque chose qui marche après tout ? Et hop, une appli moisie en production. Le stagiaire est content, mais le mainteneur qui reprend l'appli 4 ans plus tard pleure toutes les larmes de son corps.

  Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.

  Et comme dit plus haut, les serveurs SQL ont bien évolué. Ils permettent de gérer le meilleur des 2 mondes, ont une connectivité largement supérieure (merci odbc/jdbc/…), ne sont jamais limités à "JSON only".

  • [^] # Re: Tout se paye un jour ou l'autre

    Posté par barmic 🦦 le 22 décembre 2023 à 22:47. Évalué à 10.

    

    T'es pas le seul à qui je pourrais le dire mais tu as le commentaire qui le décris le plus

    Mais comme tout effet de mode

    Faut arrêter de disqualifier des trucs en parlant d'effet de mode. Ça n'en est pas un. C'est souvent utilisé pour parler d'un truc très différent : l'effet de cycle.

    C'est normal, logique et sain d'avoir cet effet de cycle.

    Le monde des bases de données a essayé énormément de choses, le stockage objet, le SQL, les No-SQL, les New-SQL,… C'est formidable. Cet effervescence c'est le terreaux qui permet d'aboutir à des solutions géniales.

    Même si on considère Postgre comme la base de données ultime, beaucoup de ce qu'elle fait et qui est listé dans le premier commentaire de wilk est arrivé par infusion de ce que des bases de données ont proposées et elles contreviennent pour une part aux concepts derrière SQL (traiter du json contrevient mécaniquement à la première forme normale).

    Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".

    Si on veut regrouper toutes les No-SQL c'est plutôt les contraintes d'intégrités qu'ils ont cherchés à éviter car c'est les contraintes d'intégrité qui rendent complexe la structure d'un cluster. Parler des travaux de recherche de Brewer comme de "petit malin" me parait assez irrespectueux. Beaucoup de base de données No-SQL ont un schema et bigtable, l'une des premières base de données No-SQL, est structurée. Ça n'est pas un ajout tardif.

    Du coup :

    Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées.

    Alors hadoop c'est beaucoup de choses, il y a plusieurs choses qui font du stockage (le système de fichier distribué et la gestion de configuration), mais la seule brique qui est présentée comme une base de donnée c'est hbase. Du coup sur les 3 que tu cite, il y en a 2 qui ont un schemas non débrayable… Ah et ils ne traitent pas de json (hbase j'ai pas suivi et cassandra c'est comme pour postresql). J'ai sincèrement du mal à croire ce que tu dis par contre parce que hbase et cassandra sont des bases de données très spécifiques qui vont très vite te faire comprendre qu'elles ne font pas ce que tu recherche (le requêtage dans cassandra c'est vraiment une version anémique de la première version d'SQL).

    Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.

    Quelqu'un qui choisi sa base de données pour de mauvaises raisons oui il faut y faire gaffe (refuser les No-SQL en croyant que No-SQL c'est équivalent à mongo, penser que sans SQL on ne gère pas de schéma,…). J'ai vu des trucs en souffrances pour les 2 choix.

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

    • [^] # Re: Tout se paye un jour ou l'autre

      Posté par Marotte ⛧ le 22 décembre 2023 à 23:52. Évalué à 6.

      

      Les bases SQL permettent structure complexe et contraintes, mais ça n’est pas une obligation. Je pensais, peut-être bếtement, qu’on en était venu aux base NoSQL par souci d’optimisation. Des besoins d’optimisation qu’un moteur SQL ne pouvait pas se permettre de faire sans nuire à a capacité à faire du SQL (du fortement structuré et contraint).

      Au risque de dire une connerie, fonctionnellement, qu’est-ce qui empêche de faire du NoSQL, du clé-valeur par exemple, avec Postgres ou autre base de ce type ?

      • [^] # Re: Tout se paye un jour ou l'autre

        Posté par barmic 🦦 le 23 décembre 2023 à 00:51. Évalué à 4.

        

        Au risque de dire une connerie, fonctionnellement, qu’est-ce qui empêche de faire du NoSQL, du clé-valeur par exemple, avec Postgres ou autre base de ce type ?

        Du clé valeur ou de l'orienté document pas grand chose, mais pour du graphe c'est plus compliqué. Pour des données temporelles tu peux faire une bonne partie mais tu n'auras pas les requêtes continues à ce que je sache.

        Les bases SQL permettent structure complexe et contraintes, mais ça n’est pas une obligation. Je pensais, peut-être bếtement, qu’on en était venu aux base NoSQL par souci d’optimisation. Des besoins d’optimisation qu’un moteur SQL ne pouvait pas se permettre de faire sans nuire à a capacité à faire du SQL (du fortement structuré et contraint).

        Il me semble qu'on dit la même chose. Les propriétés ACID rendent difficiles la scalabilité horizontale du cluster. Maintenant les moteurs SQL savent pour certains ne plus faire de SQL et sont même implémenté au dessus d'une base nosql.

        La guerre sql ou nosql n'a pas trop de sens. Les bases de données se font découper maintenant, tu as le stockage qui se fait en nosql clé valeur (voir sur du stockage objet) et/ou en colonne, tu as un moteur sql qui peu être exécuté sur du faas et par dessus tu as des implémentation de protocoles sql ou non. Toutes les bases se rapprochent tranquillement de tout ou partie de se modèle là.

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

        • [^] # Re: Tout se paye un jour ou l'autre

          Posté par Marotte ⛧ le 24 décembre 2023 à 01:34. Évalué à 6. Dernière modification le 24 décembre 2023 à 01:35.

          

          Les bases de données se font découper maintenant, tu as le stockage qui se fait en nosql clé valeur (voir sur du stockage objet) et/ou en colonne, tu as un moteur sql qui peu être exécuté sur du faas et par dessus tu as des implémentation de protocoles sql ou non.

          Pour moi le SQL (et donc le NoSQL) ça ne dit absolument rien du stockage sous-jacent. Du coup la différence entre SQL et NoSQL aujourd’hui ce serait, comme tu le dis je crois, d’un côté de solutions qui t’imposent l’utilisation de SQL pour enregistrer er accéder à la donnée, d’un langage particulier donc, et de l’autre des solutions où l’emploi de SQL n’est qu’une option parmi d’autre. Je vois qu’effectivement on dit plus ou moins la même chose.

          La différence fait peu de sens je suis d’accord avec toi, étant donné que dans NoSQL il y a différents types, orientés documents ou autre. Je crois que ce qui est nouveaux aujourd’hui (par rapport à l’époque où SQL est apparu) c’est la quantité tellement énorme de données à traiter, que l’idée même de la structurer fortement n’est pas un sujet, étant donné qu’on doit d’abord trouver des solutions pour savoir comment la stocker (et y accéder) de manière efficace, donc de manière distribuée et traitée en parallèle par plusieurs nœuds.

          Je m’étais jamais penché sur la question mais Postgres semble bien effectivement ne plus faire de différence et assumer clairement la compétition avec d’autres produit étiquetés NoSQL : https://www.nobledesktop.com/classes-near-me/blog/why-learn-postgresql-for-data-science

          C’est pas forcément la meilleure solution pour tous les besoins mais l’aspect big-data et scalabilité a l’air d’être pris en compte de manière plutôt satisfaisante. C’est assez loin de n’être plus qu’un « SGBD à papa » qui se contente de remplir ses fonctionnalités historiques de moteur de base de données relationnelle. Et c’est bien heureux !

          • [^] # Re: Tout se paye un jour ou l'autre

            Posté par barmic 🦦 le 24 décembre 2023 à 09:57. Évalué à 3.

            

            Pour moi le SQL (et donc le NoSQL) ça ne dit absolument rien du stockage sous-jacent.

            En théorie oui, mais jusque dans les années 2000 ils utilisaient quasiment tous un stockage en ligne. C'est pour ça que l'aspect connaissance préalable de la taille maximale d'une ligne était (et le reste tout de même) central. Et à la lecture même quand ça ne sortait pas du moteur tu lisait toute la ligne et c'est pour ça que le partitionnement vertical a était inventé.

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

    • [^] # Re: Tout se paye un jour ou l'autre

      Posté par Dring le 23 décembre 2023 à 17:43. Évalué à 4.

      

      Tu remarqueras que je n'ai pas "disqualifié" la technologie. Mais le fait est que durant plusieurs années, ça a été utilisé par défaut juste parce que c'était neuf, c'était beau, c'était forcément bien. Et oui, ça correspond parfaitement au "Hype Cycle" décrit par Gartner ou Forrester. Mais c'est bien à ça qu'on pense quand on parle d'effet de mode en informatique.

      Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.

      C'est exactement ce qu'on a observé avec NoSQL. Pour une raison simple : ça correspond à la psychologie humaine et l'effet boule de neige. Y'a un gars qui a une bonne idée (on va dire un mec chez Google qui pond une lib). Ca se répand assez rapidement ("si Google utilise ça, il faut faire pareil !"). Ensuite, les gens se rendent compte que "ben non, en fait j'ai pas besoin de ça, c'est juste ultra compliqué pour rien dans mon cas". Puis finalement les personnes qui en ont vraiment l'usage rendent la techno pérenne.

      Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".

      • [^] # Re: Tout se paye un jour ou l'autre

        Posté par barmic 🦦 le 23 décembre 2023 à 18:37. Évalué à 5.

        

        Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.

        C'est très discuté parce que relativement peu de techno suivent véritablement cette courbe et quand elles le suivent on parle de période allant de quelques années à 10 ans. Relancer continuellement dessus 20 ans après n'a pas de sens.

        Cette manière de tout amalgamer pour rejeter c'est un peu comme si je disais que SQL c'était vraiment nul parce que les ORM c'est de la merde.

        C'est exactement ce qu'on a observé avec NoSQL.

        Ça fait 10 ans que l'on est sur le plateau. Que plus personne de sérieux ne cherche une guerre. Les SQL tentent de proposer une partie de ce que les NoSQL font et les NoSQL font de même avec le SQL.

        Tu remarqueras que je n'ai pas "disqualifié" la technologie.

        Non tu ne caricature pas du tout de manière outrancière et de manière répété. Vraiment. pas. du. tout.

        Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".

        Tu mélange beaucoup de choses… NoSQL c'est des technologies de base de données, BigData c'est mot-valise qui a était bien trop marketé pour garder encore sont sens de jeu de données trop gros pour entrer dans les bases de données standards (depuis 20 l'évolution étant ce qu'elle est les bases de données classiques ont considérablement augmentée leur capacité et une partie des techniques BigData sont devenues classiques comme le partitionnement).

        Et non encore une fois l'absence de schema ce n'est pas dans l'ADN du NoSQL. Ce n'était pas dans les premières bases et tu as toujours d'énormes pans de NoSQL qui sont structurées. Dans les orientées colonnes, les times series et les bases de données graphes, tu as un travail de modélisation de tes données au moins aussi important qu'en SQL parce que les techno t'y obligent. Et dans les orientés documents par exemple avec elasticsearch ou opensearch qui conque en à un usage en production doit utiliser un schemas pour ses indexes. C'est nécessaire.

        Enfin la réactance ce n'est pas l'inverse de la hype c'est son symétrique tout aussi bête. Vouloir utiliser une techno sans la comprendre et cracher sur une techno sans la comprendre même combat, les 2 amènes à des choix aussi mal éclairés.

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

        • [^] # Re: Tout se paye un jour ou l'autre

          Posté par Dring le 23 décembre 2023 à 23:49. Évalué à 5.

          

          OK, OK. Je vais pas répondre à tout, mais dans le désordre…

          Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.

          Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.

          Dans les orientées colonnes, les times series et les bases de données graphes, tu as un travail de modélisation de tes données au moins aussi important qu'en SQL parce que les techno t'y obligent

          Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.

          Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.

          Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour :
          - remettre de la base relationnelle classique
          - compléter avec du stockage brut (compatible S3)

          C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.

          Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.

          J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.

          Tu mélange beaucoup de choses… NoSQL c'est des technologies de base de données, BigData c'est mot-valise qui a était bien trop marketé pour garder encore sont sens de jeu de données trop gros pour entrer dans les bases de données standards

          Cet amalgame, il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.

          D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique… Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.

          (depuis 20 l'évolution étant ce qu'elle est les bases de données classiques ont considérablement augmentée leur capacité et une partie des techniques BigData sont devenues classiques comme le partitionnement).

          Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.

          Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.

          C'est très discuté parce que relativement peu de techno suivent véritablement cette courbe et quand elles le suivent on parle de période allant de quelques années à 10 ans. Relancer continuellement dessus 20 ans après n'a pas de sens.

          Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?

          Cette manière de tout amalgamer pour rejeter c'est un peu comme si je disais que SQL c'était vraiment nul parce que les ORM c'est de la merde.

          Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.

          Et bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.

          • [^] # Re: Tout se paye un jour ou l'autre

            Posté par Marotte ⛧ le 24 décembre 2023 à 03:03. Évalué à 6. Dernière modification le 24 décembre 2023 à 03:04.

            

            Je crois que le pire du pire ce n’est même pas de vouloir migrer vers ces technologies (comme Kafka/Spark/Kubernetes etc…) sans identifier clairement le ou les besoins précis qui le nécessitent et pourquoi, tout en espérant que « globalement » ça ne puisse que régler les différents problèmes rencontrés : « parce que c’est l’outil recommandé actuellement (par Gartner ou 01PC selon le niveau), ce sera donc forcément mieux que de chercher à mieux utiliser nos outils actuels, et puis on se doit d’être à la pointe de la technologie, donc faisons d’une pierre deux coups ». Ça non, c’est encore entendable.

            Par contre, le pire du pire, c’est de se lancer dans ce projet, à l’évidence très fortement structurant, en espérant que les changements organisationnels et méthodologies seront minimes voire inexistant. Ça je ne comprends pas.

            On m’a répondu une fois, je ne sais plus exactement à quelle proposition de ma part : « Non Marotte, c’est à l’outil de s’adapter à nos besoins, pas l’inverse. » Certes, certes… m’enfin un petit peu quand même. Planter une vis avec le marteau qu’on a acquis parce qu’on avait par ailleurs aussi des clous à planter c’est quand même assez sûrement voué à l’échec (du moins, à un résultat pas tout à fait satisfaisant voire des conséquences fâcheuses ^^) pour s’épargner la tentative.

            Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?

            Sur ce point il y a des contre-exemple, au moins un, je pense à git : pas de franche opposition, un standard de fait quasi universel après seulement quelques années (que dis-je, mois !) à la suite de son introduction. On parle aujourd’hui de "gitops" pour désigner le concept de « truc-as-code » (infrastructure/opération/déploiement/…). Au point même que certains considèrent que svn est devenu obsolète, ce qui n’est pas le cas, il conserve des avantages pour certains usages et est toujours maintenu. Ceci dit on peut dire qu’il a vu le nombre des ses utilisateurs diminuer drastiquement quand git est sorti. Mais bref, je vois pas git suivre un cycle : « mais en fait le contrôle de versions distribué à la Git c’est nul, on va réinventer ça en mieux ! », en tous cas pas sur un cycle de 20 ans.

            Si un jour un développeur écrit du code depuis Mars je parie qu’il utilisera Git !

            Je ne sais pas si Linus Torvalds est à l’origine d’autres logiciels que Git et Linux (à part sûrement des drivers de FS à la pelle carrée j’imagine) mais avec seulement ces deux logiciels je crois qu’on peut clairement dire que c’est un des plus grand développeur de sa génération.

            • [^] # Re: Tout se paye un jour ou l'autre

              Posté par Tonton Th (Mastodon) le 24 décembre 2023 à 07:43. Évalué à 5.

              

              Je ne sais pas si Linus Torvalds est à l’origine d’autres logiciels que Git et Linux

              • http://subsurface-divelog.org/
              • https://en.wikipedia.org/wiki/Linus_Torvalds#Other_apps

              • [^] # Re: Tout se paye un jour ou l'autre

                Posté par Marotte ⛧ le 28 décembre 2023 à 19:35. Évalué à 4. Dernière modification le 28 décembre 2023 à 19:36.

                

                C’est un logiciel « de niche » pour employer une expression à la con, que je n’aurais sûrement pas l’occasion d’utiliser ni même de tester moi-même, mais un grand merci pour le lien.

                À la lecture de la FAQ j’apprends l’existence des « ordinateurs de plongée », je ne suis pas surpris et arrive à voir à peu prêt leurs intérêts mais je ne savais pas qu’un tel objet existait. Je pensais bêtement que les plongeurs se reposaient encore intégralement sur l’expérience, empiriquement. ^^

                • [^] # Re: Tout se paye un jour ou l'autre

                  Posté par barmic 🦦 le 28 décembre 2023 à 19:50. Évalué à 5.

                  

                  Je pensais bêtement que les plongeurs se reposaient encore intégralement sur l’expérience, empiriquement.

                  Entre les 2 il existe tout de même des outils comme les montres de plongées qui bien sûr sont étanches mais permettent aussi de savoir depuis combien de temps tu es en plongées (évidement tu peux avoir d'autres fonctions comme une boussole).

                  L'empirisme est dangereux en plongée à cause de la narcose.

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

                  • [^] # Re: Tout se paye un jour ou l'autre

                    Posté par Marotte ⛧ le 28 décembre 2023 à 20:09. Évalué à 4.

                    

                    Oui les montres, c’est vrai. La profondeur ça doit être aussi, avec le temps, l’information la plus cruciale, pour le respect des paliers de décompression j’imagine.

                    • [^] # Re: Tout se paye un jour ou l'autre

                      Posté par pulkomandy (site web personnel, Mastodon) le 28 décembre 2023 à 20:57. Évalué à 5.

                      

                      Il y a quelques calculs complexes. Plus on descend, plus on consomme d'air (ou autre mélange) des bouteilles à chaque respiration, parce que la pression augmente et donc la quantité d'air dans les poumons, à volume égal, augmente aussi.

                      Ce qui fait que ce n'est pas simple de savoir où on en est de sa réserve d'air et à quelle vitesse elle va se vider, en tenant compte aussi du temps pour remonter incluant les paliers de décompression.

                      Ça rend assez intéressante l'utilisation d'un ordinateur pour calculer tout ça en temps réel.

                      Et, en cas d'accident, si jamais il y en a un, ça sert de "boîte noire" pour savoir ce qu'il s'est passé.

            • [^] # Re: Tout se paye un jour ou l'autre

              Posté par Dring le 24 décembre 2023 à 11:21. Évalué à 6.

              

              Bien sûr il y a des contre exemples et GIT est un très bon cas. C’est pour ça que j’ai dit “souvent” et pas “toujours” :-).

              Dans les trucs qui n’ont fait que grimper progressivement sans suivre cette fameuse courbe : Python et d’autres langages, SQL justement, …

              Et il y a un autre point : quand on est dans la vague, on ne s’en rend pas forcément compte, aveuglé par l’enthousiasme. J’ai vu beaucoup d’égarement “de bonne foi”. Les routes de l’enfer sont pavées de bonnes intentions. Personne ne peut se targuer de n’avoir jamais été du mauvais côté.

              Quand le DLT (Distributed Ledger Technology) avait le vent en poupe, les évangélistes étaient très nombreux, et on pouvait se sentir limite con de ne pas en être.

              Ce qui sauve, c’est de se poser les bonnes questions. Mais on passe, comme toi, pour le rabat-joie de service (au mieux) ou pour le vieux con (au pire).

              Le sujet pour lequel je me fais beaucoup de soucis et je suis ultra-perplexe, c’est les LLM. J’ai été le vieux con jusqu’à l’an dernier, et là je ne sais plus sur quel pied danser. Les phénomènes d’hallucination sont encore là, empêchant les scénarios les plus interessants d’être réalisables sans intervention/validation humaine, mais y a un vrai potentiel et c’est difficile de tempérer les ardeurs.

          • [^] # Re: Tout se paye un jour ou l'autre

            Posté par barmic 🦦 le 24 décembre 2023 à 16:42. Évalué à 4. Dernière modification le 24 décembre 2023 à 16:42.

            

            Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.

            Donc tu parle de contraintes d'intégrité et oui c'est la définition du NoSQL. Mais ce n'est pas arrivé de nulle part. Les mainframes commencent à montrer leur limite de scalabilité, on commence à vouloir créer des services mondiaux et des gens (en particulier Brewer) ont montré que les propriété ACID ne permettaient pas d'avoir à la fois un haut niveau de disponibilité et une tolérance aux problèmes réseaux¹. Présenter ce travail comme des gens inconséquents me parait injuste et irrespectueux.

            Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.

            Ça c'est un avis. Tu as des gens qui font carrière sans en avoir besoin. C'est un peu comme dire que le typage statique on en a toujours besoin sauf quelques cas particulier. Ça n'a pas empêchés un paquet de monde de faire des choses incroyables avec un typage dynamique. Les données n'ont pas intrinsèquement un modèle, c'est l'usage qu'on en fait qui défini comment il est intéressant de les modéliser.

            Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.

            Quand tu parle de modélisation de données dans une base comme cassandra, tu as une série de ses colonnes qui vont servir à la fois de comment les données sont partitionnées, comment est-ce que tu va pouvoir les requêter et de comment va se comporter leur éventuelle suppression. Ça demande d'avoir une très bonne connaissance de tes données, de ce que tu va en faire et des volumes (à la fois de requête, de volume de données total, mais aussi par partition et de savoir quelle est la stratégie de rétention que vous avez). C'est très loin de ce que tu a l'air d'imaginer.

            Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.

            Ça dépend de ce que tu appel extrêmement rare. Travailler avec plusieurs datacenter, je ne trouve pas que c'est extrêmement rare. Dans les années 2000 les SGBD ne savaient pas gérer des latences fortes entre leurs nœuds. Maintenant ils le font, mais ils ont rognés sur la performance ou la cohérence (on échappe pas au théorème CAP facilement). Et je parle ici de solutions de type fail over ou hot standby, le load balancing ou l'actif-actif multi DC, que je sache, aucun SGBD ne le propose en standard (et les solutions que je connais impliquent d'avoir une base NoSQL à côté des nœuds).

            Il me semble que pas mal de monde le fait mais avec un cloud provider qui te cache toute cette difficulté. Quand tu utilise Amazone RDS, ils n'ont pas juste instanciés un pg pour toi, ils ont un énorme travail pour te cacher toute cette complexité.

            Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour : […]

            NoSQL n'est qu'un détail dans tout ça. Hadoop contient une base NoSQL et des choses s'approchant de S3. Tu présente ce dernier comme une solution pourtant. Se lancer tête la première dans un truc aussi gros qu'hadoop c'est forcément compliqué, comme ça le serait avec n'importe quelle stack un peu grosse. Il est pourtant possible de ne déployer que ce dont on a besoin d'hadoop et d'avancer progressivement si on en a le besoin. Pour moi dans ce que tu décris c'est la prise de décision « flip the table » plus que la techno qui est un problème.

            En plus les SGBDR en 2018 ont énormément évolués par rapport aux années 2010.

            Cet amalgame [NoSQL - BigData], il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.

            Au vu de ton expérience, je comprends, mais je me fou du discours marketing quand je prends une décision technique. Encore une fois hype et réactance même combat.

            Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.

            Excuse-moi oui je parlais de partitionnement réseau. Dis autrement de tolérance au partitionnement du cluster.

            Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.

            À partir du moment où tu es multi-dc. Si tu as une SLA demandée supérieure à ce que propose un DC par exemple, si ton service est utilisé sur plusieurs timezone et que tu veux des latences assez faible. Mais encore une fois aussi rare que tu l'imagine en quoi ça rend les développeurs de ces solutions inconséquent ?

            Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?

            Encore une fois je pense que tu mélange beaucoup de choses. Tu parlait du GHC et il y a eu des études dessus et Gartner n'est pas aussi bon que ce que leur théorie cherche à laisser croire. Ça aussi c'est du marketing.

            Si c'est une façon de dire que les nouveautés commencent en étant inconnues, puis font l'objet de curiosité avant qu'elles soient assimilées, c'est un peu bateau. Pour ce qui est des blockchain, smartcontracts par exemple il n'existe pas de ce qui ressemblerait à un « plateau de productivité » comme l'annonce la théorie.

            Pour les frameworks web si tu prend react par exemple il n'a pas connu de « creux de la désillusion » vu non plus d'ailleurs et angular semble plutôt descendre tranquillement de son apogée vers le fameux « plateau de productivité ». Les autres ? S'ils ont un « sommet des attentes surdimensionnées », alors ça ne touche généralement pas grand monde et ils ne survivent pas à ce qui s'apparenterait au « creux des désillusions ».

            Bref la théorie marche quand elle veut bien.

            Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.

            Et pourquoi tu fais la distinction SQL / mauvais usage via un ORM ? Mais pas NoSQL / mauvais usages ?

            Mais j'hésite pas une seconde si je pense que c'est le bon outil.

            Très bien, mais quand tu présentent les créateurs de ces techno comme des gens inconséquent tu ne donne pas l'impression d'avoir cette hauteur (et d'autant plus quand tu mélange allègrement hadoop et nosql par exemple).

            ---

            1. tu as eu plus tard les new-sql qui ignorent se problème en utilisant des horloges atomiques, l'idée étant que si chaque nœud peut faire confiance en l'horodatage les uns des autres, il est plus facile de se mettre d'accord. ↩

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

          • [^] # Re: Tout se paye un jour ou l'autre

            Posté par BAud (site web personnel) le 25 décembre 2023 à 01:41. Évalué à 5.

            

            Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70.
            Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe.

            Les partition views sont apparues en Oracle 7.3.4.3 c'était difficilement utilisable, vers 1998
            Les partitions tables en Oracle 8.0.5 vers 1999 / 2000.
            Les cluster tables stait pas la panacée

            Oracle 9i a apporté pas mal d'améliorations de perfs (et des plans d'exécutions un peu plus utilisables pour tuner les bases).

            C'est en PostgreSQL 9.5 que sont apparues les partitions (vers 2010).

            Franchement PostgreSQL, entre Ora2Pg et tous les outils de l"écosystème, c'est plus sympathique qu'Oracle qui est un peu spartiate…

            • [^] # Re: Tout se paye un jour ou l'autre

              Posté par Ontologia (site web personnel) le 09 janvier 2024 à 21:13. Évalué à 3.

              

              C'est en PostgreSQL 9.5 que sont apparues les partitions (vers 2010).

              La partitionnement déclaratif a été disponible à partir de la version 10, et réèllement utilisable à partir de la 11.

              Dans la 9.5, le partitionnement était une bidouille à base d'héritage et de triggers.

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

• # vitess.io ?

  Posté par bunam le 22 décembre 2023 à 22:14. Évalué à 3.

  

  J'ai ça sous le coude mais jamais utilisée :
  https://vitess.io/docs/19.0/overview/whatisvitess/

  • [^] # Re: vitess.io ?

    Posté par woffer 🐧 le 23 décembre 2023 à 08:31. Évalué à 2. Dernière modification le 23 décembre 2023 à 08:31.

    

    C'est utilisé ou c'était utilisé (je n'ai pas vérifié depuis 5 ou 6 ans) par Youtube pour leurs BDD MySQL.

    • [^] # Re: vitess.io ?

      Posté par woffer 🐧 le 23 décembre 2023 à 08:34. Évalué à 2.

      

      Ca semble être encore le cas :

      https://github.com/vitessio/vitess/blob/main/ADOPTERS.md

    • [^] # Re: vitess.io ?

      Posté par bunam le 23 décembre 2023 à 10:14. Évalué à 2.

      

      c'est indiqué dans la page fournie

• # Cassandra: petit retour d'expérience

  Posté par groumf le 23 décembre 2023 à 10:06. Évalué à 3.

  

  Pour faire de schémas optimisés il faut déja bien s'accrocher.

  Une fois que ça marche bien avec un seul noeud le passage en cluster dans lequel tu peux avoir une totale confiance c'est encore une autre paire de manche, ça deviens un job à temps plein donc il faut que le volume de données le justifie.

  Je n'ai jamais utilisé ScyllaDB mais la documentation montre qu'ils ont su synthétiser les besoins utiles pour faciliter la prise en main.

• # Besoins

  Posté par barmic 🦦 le 23 décembre 2023 à 10:13. Évalué à 8.

  

  Cependant, suite à des problèmes de performance sur de grosses quantités de données (sans qu'il y ait besoin de les répartir sur plusieurs machines), j'enquête sur d'autres possibilités.

  La démarche me semble manquer de quelque chose. Le choix de la technologie de stockage devrait être fortement cohérente avec l'usage. Sans un état des lieux de l'usage prévu c'est impossible de faire un choix. Volume de données, de requêtes en lecture et en écriture, la complexité de ses requêtes, la forme des données, la rétention que vous avez, la possibilité ou le besoin de partitionnement, l'infrastructure que vous utilisez,…

  Sans tout ça il me paraît difficile de choisir et à votre place je prendrais quelques choses de connu pour avoir facilement des retours, voir connu dans l'équipe et assez flexible.

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

• # Surreal DB

  Posté par El Titi le 23 décembre 2023 à 12:03. Évalué à 2.

  

  Jette un oeil à SurealDB, une base multi-modèle récente qui supporte Python.

  Fireship a fait une petite vidéo sur ce sujet.

  • [^] # Re: Surreal DB

    Posté par El Titi le 23 décembre 2023 à 12:23. Évalué à 2.

    

    Il a aussi produit un tuto sur cette DB.

  • [^] # Re: Surreal DB

    Posté par devnewton 🍺 (site web personnel) le 23 décembre 2023 à 15:51. Évalué à 4.

    

    Sureal n'est pas libre (BSL 😢).

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Surreal DB

      Posté par El Titi le 23 décembre 2023 à 16:24. Évalué à 3.

      

      Ah mince, Fireship la mentionnait comme open-source et je n'ai pas reverifié. Ils ont peut-être changé leur modèle en cours de route comme quasiment presque toutes les dbs pas développées par des communautés aujourd'hui.

      Quel dommage !

    • [^] # Re: Surreal DB

      Posté par El Titi le 23 décembre 2023 à 16:28. Évalué à 3.

      

      Les ptits coquins : https://github.com/surrealdb/surrealdb/commit/d8c53da443ff5ed49381cf991a06d2c4ca724e71

    • [^] # Re: Surreal DB

      Posté par El Titi le 23 décembre 2023 à 16:37. Évalué à 4.

      

      Et l'open-source washing habituel.

      Dayssu je suis !

• # Bien choisir sa base de données

  Posté par Skilgannon le 23 décembre 2023 à 14:41. Évalué à 2.

  

  Je ne suis pas dev pour un sou mais de mon point de vue il faut déjà s'y retrouver dans tout les types de bases de données.

  La conférence suivante présente les différents types et à quoi ils servent.

  Bien choisir sa base de données (Sébastien KELLER, Alexandre BUDZKO) Devoxx 2023

• # et le meilleur de tous ?

  Posté par ChocolatineFlying le 23 décembre 2023 à 17:28. Évalué à 9.

  

  • les DSI pensent à lui en premier pour gérer un projet
  • celui qui permet de créer des graphiques facilement
  • celui qui permet des liens dynamiques
  • fonctionne sans sql et utilise un langage de script réputé
  • est soutenu par des grande entreprise
  • est utilisé massivement dans notre système bancaire, la défense, l’éducation nat, etc …
  • possède moult greffon de connexion
  • mais hélas(heureusement?) pas libre !

  le sus nommé : Excel 2021 \o/

  • [^] # Re: et le meilleur de tous ?

    Posté par Benoît Sibaud (site web personnel) le 23 décembre 2023 à 17:43. Évalué à 9.

    

    C'est un truc récent qui veut cloner Calc ?

    • [^] # Re: et le meilleur de tous ?

      Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 24 décembre 2023 à 15:57. Évalué à 4.

      

      Un truc moins fiable d'après ce que j'ai ouï-dire de plusieurs sources.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: et le meilleur de tous ?

      Posté par cg le 27 décembre 2023 à 08:31. Évalué à 2.

      

      Pas du tout, c'est un sport.

  • [^] # Re: et le meilleur de tous ?

    Posté par Vlobulle le 27 décembre 2023 à 16:42. Évalué à 2.

    

    Et quand la feuille Excel marche bien, on l'industrialise en en faisant une base Access.

    Et quand la base Access marche bien, on l'industrialise en… ah non.

    • [^] # Re: et le meilleur de tous ?

      Posté par Marotte ⛧ le 13 janvier 2024 à 19:18. Évalué à 3.

      

      On repart sur un Powerpoint vierge pour faire couler du jus de cerveau. Dans le cadre d’une task-force de préférence, agile dans l’idéal.

• # backup ?

  Posté par oau le 24 décembre 2023 à 11:29. Évalué à 10.

  

  bonjour,

  je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.

  Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.

  Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.

  Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …

  Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.

  Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.

  Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.

  • [^] # Re: backup ?

    Posté par devnewton 🍺 (site web personnel) le 24 décembre 2023 à 12:45. Évalué à 7.

    

    Ce que tu aimes faire a un nom : la boring architecture.

    En gros on choisit ce qui a bien marché et qui marchera (probablement) encore bien dans 10 ans.

    Le défaut, c'est qu'il est difficile d'innover et qu'on se retrouve coincé avec des technos mal foutues (ldap par exemple :-) ).

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: backup ?

      Posté par oau le 24 décembre 2023 à 14:04. Évalué à 6.

      

      Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.

      Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.

      Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.

  • [^] # Re: backup ?

    Posté par Sacha Trémoureux (site web personnel) le 24 décembre 2023 à 13:14. Évalué à -10.

    

    Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.

    Pour une remarque de merde, t’as fait fort. Apprendre du passé bien sûr, être persuadé que les difficultés d’hier sont exactement les mêmes que celle d’aujourd’hui c’est vraiment être vieux con et ignorant.

    • [^] # Re: backup ?

      Posté par oau le 24 décembre 2023 à 13:59. Évalué à 4.

      

      Apprendre du passé bien sûr, être persuadé que les difficultés d’hier sont exactement
      les mêmes que celle d’aujourd’hui c’est vraiment être vieux con et ignorant.

      Et me faire dire ce que je ne dis pas c'est … ?

      Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.

      Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.

      • [^] # Re: backup ?

        Posté par totof2000 le 24 décembre 2023 à 14:13. Évalué à 2.

        

        En plus du manque de recul, les jeunes génération sont devenuies de plus en plus suceptibles : gros manque d'humilité et de remise en question. Il y a quelques années on pouvait encore discuter sur de (mauvais ) chois techniques sans que ça ne soit pris personnellement, mais aujourd'hui la moindre remarque, même formulée avec bienveilance, heurte la suceptibiité de plus en plus de monde.

        • [^] # Re: backup ?

          Posté par Sacha Trémoureux (site web personnel) le 24 décembre 2023 à 15:06. Évalué à 2.

          

          Source ? Hormis que tu vieillis ?
          L’humilité et la remise en question c’est dans les deux sens.

      • [^] # Re: backup ?

        Posté par Sacha Trémoureux (site web personnel) le 24 décembre 2023 à 15:10. Évalué à 7.

        

        Je te rejoins sur le fond, étant d’astreinte je préfère dormir tranquille avec des technos éprouvées en production.

        Sur la forme, je maintiens que « les jeunes n'ont plus aucune culture en informatique » c’est une remarque particulièrement stupide et hautaine. Faut redescendre un peu.

  • [^] # Re: backup ?

    Posté par wilk le 24 décembre 2023 à 15:15. Évalué à 7.

    

    Point vieux con : les jeunes n'ont plus aucune culture en informatique

    C'est surtout que les jeunes ont été éduqués par les vieux.

    Le Temps Ne Fait Rien A L'affaire…

    Ce qui me fait marrer à propos du hype c'est que quand j'étais jeune mon père me parlait déjà de VM et de NoSQL et ça semblait d'un ringard !

    • [^] # Re: backup ?

      Posté par oau le 24 décembre 2023 à 15:33. Évalué à 3.

      

      C'est surtout que les jeunes ont été éduqués par les vieux.

      la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)

      Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.

      Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.

      Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.

      Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.

    • [^] # Re: backup ?

      Posté par oau le 24 décembre 2023 à 15:35. Évalué à 1.

      

      moi mon père il me parlait de cartes perforées, de fortran et il mettait son code au coffre le soir. :)

      J'essaie juste de dire. Attendre, prendre son temps, soupeser les besoins, mettre les avantages et les inconvénients et ne pas réécrire la roue avant de mettre en prod des technos ingérables.

    • [^] # Re: backup ?

      Posté par devnewton 🍺 (site web personnel) le 24 décembre 2023 à 15:49. Évalué à 4.

      

      C'est surtout que les jeunes ont été éduqués par les vieux.

      Non justement et c'est une spécificité de notre secteur.

      Ma génération a surtout appris en autodidacte, car on a été jeune du temps de la micro-informatique où un ordinateur démarrait sur un BASIC et été vendu avec un manuel de programmation.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: backup ?

        Posté par barmic 🦦 le 24 décembre 2023 à 18:06. Évalué à 1.

        

        Ma génération a surtout appris en autodidacte, car on a été jeune du temps de la micro-informatique où un ordinateur démarrait sur un BASIC et été vendu avec un manuel de programmation.

        C'est ce livre qui t'a appris SQL ?

        Autant faire de la bidouille en autodidacte j'en connais pleins. Autant des bases de données, j'ai jamais entendu.

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

        • [^] # Re: backup ?

          Posté par alkino le 24 décembre 2023 à 18:14. Évalué à 4. Dernière modification le 24 décembre 2023 à 18:17.

          

          Ba si moi qui ai commencé l'info vers 2000 (en tant que jeune) j'ai commencé les bases de données pour coder des sites pourries en LAMP.

          Alors oui je gérais pas de grosses bases. Mais l'école d'info non plus m'a pas appris les BDD.

          Ce qui manque à beaucoup d'autodidactes jeunes c'est de faire un peu d'opensource pour arriver sur le marché de l'emplois avec autre chose que des pets projects débiles. Avoir relu du code d'autres gens, avoir compris à quoi sert la doc, les tickets et les pull requests, …

        • [^] # Re: backup ?

          Posté par devnewton 🍺 (site web personnel) le 24 décembre 2023 à 19:25. Évalué à 4.

          

          Penser qu'un autodidacte s'arrête au premier livre et attends passivement qu'on lui dise quoi apprendre ensuite, c'est bien une remarque de djeuns 😜.

          L'esprit de la micro-informatique à l'époque, c'était justement de faire pleins de choses différentes et de donner envie avec des appareils grands public.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: backup ?

            Posté par barmic 🦦 le 24 décembre 2023 à 22:35. Évalué à 1.

            

            J'ai appris la programmation avec le manuel de TI82, puisqu'on en est à l'ad hominem. Et je ne me permettrait pas de juger quelqu'un sur le fait qu'il soit autodidacte.

            Les remarques "marrantes" sur les jeunes il y en a pleins les collèges et ça je me permet très bien de juger.

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

            • [^] # Re: backup ?

              Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 décembre 2023 à 11:29. Évalué à 5.

              

              C'est surtout qu'être autodidacte n'est pas infamant comme certains semblent le croire ni synonyme d'incompétence ou de manque de connaissances. Combien d'entre nous pourraient arriver à la cheville de cet autodidacte ?

              « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

              • [^] # Re: backup ?

                Posté par barmic 🦦 le 25 décembre 2023 à 12:01. Évalué à 1.

                

                Il me semblait que la conversation présentait l'inverse : l'autodidacte serait la bonne manière de découvrir l'informatique.

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

                • [^] # Re: backup ?

                  Posté par devnewton 🍺 (site web personnel) le 25 décembre 2023 à 12:15. Évalué à 3.

                  

                  Je ne sais pas si c'est La Bonne Manière, mais les machines vendus, livres et magazines vendus au grand public poussaient dans cette direction.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: backup ?

                    Posté par Thomas Douillard le 25 décembre 2023 à 20:44. Évalué à 6.

                    

                    C'était une époque, les débuts de l'info grand public et des appareils accessibles financièrement aux particuliers. L'offre de formation n'était pas la même probablement, et le domaine bouge vite.

                    Du coup c'était un paradis pour geek, mais tous les pros ne sont pas obligés d'être geek et aimer s'autoformer sur son temps libre. Le demander c'est fermer la porte à pleins de gens. Avoir des bases solides aide évidemment, mais on est pas obligés de les acquérir en montant des pcs pièce par pieces du matériel au logiciel en recodant des noyaux full stack par soi même. Il y a pas une manière d'apprendre mais si c'est pour travailler dans une équipe de développement c'est mieux de le faire avec d'autres et se manger leurs critiques constructives et moins constructives. C'est déjà plus être strictement autodidacte.

          • [^] # Re: backup ?

            Posté par pulkomandy (site web personnel, Mastodon) le 25 décembre 2023 à 10:08. Évalué à 6.

            

            Y'a aussi plein de gens qui ont acheté un ordinateur dans les années 80 et n'en ont rien fait à part lancer des jeux vidéos (ou d'autres applications plus sérieuses).

            Dans les années 90, il y avait toujours des gens pour s'amuser à ronter un petit site web, c'est le BASIC de l'époque. Avec en plus quelques cours d'initiation à l'informatique à l'école.

            Aujourd'hui ce sont plutôt les projets électroniques à base de Raspberry Pi et d'Arduino.

            Donc des autodidactes il y en a toujours. Pas tout le monde bien sûr, mais ça fait partie des choses qu'on peut facilement voir en entretien d'embauche. (Sans que ça soit un critère essentiel, il y a des gens qui font autre chose de leurs loisirs et qui peuvent aussi apporter plein de choses dans une équipe.

            • [^] # Re: backup ?

              Posté par devnewton 🍺 (site web personnel) le 25 décembre 2023 à 12:20. Évalué à 4. Dernière modification le 25 décembre 2023 à 12:21.

              

              Au niveau individuel, on ne va rien déduire d'intéressant :-)

              Mais pour une génération, se voir présenter le numérique façon micro-informatique ou façon smartphone, ça change tout.

              Ce qui s'est passé, c'est comme si dans le monde du foot, on avait fermé la plupart des terrains communaux, qu'on ne vendait plus de ballons que dans des magasins spécialisés et que pour la majorité des gens ce n'était plus qu'un spectacle à la télé.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: backup ?

                Posté par pulkomandy (site web personnel, Mastodon) le 26 décembre 2023 à 15:03. Évalué à 3.

                

                Ça me semble un peu facile d'oublier les consoles de jeux (pas du tout ouvertes pour développer ses propres trucs dessus pour la très grande majorité) et le fait que les smartphones aujourd'hui sont bien plus répandus que les ordinateurs à l'époque (on est passés de un ordinateur par famille dans le meilleur des cas à un smartphone dans la poche de chaque personne).

                On adonc deux phénomènes qui peuvent très bien s'éouilibrer:
                - beaucoup plus de monde a accès à des moyens informatiques dont on ne rêvait même pas il y a 40 ans,
                - mais moins d'entre eux vont devenir des petits génies de la programmation

                Je n'ai pas de statistiques à donner mais je pense que le nombre de gens qui font des trucs incroyables avec des Arduino, des Raspberry Pi, de la programmation en Scratch ou en Swift Playground, ou encore qui scriptent quelques trucs à base de bots Discord, il a certes baissé en proportion du nombre de g ns qui ont accès à un ordinateur (au sens large, incluant les smartphones), mais pour autant, il n'a pas forcément baissé par rapport à la population globale. Les compétences ne sont certainement pas les mêmes, mais quand je fais passer des entretiens d'embauche, même à des étudiants sortis d'école, ce n'est pas exceptionel de voir des gens qui ont fait bien plus que suivre une formation à l'école. Certes, c'est aussi parce que on a un service de recrutement qui recherche les candidatures avec ce type de profil, et quand ils en trouvent, leur font passer un entretien avec moi plutôt qu'avec d'autres collègues qui recherchent et valorisent d'autres choses chez les candidats, donc mon point de vue est bien sûr complètement biaisé. Il n'empêche que ces candidats existent, en nombre suffisant pour que je fasse ce type d'entretien assez régulièrement.

                • [^] # Re: backup ?

                  Posté par devnewton 🍺 (site web personnel) le 26 décembre 2023 à 15:08. Évalué à 5.

                  

                  Je ne prends pas en compte les consoles de jeux, car elles existaient à l'époque de la micro-informatique et… elles existent toujours, donc on peut réfléchir "toute console égale par ailleurs" comme diraient les économistes !

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: backup ?

          Posté par wilk le 24 décembre 2023 à 19:39. Évalué à 4.

          

          J'ai appris SQL sur le tas avec MSAccess 1.0 ! Uniquement avec la doc embarquée, et bien c'était pas si mal foutu.
          Au début je gérai ça comme en C, une table, une clé primaire c'est comme fseek (du nosql quoi) !
          On peut apprendre SQL très progressivement en fait, surtout à l'époque où on(je) n'avait pas à traiter des quantités énormes et complexes de données.

          • [^] # Re: backup ?

            Posté par barmic 🦦 le 24 décembre 2023 à 22:51. Évalué à 2.

            

            Et ça apprenait comment construire une forme normale ? Parce que sinon c'est un contre argument à l'hypothèse de base : avant on était autodidacte et on jouait avec notre caca en utilisant des bases de données.

            Je trouve qu'il y a une vrai différence entre savoir quoi faire pour que quelque chose fonctionne et savoir pourquoi il faut faire ça pour que ça fonctionne. Et je doute qu'il existe beaucoup de manuel utilisateur qui aillent aussi loin.

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

            • [^] # Re: backup ?

              Posté par wilk le 25 décembre 2023 à 08:12. Évalué à 4.

              

              La forme normale est évidente quand on apprend le language machine et la structure des données sur un disque car on ne traite que des index.
              Pour la même raison, quand on a l'habitude de traiter des données directement on sait pourquoi et comment ça fonctionne. On a peu de mémoire, il faut une intégrité parfaite et aucune redondance.
              Mon livre de chevet : La pratique de l'Apple // volume 3, language machine et assembleur du 6502
              On ne jouait pas non plus avec notre caca mais on hackait ce que les précédents avaient pondu pour voir comment ils faisaient. Ensuite les logiciels libres sont apparus ce qui a grandement facilité la tache mais le principe de l'apprentissage reste le même.

              • [^] # Re: backup ?

                Posté par barmic 🦦 le 25 décembre 2023 à 08:54. Évalué à 4.

                

                Donc l'idée c'est de re-découvrir intuitivement ce qui a fait l'objet de plusieurs années de recherche par quelqu'un qui savait très bien comment ça fonctionne en dessous puisqu'il fait partie de ceux qui l'ont conçu.

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

                • [^] # Re: backup ?

                  Posté par wilk le 25 décembre 2023 à 09:40. Évalué à 3.

                  

                  Intuitivement mais avec les bases du fonctionnement primaire, c'est à dire le language machine sinon c'est trop abstrait.

                  • [^] # Re: backup ?

                    Posté par barmic 🦦 le 25 décembre 2023 à 10:03. Évalué à 4.

                    

                    Codd connaissait ça parfaitement et ça lui a pris 4 ans pour arriver à la base, la troisième forme normale, il y a encore eu de l'exploration sur le sujet pendant des décennies.

                    C'est très bien l'autodidacte. Je suis quelqu'un qui préfère très largement apprendre en bottom up plutôt qu'en top down. Mais le principe c'est justement de monter en théorie et personne n'est capable de re-découvrir ACID, les formes normales, lire un plan d'exécution, les différents niveaux d'isolation, comprendre les différentes formes d'index,… On parle de sujets de millions d'heures de travail fait par des milliers d'individus avec des essais/erreurs multiples.

                    Considéré ça comme intuitif me fait plutôt l'impression que le sujet a été effleuré. Les gens comme Codd sont des scientifiques hors-pair reconnus parmi les siens par les plus hautes distinction existantes et tu en as au moins une dizaines comme lui. Apprendre le fruit de leurs travaux est une tâche, le re-découvrir intuitivement grâce au manuel utilisateur de l'Apple II est de l'ordre du génie

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

                    • [^] # Re: backup ?

                      Posté par wilk le 25 décembre 2023 à 12:06. Évalué à 3.

                      

                      Je pense que tu confonds le fait de l'inventer, le modéliser, le théoriser avec le fait de le comprendre et l'utiliser progressivement.
                      L'apprentissage autodidacte est incrémental.
                      Comme je l'indiquais au début je me suis juste dit tien au lieu de faire LDA $FF82, X, fopen fseek fread je remplace ça par select from where. Puis tien si je défini ça comme ça je suis sûr que mon id est bien dans les deux tables et ainsi de suite.
                      Y a pas besoin d'être un génie, faut surtout avoir la chance d'être né dans un milieu de hackers.

  • [^] # Re: backup ?

    Posté par jean_clume le 24 décembre 2023 à 17:55. Évalué à 5.

    

    Pour du backup MongoDB un bon outil quand tu as un cluster "shardé" c'est Percona Backup for MongoDB (https://www.percona.com/blog/mongodb-backup-best-practices/).
    Bien sur il faut avoir un peu de ressource dédiée au backup mais ça fait du PITR et de mémoire ça affectait pas les performances du cluster.

    D'une manière générale je recommande de voir ce que fait Percona comme outils pour les bases de données (MySQL, Postgresql, Mongo, …), il sont vraiment bons dans leur domaine.

    • [^] # Re: backup ?

      Posté par oau le 25 décembre 2023 à 18:51. Évalué à 3.

      

      j'en suis arrivé aux même conclusions oui. Percona. Mais avec un backup à froid. Je n'ai pas encore suffisamment d'exp et donc de confiance pour me lancer dans des acrobaties surtout quand la doc dit :

      mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.
      

      https://www.mongodb.com/docs/manual/core/backups/#back-up-with-mongodump

      le reste de la description fait un peu flipper je trouve.

      • [^] # Re: backup ?

        Posté par barmic 🦦 le 25 décembre 2023 à 19:09. Évalué à 2.

        

        Ouai… Alors transaction et NoSQL ne devrait jamais aller de pair… C'est à mon avis une grosse connerie de la part de mongo de tenter de jouer les SGBDR et c'est logique que ça ne marche pas (on ne viol pas le théorème CAP impunément)… Et ça n'est pas désactivable à première vue.

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

  • [^] # Re: backup ?

    Posté par barmic 🦦 le 24 décembre 2023 à 18:02. Évalué à 2.

    

    Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …

    Ça me pose 2 de questions :

    • Qu'est-ce que tu entend pas consistant ?
    • Une fois la base en RO pourquoi ne pas utiliser mongodump ?

    On fait des backups de bases mongo et on fait des tests de restauration mensuel sans problème particulier (et on vérifie l'usage des données par le soft ensuite on ne se contente pas d'un OK de la base), mais je n'ai jamais entendu parler de problème de consistance.

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

  • [^] # Re: backup ?

    Posté par barmic 🦦 le 24 décembre 2023 à 18:12. Évalué à 6.

    

    Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.

    C'est les jeunes qui font des choix d'architecture et/ou de techno ? Et ils le font sans que le reste de l'entreprise leur pose de contraintes ? Et on lance les techno sans une étape de rampup pour vérifier que tout fonctionne (du bench, de la vérification de comment ça se comporte dans des situations critiques, des backup, du monitoring etc) ?

    Quel est le rapport entre « les jeunes » et les choix fait dans une entreprises ?

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

    • [^] # Re: backup ?

      Posté par SpaceFox (site web personnel, Mastodon) le 24 décembre 2023 à 19:16. Évalué à 9.

      

      C'est comme les gens qui expliquent que le problème en prod c'est la faute du stagiaire.

      Si ton stagiaire a pu péter la prod, c'est que ton organisation a de gros problèmes, bien plus graves qu'une erreur d'un stagiaire.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: backup ?

      Posté par oau le 25 décembre 2023 à 18:47. Évalué à 2. Dernière modification le 25 décembre 2023 à 18:47.

      

      hello

      dans les 3/4 des clients dont je fais la prod, qui sont des pme on va dire avec une grosse douzaine de dev qui font les choix technique parce qu'en vrai il n'y a que des dev dans ces boites. Et la plupart pour pas dire la totalité sont des jeunes prestas de 25ans qui ne sont que de passage. Alors est ce que c'est maintenable ? Ce n'est pas la question. En vrai plus c'est pourri plus longtemps ils gardent leur mission. Et donc oui c'est mal géré.

      Après j'ai passé pas mal de temps dans des très grosses boites et les problèmes étaient différents mais tout aussi pénible pour moi qui faisait de la prod. Vmware/Windows/apache/mysql ou Vmware/windows/websphere/oracle ? Non debian/python/postgres … J'ai finis pas me faire dégager :) Alors maintenant c'est moi qui comment qu'on fait :)

      • [^] # Re: backup ?

        Posté par barmic 🦦 le 25 décembre 2023 à 18:59. Évalué à 6.

        

        En vrai plus c'est pourri plus longtemps ils gardent leur mission.

        Si ton garagiste fais mal son travail, tu retourne le voir ? J'ai vu plusieurs fois des prestataires se faire sortir voir des ESN complètes se faire dégager. Si tu paie, que ta de la merde et que tu continue à payer, il y a un moment où il faut se poser des questions.

        Tu n'a pas la main, tu n'es pas décideur, ce n'est pas toi qui paie,… mais le problème que tu décris ce n'est pas que les jeunes ne savent plus faire mais qu'on crée un système dans le quel on les mets à des responsabilités qui ne leur correspondent pas encore et qu'on s'en satisfait.

        Ce que tu décris montre un fonctionnement beaucoup plus crétin que ce que tu reproche aux « jeunes ».

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

• # En parlant de base de données...

  Posté par cosmocat le 25 décembre 2023 à 22:37. Évalué à 4.

  

  Une base de données de base de données:

  https://dbdb.io/

• # Retirer un lien

  Posté par GG (site web personnel) le 27 décembre 2023 à 18:56. Évalué à 3.

  

  Est ce qu'un modérateur pourrait retirer le lien qui pointe vers une page parking pour Elassandra ? Ou transformer en non-lien.

  Je ne pense pas que ce soit bien d'avoir un lien vers ce genre de sites, d'autant plus que ça renforce ces pratiques.

  Merci beaucoup

  Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • [^] # Re: Retirer un lien

    Posté par Benoît Sibaud (site web personnel) le 29 décembre 2023 à 09:49. Évalué à 3.

    

    Corrigé, merci.

• # Commentaire supprimé

  Posté par dharshanxx24 le 02 mars 2024 à 06:27. Évalué à -1. Dernière modification le 02 mars 2024 à 09:12.

  

  Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.