Journal Postgresql, un retour d'expérience

Posté par  (site Web personnel) . Licence CC By‑SA.
107
15
mai
2020

Sommaire

Un petit peu de contexte

J'ai rejoint une grande banque asiatique, à Londres, il y a de cela 10 ans, pour travailler sur un de leurs systèmes, une grosse application financière en C++. Quelques années plus tard, les affaires n'ayant pas fonctionné comme prévu, ils décident de se débarrasser de l'équipe à laquelle j'appartenais. Heureusement, une petite institution financière européenne s'est montrée intéressée par le système et l'équipe, et plutôt que je devoir payer des indemnités de licenciement, mon ancien employeur était ravi de se débarrasser de nous à l’œil.

Ça se précise

On me charge de préparer la migration des données. Nous avons 2 bases:

  • Une base IBM DB2, qui contient surtout des données dites statiques, relatives aux produits financiers. Ça change un petit peu, mais pas tant que ça : quelques mises à jour le matin, et ça restera tel quel durant le jour.

  • Une autre base KDB, utilisée comme persistance pour une interface graphique qui affiche les ordres passés durant la journée. On parle de quelques centaines de milliers de changements durant la journée, et à la fin, on efface tout. Pour ceux qui ne connaissent pas KDB, il s'agit d'une base orientée colonnes. C'est très cher, et c'est horriblement moche : son concepteur avait une idée toute personnelle de la lisibilité du code, et a construit sa base de données autour d'un langage hyper concis, le langage q (le bien nommé). L'interface C de q (vous suivez ?) est une horreur Lovecraftienne bourrée de macros de 1 caractère. Mais tout le monde semble persuadé qu'une base SQL ne peut pas tenir les 200 000 transactions à la journée. Bon.

Mon nouvel employeur, lui, travaille avec Oracle, et n'est évidemment pas emballé de débourser une petite fortune pour ces technologies. Nous décidons donc de migrer les bases DB2 et KDB vers une base open source, et une fois arrivés de l'autre côté, de convertir depuis la base open source vers Oracle. Et on verra ce qu'il faut optimiser.

Je me lance donc tout d'abord dans la conversion de la base DB2 vers MySQL. Ouh là quelle catastrophe ! J'espère que les choses ont bien changé depuis, mais MySQL manque cruellement à l'époque de fonctionnalités plutôt basiques. J'ai beaucoup lutté avec les clés étrangères, l'indexage, la création de séquences ou les sous-requêtes.

Tournant en rond, je propose à ma hiérarchie d'utiliser Postgres, qui était plutôt plus touffu en termes de fonctionnalités, et que je connaissais mieux. En effet, ça se passe mieux, et j'ai une belle base qui fonctionne.

Pour KDB, c'est aussi facile, et, surprise (ou pas !), c'est tout aussi efficace.

Finalement, quand nous arrivons chez notre nouvel employeur, l'idée d'une base qui ne leur coûtera pas un rond en licences, pour un projet un peu risqué, leur semble une très bonne idée. Leurs DBAs sont réceptifs et prennent un consultant pendant quelques semaines histoire d'apprendre à installer et administrer une base Postgres. Nous décidons d'utiliser la réplication par envoi de journaux de transactions, afin d'avoir une base primaire dans un datacenter, une base secondaire dans l'autre datacenter, et de pouvoir utiliser la base secondaire pour effectuer des opérations en lecture seule.

Ce type de réplication fonctionne très bien, mais souffre d'un défaut: quand on dit que le secondaire de peut effectuer que des opérations en lecture seule, cela interdit la création de tables temporaires. Or, afin de lire rapidement des sous-ensemble de données, nous utilisons beaucoup une approche qui consiste à créer une table temporaire, y pousser les références des données qui nous intéresse, puis à faire une jointure de la table temporaire avec la table principale pour récupérer les lignes qui vont bien.

Or, nos analystes aimeraient bien étudier les donnés et faire tourner de grosses études qui peuvent prendre plusieurs jours, sans impacter les opérations temps réel. On finit par leur créer une base séparée dans laquelle on copie la base principale toutes les nuits, mais cela invalide les requêtes préparées au moment du rafraîchissement et cause des problèmes.

Finalement, après bien des années, nous changeons d'approche et utilisons les tableaux Postgres pour passer au sein de la procédure stockée la liste des données qui nous intéresse. On peut enfin fournir à nous analystes une autre base répliquée. Tout le monde est content !

Au fur et à mesure des années, la base grossit et devient de plus en plus temps réel, car nous l'utilisons pour la persistance de messages transmis entre les services ou avec l'extérieur. On est maintenant entre 500 et 2000 transactions par seconde. L'autre base, remplacement de KDB, fonctionne également sans accrocs. On finit même par manger un petit peu Oracle : nous recommandons Postgres pour la migration d'une gigantesque base OLAP, utilisée pour sauver tous les messages qui passent par le système (plusieurs millions par jour, quand même). C'est un peu de sport, mais la base fait maintenant plusieurs téraoctets, et reste tout à fait administrable.

