Sommaire
- Un petit peu de contexte
- Ça se précise
- Quelques remarques techniques à l'emporte-pièce
- Quelques remarques non techniques, tout autant à l'emporte pièce
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 Sytoka Modon (site web personnel) . Évalué à 10.
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.
[^] # Re: Participation
Posté par L'intendant zonard (site web personnel) . Évalué à 1.
A choisir et si on ne peut faire qu'un repas par jour, mieux vaut manger le matin. ->[]
Intendant, donc méchant, mais libre !
# Actif Actif, multimaster, bi site?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
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
basespoubelles de données, mais c'est pas top.Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Actif Actif, multimaster, bi site?
Posté par claudex . Évalué à 5.
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 small_duck (site web personnel) . Évalué à 7.
É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 Jean Roc Morreale . Évalué à 4.
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 Anonyme . Évalué à 4.
Regarde du côté de Patroni.
[^] # Re: Actif Actif, multimaster, bi site?
Posté par oau . Évalué à 1.
Stolon en prod ici depuis 18 mois. Et franchement c'est top.
https://github.com/sorintlab/stolon
Par contre pas de actif/actif pour autant que je sache. En écriture du moins. Les n replica sont accessibles en lecture.
[^] # Re: Actif Actif, multimaster, bi site?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
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 Glandos . Évalué à 10.
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 claudex . Évalué à 10.
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.
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 kna . Évalué à 10.
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 claudex . Évalué à 6.
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 Jean Roc Morreale . Évalué à 10.
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 claudex . Évalué à 9.
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 kowalsky . Évalué à 2.
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 kna . Évalué à 6.
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 claudex . Évalué à 10.
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 Psychofox (Mastodon) . Évalué à 9.
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 Pazns . Évalué à 3.
« 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 windu.2b . Évalué à 5.
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 small_duck (site web personnel) . Évalué à 10.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 16 mai 2020 à 15:37.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par barmic 🦦 . Évalué à 0.
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.
Je te trouve très rude.
Si tu veux baver sur mongo, des citations du patron de la boite qui est derrière seront bien plus pertinentes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par barmic 🦦 . Évalué à -2.
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 :
mais
J'ai bien indiqué dès le début que ça dépendait des cas.
Pointer ça tout en faisant une grosse faute de français est au moins aussi "coquet".
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.
Quel est l’objectif de les dénigrer du coup ?
Ouai il a tout de même un paquet de défauts quand tu le pousse un peu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par barmic 🦦 . Évalué à 1.
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).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par barmic 🦦 . Évalué à 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?
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par Psychofox (Mastodon) . Évalué à 2.
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 Jérôme FIX (site web personnel) . Évalué à 4.
Mongodb
https://docs.opsmanager.mongodb.com/current/tutorial/provisioning-prep/
Pour un simple blog cela commence à faire beaucoup de ressources à allouer à un serveur non ?
Pas sur que mongodb soit très adapté à un simple blog au final :-)
IL vaut peut être mieux rester sur du MySQL, du sqlite ou autre.
Jérôme.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par Psychofox (Mastodon) . Évalué à 2.
je n'ai pas dit non plus que mongo était mieux :-)
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Mongodb c'est bien, mais la licence refoule du derrière.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par windu.2b . Évalué à 3.
Merci pour vos réponses, small_duck et toi.
Concernant ce point :
Ç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; thisis incompatible with sql_mode=only_full_group_by
Apparemment, c'est apparu dans la version 5.7.5
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par HL . Évalué à 3.
Tiens, à la base, pourquoi un
GROUP BYsans agrégation alors qu'il y aSELECT DISTINCT?La question est volontairement naïve, les deux commandes traitent la « même » demande sous deux approches différentes ce qui peut produire dans certains cas particuliers un résultat différent.
A-t-on ces deux commandes pour des raisons historiques, ou ai-je loupé quelque chose ?
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par windu.2b . Évalué à 2.
Le
DISTINCTsert à prendre un seul élément, à chaque fois qu'il y en a plusieurs identiques. Ce que leGROUP BYfait aussi, mais permet en même temps de compter (COUNT(champ) AS cpt) le nombre d'éléments regroupés.[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par windu.2b . Évalué à 2.
J'ai parlé de compter (avec
COUNT(champ)), mais en réalité, ça s'utilise avec n'importe quelle fonction d'aggrégation (AVG,SUM, …).[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par HL . Évalué à 1.
Merci pour la réponse, mais je parlais eh fait de
GROUPsans fonction d'agrégation.[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par windu.2b . Évalué à 2.
Ah !
Pour ma part, je n'ai jamais vu quelqu'un l'utiliser ainsi, dans ce cas…
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par champomy62 . Évalué à 1.
Il me semble depuis la version 5.7, il y a le mode strict qui permet de forcer une meilleure vérification des contraintes.
As-tu essayé avec postgresql ? Tu serai bien surpris! car j'ai bien un exemple qui montre que PG en est incapable!
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par wismerhill . Évalué à 3.
C'est documenté, et il y a un contournement:
https://www.postgresql.org/docs/current/sql-createtable.html#id-1.9.3.85.9.4
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par champomy62 . Évalué à 1.
Je connais les contraintes "DEFERRABLE", mais la théorie relationnelle indique que tu devrai pouvoir le faire sans avoir a déferrer.
Mais bon au moins c'est possible!
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par wismerhill . Évalué à 2.
De fait, c'est pour ça que la remarque que je pointe se trouve dans la section compatibility, c'est une déviation par rapport au standard SQL.
Ils indiquent que les contraintes déférées ont un impact sur les performances, je suppose que c'est pour ça qu'elles ne le sont pas par défaut.
Je dois dire qu'en une dizaine d'années à travailler avec PG, il ne m'est arrivé qu'une fois d'avoir l'usage pour des contraintes déférées (c'était une contrainte d'unicité).
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par champomy62 . Évalué à 1.
Pareil, 7 ans à travailler professionnellement avec PG et jamais eu besoin de déferrer la contrainte.
La plupart du temps, cela arrive quand je m'exerce a faire des requetes.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par Jean Roc Morreale . Évalué à 1.
ça sert lorsqu'on travaille sur des imports de données depuis des systèmes en prod libérés de toutes contraintes de normalisation (pour des questions d'optimisation bien sûr) où tout se fait côté appli, ça permet de migrer en évitant des difficultés dans la reprise des références (pk/fk qui tiennent de l'ordre d'arrivée l’œuf ou la poule, unicité quantique) mais avec la garantie d'intégrité en bout de course (sinon pas de commit).
Les performances ont dans ces cas un impact limité
# Participation
Posté par ckiller . Évalué à 6.
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 small_duck (site web personnel) . Évalué à 8. Dernière modification le 18 mai 2020 à 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 SQLpro . Évalué à -1.
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 ngpe . Évalué à 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é :
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 small_duck (site web personnel) . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.