Quelques remarques techniques à l'emporte-pièce

  • Postgres fournit une bibliothèque C, la libpq (la bien nommée), qui permet de transférer les données soit en mode texte, soit en mode binaire. Il existe également une bibliothèque C++, libpqxx, qui ne fonctionne qu'en mode texte. Finalement, et malgré les recommandations de se cantonner au mode texte, ce qui a marché le mieux pour nous est de construire une petite bibliothèque lourdement templatée autour de la libpq qui passe toutes les données au format binaire. C'est plus efficace, et beaucoup plus sûr, surtout avec des types plus complexes comme des types date heure et les tableaux. Certes, le format binaire est mal ou pas documenté, et il faut faire parfois du reverse engineering ou aller lire le source pour comprendre comment les tableaux sont envoyés, mais une fois que ça marche, c'est du solide.

  • Postgres est configuré par défaut pour de petites bases, et il nous a fallu pas mal de temps afin de vraiment comprendre quels paramètres changer pour obtenir la performance désirée avec nos volumétries. En particulier, nous avons clairement trop longtemps sous-dimensionné les autovacuum, qui sont les jobs de maintenance des tables. Sur de grosses bases, avec de gros serveurs avec des dizaines de CPU, des centaines de Go de RAM, et une baie de SSD derrière, il ne faut pas hésiter à rendre l'autovacuum bien plus agressif.

  • Les types tableaux de Postgres sont vraiment magiques. Ne pas en abuser, car cela casse le modèle relationnel, et l'on peut regretter plus tard de ne pas pouvoir l'indexer, mais parfois, cela permet de beaucoup se simplifier la vie.

  • Enfin, ce qui est vraiment plaisant, avec Postgres, c'est la cohérence du système, le fait que la base semble faite d'abord pour l'utilisateur:

    • Les changements de schéma sont transactionnels, pour de vrai, pour n'importe quel changement de schéma, et ça, il n'y en a pas beaucoup d'autres qui le font. Cela rend les mises à jour faciles et plaisantes: on lance le script, si on s'est trompé et qu'il s'interrompt avec une erreur, le rollback est complet, on a pas besoin de bidouiller à la main pour rattraper le coup.
    • Le type text est limité à un confortable 2Go, et marche exactement de la même manière que n'importe quel autre type. Par rapport aux autres bases qui donnent des limites ridiculement basses à leurs types texte et qui nous forcent à utiliser une structure différente genre blob ou bigtext, qui évidemment se gère différemment dans l'API C, ou ne peut pas s'indexer, ou ne peut pas faire partie de la clé primaire, ou que sais-je encore, quel bol d'air !

Quelques remarques non techniques, tout autant à l'emporte pièce

Postgres nous a donné des résultats incroyables parce que c'est une application d'une qualité rare, mais également parce que nous avons eu le soutien de notre hiérarchie et de l'équipe d'infrastructure, de vrais pros, enthousiastes à l'idée d'essayer quelque chose de nouveau, mais sans naïveté par rapport aux attentes et à l'effort à fournir : nous avons payé des consultants, nous avons pris un contrat de support chez un fournisseur tiers, les serveurs ont été correctement dimensionnés.

J'ai aussi fait attention à ne jamais forcer la main de qui que ce soit : j'ai fourni des prototypes, j'ai tenté de montrer les bons côtés de la solution open source, sans cacher les difficultés, et je ne me suis pas braqué lorsque les décisions sont allées à l'opposé de ce que je proposais. On s'est tous fait confiance, et ça s'est bien passé.

  • # Participation

    Posté par  (site Web personnel) . Évalué à 10 (+18/-0).

    Il faut aussi que les entreprises se rendent compte qu'un tel produit doit continuer d'évoluer et de s'adapter. Si la licence ne coûte rien, cela peut quand même être une bonne idée de participer au financement. Il faut bien imaginer que les développeurs (au sens large) ont besoin de manger tous les soirs.

  • # Actif Actif, multimaster, bi site?

    Posté par  (site Web personnel) . Évalué à 8 (+5/-0).

    J'adore postgresql, mais aujourd'hui la principale limitation est de ne pas pouvoir le déployer Actif Actif, multimaster et bi site.

    On se retrouve pour beaucoup de projet à utiliser Mysql + Gallera (mouaif) ou Oracle RAC (beurk).

    Pour des besoins très simple, on fait aussi du Cassandra ou du S3 comme bases poubelles de données, mais c'est pas top.

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Actif Actif, multimaster, bi site?

      Posté par  . Évalué à 5 (+2/-0).

      J'adore postgresql, mais aujourd'hui la principale limitation est de ne pas pouvoir le déployer Actif Actif, multimaster et bi site.

      Il me semble qu'avec pgpoolII (par exemple), il y a moyen de faire ça.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Actif Actif, multimaster, bi site?

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      Était-ce pour maintenir la haute disponibilité de la base ?

      Notre système a été construit de façon à ne jamais avoir la base sur le chemin critique. Si le primaire tombe, les données à persister s'accumulent en mémoire jusqu'à ce que le secondaire reprenne la main, et nous changeons suffisamment en cache le matin pour pouvoir survivre quelques minutes le temps que les DBAs fassent la bascule.

      Mais d'autres systèmes n'auront pas la même tolérance aux pannes…

    • [^] # Re: Actif Actif, multimaster, bi site?

      Posté par  . Évalué à 4 (+3/-0).

      http://bdr-project.org/docs/stable/ pour le multimaster ? Rien que dans le tronc de base de PG chaque release apporte son lot de nouveautés sur la replication et le clustering

    • [^] # Re: Actif Actif, multimaster, bi site?

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      Regarde du côté de Patroni.

    • [^] # Re: Actif Actif, multimaster, bi site?

      Posté par  . Évalué à 5 (+2/-0).

      Question bête mais les techniques "pro habituelles" que l'on trouve dans les SAN ou iSCSI qui dupliquent les serveurs d'écritures, est-ce que cela fonctionne ?

      J'ai vu que iSER avec ethernet sans perte devenait une norme commune avec les vitesses de 25 et 100 Gbits. En théorie, on doit pouvoir mettre 2 serveurs différents pour une seul base, non ? (certains utilisent même 2 datacenters pour ne rien perdre)

      De toute façon, j'ai du mal à croire qu'une base de données relationnelles actif-actif puissent garantir grand chose sans tomber en panne tout le temps. Le site https://jepsen.io/ test les bases de données distribué (gros testes, sur plusieurs mois). Seul Zookeeper (kafka) et etcd (kubernetes) offrent des garanties fortes. Les autres bases souffrent beaucoup des tests.

      "La première sécurité est la liberté"

  • # C'est gratuit, c'est pas bien

    Posté par  . Évalué à 10 (+15/-0).

    Derrière le titre agressif de ce commentaire se cache cette réalité, qui change, mais qui est toujours présente : si c'est gratuit, c'est que c'est moins bien.

    PostgreSQL est un excellent logiciel, qui fait très bien son travail. Bien sûr, il y a tellement de cas d'utilisation que la configuration ne peut pas être la même pour tout le monde, et ça requiert parfois une personne à plein temps. C'est mieux que Oracle qui requiert plusieurs consultants et le prix de la licence (oui, oui, j'exagère). Très souvent, PostgreSQL couvre le besoin, sans problème.

    J'ai eu la même chose avec SQLite. J'ai dû convaincre des gens que ça pouvaient gérer des grosses bases de données, de manière solide. C'est dans le domaine public, et j'ai des bases de données (simples) de 12 Go qui tourne bien sur un Intel Atom.

    Bref, beaucoup de gens en sont convaincus ici, mais des fois, il faut le rappeler.

    Dans mon équipe, on en a même fait un proverbe : « C'est mieux, mais c'est moins cher. »

    • [^] # Re: C'est gratuit, c'est pas bien

      Posté par  . Évalué à 10 (+9/-1).

      Un point qu'il ne faut pas négliger, c'est le parachute du support. Quand tu paye une licence, tu as du support derrière1. Du coup, tu peux te décharger du problème ailleurs. Ta prod est down pendant 4 jours, ce n'est pas grave, c'est la faute du support que tu as payé. Et du support, ça reste cher à fournir à petite échelle, donc tu n'es pas forcément compétitif sur ce point.


      1. même quand tu n'en as pas, certains le crois quand même et préfère payer. 

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: C'est gratuit, c'est pas bien

        Posté par  . Évalué à 10 (+8/-0).

        La licence, c'est le truc où il y a écrit qu'on ne te garantie rien. Le support, c'est autre chose.

        • [^] # Re: C'est gratuit, c'est pas bien

          Posté par  . Évalué à 6 (+3/-0).

          Relis mon commentaire. C'est souvent inclus ensemble donc ça rassure.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: C'est gratuit, c'est pas bien

            Posté par  . Évalué à 10 (+9/-0).

            Et le support de ta grosse appli propriétaire qui t'explique que non, rien ne sera fait car ton installation diffère d'un pouillième de celle recommandée.

            L'aigritude me gagne quand je pense au gouffre financier (consultants, licences, supports, devs spécifiques pour tous les outils tiers) qu'impose l'usage d'une base pour décideurs pressés pendant que tu regardes une requête SQL simple prendre une heure là où avec postgresql je commencais à m'inquiéter lorsque ça atteignais une minute. Et je ne parle pas de la plaie qu'est le PL/SQL, la pauvreté des types dispo, la différence de transactionnel entre le DDL et le DML, etc.

            • [^] # Re: C'est gratuit, c'est pas bien

              Posté par  . Évalué à 9 (+6/-0).

              Et le support de ta grosse appli propriétaire qui t'explique que non, rien ne sera fait car ton installation diffère d'un pouillième de celle recommandée.

              Entièrement d'accord. D'ailleurs, même un bon support, le temps que tu lui explique ton problème, ta prod n'est pas réparée, si tu n'as pas les compétences en interne pour un workaround.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: C'est gratuit, c'est pas bien

              Posté par  . Évalué à 2 (+0/-0).

              Et le support de ta grosse appli propriétaire qui t'explique que non, rien ne sera fait car ton installation diffère d'un pouillième de celle recommandée.

              Il faut updater en version x.x.x.1b monsieur le client. Oui, en prod, sinon, on ne supporte plus.

          • [^] # Re: C'est gratuit, c'est pas bien

            Posté par  . Évalué à 6 (+4/-0).

            C'est souvent inclus ensemble donc ça rassure.

            Bah désolé, mais si je veux du support, je choisis pas une licence payante parce que si j'ai un peu de bol, j'aurais du support.

            Si le soft est gratuit, je prends du support à côté. Si le soft est payant, je regarde si le support est inclus, sinon, je prends du support à côté.

            Alors, le soft payant peut être finalement plus intéressant support compris, je dis pas. Mais ça n'a pas de sens de se focaliser uniquement sur la licence si c'est le support qui t'intéresse.

            • [^] # Re: C'est gratuit, c'est pas bien

              Posté par  . Évalué à 10 (+11/-0).

              Bah désolé, mais si je veux du support, je choisis pas une licence payante parce que si j'ai un peu de bol, j'aurais du support.

              Je suis désolé de te l'apprendre, mais tu n'es pas mûr pour être décideur pressé.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: C'est gratuit, c'est pas bien

              Posté par  . Évalué à 9 (+7/-0).

              Je crois que ce qu'il sous-entendait, c'est qu'en général quand un logiciel a une licence payante son éditeur propose aussi un support (avec ou sans contrat séparé on s'en branle) et que ce support est donc souvent assuré par ledit éditeur du logiciel ou un partenaire ce qui en théorie assurerait une certaine garantie sur la qualité de support.

              Alors que dans le cas de logiciels gratuis, libre ou non, les dev upstream ne proposent pas forcément du support, ou alors "à bien plaire" et qu'en dehors du bouche à oreille il est souvent difficile de juger du savoir faire des entreprises tierces qui proposent du support pour les-dits logiciels.

              Des fois tu engages une société pour du consulting et du support sur un soft ou une technologie que tu veux déployer et tu te rends comptes une fois "l'ingénieur" sur site qu'en lisant la documentation tu en sais déjà plus que le mec que tu payes très cher pour t'aider. Tu comprends vite qu'en fait il a été engagé pour cette mission sans même avoir fait une formation, ou alors juste 5 jours sans aucune expérience de mis en prod. Ce qui est curieux c'est que malgré ce genre d'expérience et avoir remonté la chose à la hiérarchie, ladite hiérarchie continue parfois à engager les mêmes sociétés sur d'autres projets au lieu de les bannir purement et simplement de leur carnet d'adresse. Copinage? Pot de vin ?

              • [^] # Re: C'est gratuit, c'est pas bien

                Posté par  . Évalué à 3 (+2/-0).

                Copinage? Pot de vin ?

                « Ne jamais attribuer à la malveillance ce que la bêtise suffit à expliquer ».
                Je trouve le rasoir d'Hanlon (ou de Heinlein, allez savoir) souvent facile à appliquer, avec les décideurs pressés…

  • # Mysql a(vait) du retard. Est-ce toujours le cas ?

    Posté par  . Évalué à 5 (+3/-0).

    Je me lance donc tout d'abord dans la conversion de la base DB2 vers MySQL. Ouh là quelle catastrophe ! J'espère que les choses ont bien changé depuis, mais MySQL manque cruellement à l'époque de fonctionnalités plutôt basiques. J'ai beaucoup lutté avec les clés étrangères, l'indexage, la création de séquences ou les sous-requêtes.

    Tu pourrais développer ? Quels problèmes avais-tu rencontrés ? Et sais-tu si ces retards de MySQL sont toujours d'actualité ?

    • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

      Posté par  (site Web personnel) . Évalué à 10 (+9/-0).

      Les restrictions au niveau des sous-requêtes semblent encore d'actualité. Il me semble avoir été mordu soit par le problème des sous-requêtes référençant une table en écriture, soit par la restriction sur les requêtes corrélées (avant la version 8.0.14).

      La taille maximum d'une ligne est de 64Ko, et donc un varchar ne pourra pas aller au delà. Pour y mettre du texte plus gros, il est possible d'utiliser les types BLOB et TEXT, qui ont certaines restrictions, et qui se chargent différemment d'un varchar dans l'API ODBC.

      MySQL ne connait pas le "CREATE SEQUENCE". L'on peut avoir des colonnes auto-incrémentées, mais on perd le côté universel de la séquence.

      J'ai également cru comprendre que le planificateur de requêtes de MySQL s’essouffle bien plus rapidement lorsque le nombre de jointures et la complexité des requêtes augmentent, mais je n'ai pas de benchmark sous la main.

      Aucune de ces restrictions n'est complètement bloquante et l'on peut toujours émuler quelque chose, mais le schéma que je migrais était complexe, et Postgres était simplement un outil plus adapté à mon problème.

    • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

      Posté par  (site Web personnel) . Évalué à 10 (+9/-0).

      MySQL (et MariaDB aussi) souffre malheureusement de beaucoup de défauts, qui font que, pour des applications "critiques" (=données importantes), c'est un choix que j'élimine d'office.

      MySQL est encore très sensible aux coupures brutales qui peuvent entrainer des corruptions de données (alors qu'un bon SGBD comme Postgresql ou SQL Server (pas tapper) gère cela tout seul).

      MySQL ne connait pas la notion de schéma. Syntaxiquement oui, mais en fait, c'est une base de données. Cela peut générer quelques surprises lors de la création de clé étrangères entre schémas différents.

      La sauvegarde est du coup, complexe. Pour sauvegarder une base de données, il faut sauvegarder TOUTES les bases de données, au même instant pour assurer la cohérence. Difficile à réaliser, surtout à chaud et sans blocage !

      La syntaxe SQL laisse aussi parfois à désirer. Un SELECT avec GROUP BY et une colonne qui n'apparait pas dans la clause GROUP BY est acceptée sans broncher tandis que tous les autres SGBD refuse catégoriquement en l'absence d'une fonction d'aggrégation.

      Au delà de quelques jointures, les performances ne sont en général pas vraiment au rendez-vous comparer à Postgres.

      Et les changements de version (même mineure !) qui introduisent des changements de comportement, il faut avouer que ce n'est pas top non plus ! On a la possibilité de changer les choses en trouvant les bonnes variables etc, mais ce n'est pas toujours fait automatiquement.

      Enfin, il n'est pas vraiment relationnel. Un SGBD relationel doit être ensembliste. Or, la vérification des contraintes, lors d'un UPDATE par exemple, est séquentielle (UPDATE matable SET id = id + 1, où id est une clé unique ne passe pas avec une violation de contrainte d'unicité).

      Et il y a encore pleins de raisons, mais ce sont les seuls qui me reviennent à l'esprit pour l'instant ^

      Après, est-ce que cela veut dire qu'il ne faut pas l'utiliser ? Non. L'avantage de MySQL est qu'il reste répandu et léger. Donc pour de simple besoin (blog, site, etc…) où les données ne sont pas crucial, il n'y a aucun problème à l'utiliser (PS : je l'utilise pour mon site xD)

      • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

        Posté par  . Évalué à 2 (+2/-2). Dernière modification le 16/05/20 à 15:37.

        Après, est-ce que cela veut dire qu'il ne faut pas l'utiliser ? Non. L'avantage de MySQL est qu'il reste répandu et léger. Donc pour de simple besoin (blog, site, etc…) où les données ne sont pas crucial, il n'y a aucun problème à l'utiliser (PS : je l'utilise pour mon site xD)

        Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

        • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

          Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

          Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

          Attention, les deux ne répondent pas aux mêmes besoins ! L'un est un SGBD (enfin prétend l'être, troll inside xD), l'autre est de la mouvance NoSQL (orienté document).

          Au passage, je suis aller voir sur le site de mongodb. La traduction française est, comment dire…

          En tant que programmateur, vous réfléchissez en termes d'objet. Désormais, il en va de même pour votre base de données.

          MongoDB est base de données de documents, ce qui signifie qu'elle stocke les données au format de documents JSON. Nous estimons qu'il s'agit de la façon la plus naturelle d'envisager les données, bien plus efficace et expressive que le modèle traditionnel basé sur des rangées et des colonnes.

          Ce qu'il ne faut pas lire :/ Tout dépend des usages ! Mais bon, la je disgresse xD

          • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

            Posté par  . Évalué à 0 (+0/-2).

            Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

            Attention, les deux ne répondent pas aux mêmes besoins ! L'un est un SGBD (enfin prétend l'être, troll inside xD), l'autre est de la mouvance NoSQL (orienté document).

            C'est une dichotomie, mais il y en a d'autres. Grosso modo l'impression que me donne ton commentaire c'est : quand tu as peu de contraintes MySQL peut faire le job, mais dans ce genre de cas ça peut être intéressant d'élargir son spectre. Et d'aller voir potentiellement vers ce qui n'est pas du SQL ou d'autres bases SQL.

            En particulier une base de données qui est sujette à corruption des données comme le semble l'indiquer ton commentaire. Même si je me doute que c'est des cas rares pathologiques etc. Ça baisse fortement les chances que je me tourne vers elle :)

            Mongo est une base extrêmement flexible qui supporte des transactions. Il est très agréable à utiliser. Ce qui va le distinguer de MySQL ça va être le fait qu'il est sans schéma. Mais si ton taff c'est d'utiliser un ORM et de pas faire de requêtes trop complexes, ce qui me semble être le cas d'usage que tu dépeins. Il peut être une très bonne alternative.

            Ce qu'il ne faut pas lire :/ Tout dépend des usages ! Mais bon, la je disgresse xD

            Je te trouve très rude.

            1. C'est assez ironique de leur reprocher leur vocabulaire pour développeur dans une phrase dans la quelle tu utilise un verbe qui n'existe pas…
            2. La citation que tu pointe est très humble ils expliquent que c'est leur point de vu. C'est plutôt pas mal de croire en ce qu'on fait en tant dans le développeur d'un projet. Je pense que leur présent est un présent de vérité général ils pensent qu'en général c'est le cas. C'est discutable bien sûr mais le tourner en ridicule, je ne pense pas que ça en vaille la peine.

            Si tu veux baver sur mongo, des citations du patron de la boite qui est derrière seront bien plus pertinentes.

            • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

              Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

              En particulier une base de données qui est sujette à corruption des données comme le semble l'indiquer ton commentaire. Même si je me doute que c'est des cas rares pathologiques etc. Ça baisse fortement les chances que je me tourne vers elle :)

              Une simple recherche sur un moteur de recherche et tu pourras avoir pas mal de retour là-dessus ;)

              Mongo est une base extrêmement flexible qui supporte des transactions. Il est très agréable à utiliser. Ce qui va le distinguer de MySQL ça va être le fait qu'il est sans schéma. Mais si ton taff c'est d'utiliser un ORM et de pas faire de requêtes trop complexes, ce qui me semble être le cas d'usage que tu dépeins. Il peut être une très bonne alternative.

              Je ne dépeins aucun cas d'usage. Je fais juste remarquer que proposer MongoDB comme alternative à MySQL, c'est comme proposer une moto en remplacement d'une voiture : ça peut le faire, ça peut convenir pour certains cas, mais pas pour d'autre !

              Un SGBD est ACID. Une base NoSQL non (les bonnes performances obtenues par ce type de base est justement obtenues en relaxant au moins une des propriétés ACID).

              De plus, un SGBD permet de s'assurer de beaucoup choses et ne se limite pas, et de loin, aux transactions. Il y a les contraintes d'intégrités (foreign key, check contraint, etc…), les fonctions et procédures stockées, les triggers, les vues, une gestion des droits fines, etc… et sans oublier la possibilité de faire des requêtes très complexes si besoin est !

              Dès lors, proposer l'un pour l'autre sans connaitre le contexte d'utilisation derrière est juste… impossible.

              Et mon taf, c'est justement de ne pas utiliser un ORM, mais de travailler sur la modélisation de la base de données, avec les bonnes contraintes pour assurer au maximum la cohérence des données directement par le SGBD, avec les "bonnes tables", index, partitionnement, etc… pour assurer de bonnes performances et des temps de réponse très restreint.

              Je te trouve très rude.

              Je suis désolé, mais s'adresser à des développeurs en les nommant "programmateur", c'est une énorme erreur qui peut faire perdre toute crédibilité (à noter qu'ici, le problème est uniquement dans la traduction française, mais j'ai trouvé ça "coquet").

              De plus, quand je lis ceci :

              Nous estimons qu'il s'agit de la façon la plus naturelle d'envisager les données, bien plus efficace et expressive que le modèle traditionnel basé sur des rangées et des colonnes.

              Ce que je comprends, c'est que le modèle "rangées et colonnes" est dépassé (et donc, de facto le modèle des SGBD) mais NOUS nous avons la solution ultime. Ben je suis désolé, c'est des conneries de "markéteux".

              Si tu veux baver sur mongo, des citations du patron de la boite qui est derrière seront bien plus pertinentes.

              Je n'ai aucune raison de "baver" sur MongoDB. Tu noteras d'ailleurs que je n'ai rien dit du point de vue technique, car, à ma connaissance, c'est une bonne techno (pas eu l'occasion de l'employer jusqu'à présent sur des projets, mais les retours que j'en ai sont plus que positifs).

              J'ai bien précisé dans mon commentaire que ce qui était en cause, c'était "la traduction française".

              • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                Posté par  . Évalué à -2 (+0/-4).

                Dès lors, proposer l'un pour l'autre sans connaitre le contexte d'utilisation derrière est juste… impossible.

                L'objet de mon premier commentaire c'est que d'après ce que tu dis MySQL a du mal avec les propriétés ACID en particulier avec la durabilité. Il est donc logique de commencer à regarder du coté des bases qui sans se venter d'être ACID cherchent à s'en rapprocher. Mais surtout, dès le départ j'ai dis explicitement que ce n'était pas une règle générale.

                Je vais le dire plus simplement du coup. Je en dis pas :

                Mongo déboite MySQL

                mais

                Vu les souci que semble avec MySQL, Mongo est un concurrent serieux dans certains contexte.

                J'ai bien indiqué dès le début que ça dépendait des cas.

                Je suis désolé, mais s'adresser à des développeurs en les nommant "programmateur", c'est une énorme erreur qui peut faire perdre toute crédibilité (à noter qu'ici, le problème est uniquement dans la traduction française, mais j'ai trouvé ça "coquet").

                Pointer ça tout en faisant une grosse faute de français est au moins aussi "coquet".

                Ce que je comprends, c'est que le modèle "rangées et colonnes" est dépassé (et donc, de facto le modèle des SGBD) mais NOUS nous avons la solution ultime. Ben je suis désolé, c'est des conneries de "markéteux".

                Il indique clairement que c'est leur point de vu. Les gens croient en leur projet c'est normal. Leur faire un procès d'intention pour cela c'est très dommageable. Regarde pijul tu peux difficilement les taxer de "markéteux", c'est juste leur point de vu. Tout point de vu est critiquable. C'est dommage de placer ça juste pour dénigrer. D'autant que leur job c'est de faire cette base, qu'ils croient une chose ou une autre sur les autres systèmes de stockage n'est pas très important par rapport au travail qu'ils font.

                Je n'ai aucune raison de "baver" sur MongoDB. Tu noteras d'ailleurs que je n'ai rien dit du point de vue technique,[…]

                Quel est l’objectif de les dénigrer du coup ?

                […] car, à ma connaissance, c'est une bonne techno (pas eu l'occasion de l'employer jusqu'à présent sur des projets, mais les retours que j'en ai sont plus que positifs).

                Ouai il a tout de même un paquet de défauts quand tu le pousse un peu.

                • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                  Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                  L'objet de mon premier commentaire c'est que d'après ce que tu dis MySQL a du mal avec les propriétés ACID en particulier avec la durabilité. Il est donc logique de commencer à regarder du coté des bases qui sans se venter d'être ACID cherchent à s'en rapprocher. Mais surtout, dès le départ j'ai dis explicitement que ce n'était pas une règle générale.

                  Et bien dans ce cas, on compare ce qui est comparable, et on oriente vers du psotgresql, du sqlite, du oracle, du SQL Server, etc…

                  Pointer ça tout en faisant une grosse faute de français est au moins aussi "coquet".

                  J'ai fait une faute de frappe. Et ? D'autant que le néologisme employé existe. La différence, c'est que je n'ai rien à vendre. Décrédibilise mon commentaire sur ce point si cela te chante, cela n'empêche pas que confondre programmateur/programmeur quand on s'adresse à des programmeurs, ça fait mal.

                  Il indique clairement que c'est leur point de vu. Les gens croient en leur projet c'est normal. Leur faire un procès d'intention pour cela c'est très dommageable.

                  Ce n'est pas un procès d'intention. C'est juste du bon sens.

                  Nous estimons qu'il s'agit de la façon la plus naturelle d'envisager les données,

                  Ca, c'est un point de vue.

                  la façon la plus naturelle d'envisager les données, bien plus efficace et expressive que le modèle traditionnel basé sur des rangées et des colonnes.

                  Ca, c'est de la connerie. J'attends de voir sur quels critères ils se basent pour dire que c'est plus efficace et plus expressif. Prenons juste le côté expressif. Je peux te sortir des requêtes SQL que tu ne pourras pas exprimer avec MongoDB. Donc oui, c'est de la foutaise.

                  Un MySQL te poutre les perf en lecture par rapport à MongoDB. A l'inverse, MongoDB poutre MySQL pour les écritures (normal, propriétés ACID relachées !). Donc dire que c'est plus efficace, sans contexte, c'est "n'importe quoi".

                  Quel est l’objectif de les dénigrer du coup ?

                  Mais d'où je les dénigres ? Comme déjà dit, je dénigrecritique la traduction (et le marketing à 2 balles)

                  Je critique aussi ton choix de proposer MongoDB en tant que remplacement pour MySQL car ils ne répondent pas au même besoin. Mais à aucun moment, je n'ai dénigré (pour reprendre tes propos) MongoDB.

                  • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                    Posté par  . Évalué à 1 (+1/-2).

                    Je critique aussi ton choix de proposer MongoDB en tant que remplacement pour MySQL car ils ne répondent pas au même besoin. Mais à aucun moment, je n'ai dénigré (pour reprendre tes propos) MongoDB.

                    Ce n'est pas comme ça que je travaille. Le besoin pour moi lorsque l'on construit un logiciel ce n'est pas "avoir une base de données SQL" (sauf bien sûr dans des certains contexte), mais "j'ai besoin de stocker de la donnée" et il y a une pluralité de réponse à cette question. Quand on se pose la question de cette façon sans présupposé sur la réponse technique, on ne segmente pas autant que ce que tu semble faire. Et moins on a de contraintes plus le champs des possibles est ouvert. Au contraire que plus tu as de contrainte moins tu aura de solution.

                    Pg et mongo sont pour moi les 2 bases qui sont les meilleures solutions quand tu es peu contraint. Ils ballaient un très large champs de besoin fonctionnel. Pg allant jusqu'à marcher sur les platebandes de ce qu'on appellerait NoSQL (le type json n'est pas 3NF) et mongo allant lui aussi taquiner des choses que l'on trouve d'habitude chez les SQL (avec des transactions).

                    • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                      Ce n'est pas comme ça que je travaille. Le besoin pour moi lorsque l'on construit un logiciel ce n'est pas "avoir une base de données SQL" (sauf bien sûr dans des certains contexte), mais "j'ai besoin de stocker de la donnée" et il y a une pluralité de réponse à cette question.

                      Je suis entièrement d'accord avec toi sur ce point. C'est d'ailleurs comme ça que je travaille. D'ailleurs, quand un client me dit qu'il lui faut telle solution technologique précise, je lui demande d'exprimer son souhait en terme de besoin.

                      Ce qui ne veut pas dire que je ne vais pas tenir compte de son avis. Il y a des cas où c'est légitime. Par exemple, utiliser Postgresql car ils l'utilisent déjà pour d'autres appli (pour favoriser une trop certaine homogénéité).

                      Quand on se pose la question de cette façon sans présupposé sur la réponse technique, on ne segmente pas autant que ce que tu semble faire.

                      Mais comment sais-tu comment je travaille ? Tu proposes MongoDB en remplacement de MySQL, je te dis que proposer une BD NoSQL pour remplacer un SGBD ne marche pas à tous les coups et que cela dépend fortement des cas d'usage (besoins !), et tu es capable de me dire l'âge du capitaine ? Niveau "supposition", je pense que tu fais fort !

                      • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                        Posté par  . Évalué à 0 (+0/-2).

                        Je suis entièrement d'accord avec toi sur ce point.

                        Donc pourquoi être aussi catégorique au dessus pour dire qu'il faut proposer un SGBDR uniquement et que ça n'a pas de sens de parler des NoSQL?

                        Mais comment sais-tu comment je travaille ? Tu proposes MongoDB en remplacement de MySQL, je te dis que proposer une BD NoSQL pour remplacer un SGBD ne marche pas à tous les coups et que cela dépend fortement des cas d'usage (besoins !), et tu es capable de me dire l'âge du capitaine ? Niveau "supposition", je pense que tu fais fort !

                        Tu t'es lancé dans une tirade avant même d'avoir véritablement lu mon premier commentaire. J'ai bien dis que ça dépendait des cas. Je l'ai dis clairement dès mon premier commentaire. Tu t'es lancé dans un long commentaire pour t'en offusquer sans chercher à comprendre ma phrase. Ce genre de réaction donne forcément des impressions.

                        • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                          Donc pourquoi être aussi catégorique au dessus pour dire qu'il faut proposer un SGBDR uniquement et que ça n'a pas de sens de parler des NoSQL?

                          Voici la réponse initiale à ton commentaire :

                          Attention, les deux ne répondent pas aux mêmes besoins ! L'un est un SGBD (enfin prétend l'être, troll inside xD), l'autre est de la mouvance NoSQL (orienté document).

                          Où suis-je catégorique ? Je n'ai fais que préciser que les deux ne répondaient pas au même besoin !

                          Tu t'es lancé dans une tirade avant même d'avoir véritablement lu mon premier commentaire.

                          Celui qui dit que tu proposes MongoDB alors que ne connais pas bien MySQL ? J'ai apporté une précision qui m'a semblé "utile".

                          Tu t'es lancé dans un long commentaire pour t'en offusquer sans chercher à comprendre ma phrase. Ce genre de réaction donne forcément des impressions.

                          Dis celui qui n'a pas arrêté de dire que je dénigrais MongoDB car il n'avait pas chercher à comprendre mes commentaires…

                          Bon, c'est "rigolo" ce genre de discussion, mais je m'arrête là. Autre chose à faire devant tant de mauvaise foi.

                          Bonne continuation.

                        • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

                          Posté par  . Évalué à 2 (+1/-1).

                          C'est clair que pour faire tourner un blog une SGBDR est un peu overkill.

            • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

              Posté par  (site Web personnel) . Évalué à 5 (+2/-0).

              Mongodb c'est bien, mais la licence refoule du derrière.

              Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

        Posté par  . Évalué à 3 (+1/-0).

        Merci pour vos réponses, small_duck et toi.

        Concernant ce point :

        Un SELECT avec GROUP BY et une colonne qui n'apparait pas dans la clause GROUP BY est acceptée sans broncher tandis que tous les autres SGBD refuse catégoriquement en l'absence d'une fonction d'aggrégation.

        Ça n'est plus vrai. MySQL râle désormais, avec le message suivant : ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'mydb.t.address' which is not functionally dependent on columns in GROUP BY clause; this
        is incompatible with sql_mode=only_full_group_by

        Apparemment, c'est apparu dans la version 5.7.5

      • [^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?

        Posté par  . Évalué à 1 (+1/-0).

        Il me semble depuis la version 5.7, il y a le mode strict qui permet de forcer une meilleure vérification des contraintes.

        Enfin, il n'est pas vraiment relationnel. Un SGBD relationel doit être ensembliste. Or, la vérification des contraintes, lors d'un UPDATE par exemple, est séquentielle (UPDATE matable SET id = id + 1, où id est une clé unique ne passe pas avec une violation de contrainte d'unicité).

        As-tu essayé avec postgresql ? Tu serai bien surpris! car j'ai bien un exemple qui montre que PG en est incapable!

  • # Participation

    Posté par  . Évalué à 6 (+5/-1).

    Certes, le format binaire est mal ou pas documenté, et il faut faire parfois du reverse engineering ou aller lire le source pour comprendre comment les tableaux sont envoyés

    Super, avez-vous mis à la jour la documentation afin de 1) documenter VOTRE système, 2) que cela participe à l'effort d'un bon produit libre?

    • [^] # Re: Participation

      Posté par  (site Web personnel) . Évalué à 8 (+6/-0). Dernière modification le 18/05/20 à 01:04.

      Malheureusement, c'est une question que nous ne nous sommes pas du tout posés, avec des développeurs Postgres moyen chauds quand ça commence à parler format binaire dans les mailing lists, et la difficulté de convaincre le n+3 de faire sortir de la boite quoi que ce soit.

      Pour la documentation interne, nous avons les commentaires dans le code, et des tests unitaires (le Test Driven Developement dit que les tests sont la spec, non?).

      Pour la participation au produit, nous avons pris un contrat support auprès d'une entreprise qui emploie de nombreux développeurs Postgres. Vu la solidité du produit, et nos DBAs plutôt dégourdis, on ne les a pas noyés sous les questions ou les problèmes, et j'ai donc espoir qu'une large partie de la facture soit partie dans l'amélioration de Postgres pour tout le monde.

  • # Quelques erreurs !

    Posté par  . Évalué à -1 (+1/-2).

    Vous dites beaucoup de choses fausses… je vous cite :
    "
    Les changements de schéma sont transactionnels, pour de vrai, pour n'importe quel changement de schéma, et ça, il n'y en a pas beaucoup d'autres qui le font.
    "
    Depuis toujours IBM DB2, Microsoft SQL Sevrer, Oracle Database, Sybase Adaptive Server, Sybase Enterprise Server… font cela et depuis plus de 20 ans.
    Le seul SGBD qui ne le fait pas est MySQL/MariaDB
    Donc, contrarement à vos dire, la plupart des GBDR le font…

    Vous dites :
    "
    Le type text est limité à un confortable 2Go, et marche exactement de la même manière que n'importe quel autre type. Par rapport aux autres bases qui donnent des limites ridiculement basses à leurs types texte et qui nous forcent à utiliser une structure différente genre blob ou bigtext, qui évidemment se gère différemment dans l'API C, ou ne peut pas s'indexer…
    "
    Contrairement à ce que vous laissez entendre, vous ne pouvez pas indexer un type "text" de PostGreSQL de n'importe quelle longueur. C'est d'ailleurs un véritable piège à con. Démonstration :

    CREATE TABLE TBLOBTEXT (ID INT PRIMARY KEY, DATA TEXT)
    INSERT INTO TBLOBTEXT VALUES (2, REPEAT('toto', 200000))
    CREATE INDEX X ON TBLOBTEXT (DATA)
    ==> ERROR: ERREUR: la ligne index requiert 9184 octets, la taille maximum est 8191

    A +

    • [^] # Re: Quelques erreurs ! ... effectivement :)

      Posté par  . Évalué à 0 (+0/-0).

      Salut SQLpro…

      Après si tu utilises un index b-tree … et penses aussi au "text_pattern_ops" ;) pour du texte…

      L'utilisation avec un autre type d'index avec l'extension pg_trgm le permet sans problème…
      exemple :

      create extension pg_trgm ;
      CREATE INDEX trgm_idx ON TBLOBTEXT USING GIST (data gist_trgm_ops);
      -> CREATE INDEX

      Et cela permet en plus de faire des recherches du type like '%montexte%" en utilisant l'index :)

      Et il en existe un tas ;) un petit résumé :

      • B-Tree - Pour la plupart des types de données et des requêtes
      • GIN - Pour JSONB/hstore/tableaux
      • GiST - Pour la recherche en texte intégral et les types de données géospatiales
      • SP-GiST - Pour des ensembles de données plus importants avec un regroupement naturel mais inégal
      • BRIN - Pour les très grands ensembles de données qui s'alignent de manière séquentielle
      • Hash - Pour les opérations d'égalité, et généralement les même types de données que pour B-Tree

      • Et bien d'autres que les dev peuvent rajouter grâce à l'API permettant leur développement comme des "extensions" (…vodka et d'autres expérimentaux) :)

      Bref utiliser le bon index pour la bonne utilisation et bien sur lire la documentation qui est dispo en français (merci la communauté) !

      Sinon merci small_duck pour ton retour d'expérience :)

      ++

    • [^] # Re: Quelques erreurs !

      Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

      En effet, je ne connaissais pas cette limite sur la taille des index. J'en prends note.

      Pour les changements de schéma transactionnels, je maintiens, mais je précise afin d'éviter les malentendus: par transactionnel, je veux dire qu'il est possible d'effectuer dans une seule transaction plusieurs changements de schéma et de données, et d'avoir un rollback propre en cas d'erreur, ce qui est fort pratique pour faire des mises à jour complexes en toute sérénité.

      Par exemple, Sybase force un commit avant et après un "drop table":

      http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc00170.1540/doc/html/san1283555530313.html

      Ça semble encore pire chez Oracle:

      "Oracle Database implicitly commits the current transaction before and after every DDL statement."

      https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_1001.htm#SQLRF30041

      DB2 me semblait mieux doté sur ce point, mais je me souviens d'avoir du régulièrement séparer mes mises à jour en plusieurs paquets, car certaines opérations devaient se faire en dehors d'une transaction. Je ne retrouve cependant pas de références, et je serai heureux d'en apprendre plus.

Envoyer un commentaire

Suivre le flux des commentaires

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