Journal Cassandra 4 qui la testent, un qui l'Hécube

Posté par  (site Web personnel) . Licence CC By‑SA.
20
4
août
2021

Bonjour Nal,

Je t'écris pour te signaler la sortie de la base de données Apache Cassandra 4.0.

Cette base orientée colonne grecque est devenue l'un des stockages les plus utilisées pour les titanodonnées. Écrite en Java (pour les perfs), elle utilisable via son langage de requête CQL ou via des API dans tous les bons langages mais aussi en Python ou Node.js.

Voici les nouveautés de cette version:

  • le support de Java 11 : c'est important, car il s'agit de la dernière version Long Term Support ;
  • des tables virtuelles (par exemple pour exposer une configuration en CQL) ;
  • des logs plus complets (audit et requêtes) ;
  • beaucoup d'optimisations ;
  • un truc qui s'appelle Transient Replication, je n'ai pas compris ce que s'est, mais mon DBA a dit "super, je suis trop heureux" en l'apprenant.

Et toi Nal, tu as quoi comme base en prod?

  • # Scylla/MongoDB

    Posté par  . Évalué à 9 (+9/-1). Dernière modification le 04/08/21 à 16:43.

    Écrite en Java (pour les perfs)

    Il me semblait que Scylla en avait encore plus (écrit en C++ ;))

    Et toi Nal, tu as quoi comme base en prod?

    MongoDB car j'aime le mode document. Un jour peut-être j'utiliserai du PostgreSQL avec jsonb.

    • [^] # Re: Scylla/MongoDB

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

      Postgres avec les json, faut se méfier un peu quand même.
      Les requêtes sont vachement plus chiantes à écrire, il me semble que les index sont beaucoup plus gros, les foreign keys sont pas possible, et ça risque de te donner un faux sentiment de sécurité “mes données sont structurés”.

      C’est très pratique pour stocker des données arbitraires sur une ligne, mais des que le json doit intervenir dans une requête, ca marche pas aussi bien que ce tu pourrais penser. Si ton idée c’est d’avoir juste une colonne id, et une autre “data” avec tout le json, ca va piquer.

      Une db relationnelle, c’est bien pour faire du relationnel. Si tu cherches à transformer pg en db orienté document, tu vas vite avoir des problèmes.

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

      • [^] # Re: Scylla/MongoDB

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

        C'est pas si sûr, d'après des benchmarks que j'avais lus (d'il y a un an ou deux j'arrive pas à les retrouver) PostgreSQL explose MongoDB en performances brutes quand on l'utilise en mode "document" avec du jsonb.

        En plus avec PostgreSQL tu peux explicitement créer les indexes comme bon te semble, et profiter de toutes ses autres fonctionnalités.

        Donc quant bien même la syntaxe est chiante pour écrire des requêtes qui manipulent le jsonb (elle est vraiment très chiante, je sais de quoi je parle) ça vaut toujours le coup d'évaluer PostgreSQL quand le besoin se pose.

        Surtout qu'avec MongoDB, tu peux pas faire de relationnel le jour où tu dis que "merde, en fait j'en ai besoin", alors qu'avec PostgreSQL, tu l'as, et bien plus encore !

        Bon, puis j'ai eu beaucoup trop d'emmerdes avec MongoDB, on l'a utilisé sur un site à fort traffic / gros volumes de données, on a fini par le remplacer par un SGBD plus classique et tous nos ennuis se sont évaporés, mais c'était il y a quelques années, peut être que MongoDB s'est sortis les phalanges du fondement depuis.

        • [^] # Re: Scylla/MongoDB

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

          On stocke quelques Tio dedans sans problème particulier, on a plusieurs collections à plus de 20 millions de documents et qu'on met à jour à probablement plus de 2k/s sans problème particulier. Mongo n'aime vraiment pas avoir de gros documents ça le ralenti pas mal.

          Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X), depuis ma femme est revenu !". mongo et postgre sont 2 outils très différents. Pour moi c'est vraiment comme dire "pour ma vis, j'utilisais une clef allen c'était une galère depuis que je me suis acheté une clef torx ma vie a changé, je la serre et la déserre avec plaisir". Ma machine à laver n'est pas meilleure que mon vélo.

          Tous ces outils sont très bons. Ils ne sont juste pas fait pour les même usages. Souvent on est peu contraint et moins on est contraint moins la techno sous-jacente n'a d'importance. Quand on parle de grosse contraintes, il faut se rappeler que ce sont des techno utilisé pour d'énormes infra être petit à coté n'est pas une insulte (et je suis un tout petit à coté). Nous on utilise mysql/mongo/cassandra/infinispan selon le besoin et je n'irais pas dire que l'un dépasse les autres chacun vient avec ses avantages (ce que tout le monde a en tête) et ses inconvénients (qu'on a facilement tendance à oublier), mais si on ne prend pas en compte ses inconvénients ça pose des problèmes (et faut avoir du recul y compris sur ce qui est présenté par le vendeur de ses trucs).

          Par exemple si mongo parle d'avoir des transaction par exemple, il faut pas se dire que c'est parti on refait comme en SQL. Tous ses outils et pg le premier tentent d’agrandir autant que possible leur surface d'utilisation, mais sauf cas particulier ça devrait rester à la marge (voir être ignoré) parce que ça remet en cause l'architecture de base du truc ce qui lui donnait un intérêt.

          En plus avec PostgreSQL tu peux explicitement créer les indexes comme bon te semble, et profiter de toutes ses autres fonctionnalités.

          Je ne te suis pas, de quoi parle-tu ? Mongo peut très bien avoir des indexes par contre postgre ne peux pas faire n'importe quoi avec du jsonb. Si par "toutes les autres fonctionnalités" tu entends "sauf ma majeure partie des fonctions relationnelles" ça en enlève un paquet et ça réduit fortement l'intérêt d'un moteur de base de données relationnelle à cela on ajoute un requêtage limité, de même pour les vues du coup. Clairement c'est pas fait pour la même chose.

          • [^] # Re: Scylla/MongoDB

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

            mongo et postgre sont 2 outils très différents

            C'est vrai, je suis d'accord, cependant tout dépend du besoin. Quand tu veux faire du CMS, de la vitrine, un site métier mais sans fortes contraintes relationnelles, ou juste quand tu es le commun du mortel, le choix entre un SGBD et une base NoSQL est parfois ambigu: les deux vont fournir les fonctionnalités nécessaires et suffisantes pour le besoin, et les deux vont écrire noir sur blanc dans leur documentation que c'est le bon outil pour implémenter ce besoin. Finalement, tout comme les SGBD, MongoDB est assez polyvalent lui aussi.

            La seule différence sera dans la façon de l'utiliser, et souvent la bonne réponse reste le SGBD conventionnel un poil plus polyvalent. C'est juste une question d'échelle, si passer au NoSQL ne déverrouille pas une contrainte que tu aurais avec le SGBD classique (comme par exemple, le besoin de passer à l’échelle horizontalement, et encore que…), autant rester sur l'ennuyeux SGBD classique car c'est souvent un outil plus mature, plus stable, pour lequel on trouvera un meilleur support et plus de gens compétents pour travailler avec.

            Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X),

            C'est là que je ne suis pas d'accord. À l'époque, et c'était un choix de design logiciel assumé par MongoDB, une lecture et une écriture en même temps sur la collection influaient l'une sur l'autre, et des enregistrements pouvaient simplement ne pas être écrit, des mises à jour pouvaient être ignorées, et la lecture pouvait lire un même document deux fois, etc… C'était des comportements très grave, et impossibles à ignorer dans notre contexte, où on avait beaucoup de lectures et écritures concurrentes.

            Maintenant ils semblent avoir implémenté correctement quelque chose qui ressemble enfin à des transactions, mais il leur a fallu du temps, plusieurs années même. Ça refroidit vraiment, c'est devenu pour nous un outil à fuir absolument. Trop de mauvaises surprises, et certains étaient même assumées par ses mainteneurs et marqués comme étant "par design".

            Ma machine à laver n'est pas meilleure que mon vélo.

            Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données. Il y a une intersection entre les deux espaces fonctionnels fournis par ces deux outils. Je pourrais dire la même chose avec Cassandra et MSSQL, ou encore bien d'autres bases de données.

            tu entends "sauf ma majeure partie des fonctions relationnelles"

            Non pas forcément, PostgreSQL va bien au delà, il convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin), pour faire du publish/subscribe (event/notify), pour implémenter de la recherche fulltext, et ses capacités vont encore bien au delà (et sans parler des extensions). MongoDB s'est amélioré avec le temps, je dis pas, seulement, vu son âge finalement peu avancé comparés à beaucoup d'autres bases de données, je lui fais encore pas confiance.

            • [^] # Re: Scylla/MongoDB

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

              Ce qui manque à Postgresql, c'est un langage lisible qui est transpilé vers SQL. Écrire une requête de 2 lignes, c'est facile. Écris une requête SQL de 100 lignes et tu deviens chauve.

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

              • [^] # Re: Scylla/MongoDB

                Posté par  (site Web personnel) . Évalué à 8 (+7/-0). Dernière modification le 06/08/21 à 10:03.

                Le SQL est un langage standardisé (et d'ailleurs, PostgreSQL est un SGDB qui respecte le standard, presque le seul, hors fonctionnalités qui vont au delà du standard) qui a plus de 40 ans maintenant.

                Ça s'apprend, et c'est pas compliqué en vrai. J'en fais depuis des années certes, donc c'est difficile de me mettre dans la peau de quelqu'un qui apprend de zéro, mais je l'ai appris à un moment ou un autre. Le seul changement de paradigme un peu perturbant, je pense, c'est de raisonner de façon ensembliste (bien que le SQL ne soit pas réellement une transposition de la théorie des ensembles, il s'en inspire). Toute personne qui travaille sur un langage qui gère correctement les collections et a un système de typage complet y trouvera beaucoup de choses familières. Enfin, pour des requêtes simples, et même certaines plus complexes, il n'y a définitivement pas besoin d'être mathématicien, ni même de connaître quoi que ce soit à propos de la théorie des ensembles.

                En plus, c'est vraiment cool comme langage, parce que c'est spécifié comme étant un langage déclaratif: tu dis ce que tu veux comme résultat, et c'est au serveur de choisir comment l'interpréter, et de choisir la façon optimale pour obtenir le résultat que lui a demandé.

                Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur, ce qui le rend bien plus accessible que la majeure partie de langages qu'on manipule tous les jours, qui vous nous exposer des détails techniques complexes pour permettre de contourner les faiblesses de ton processeur ou te forcer à gérer ta mémoire par toi même. Le SQL s'affranchit complètement de toutes ces contraintes qui polluent la sémantique, et te permet de réfléchir uniquement à tes données. Il te fourni une langue pour exprimer simplement des transformations de collections de données. C'est même bien plus expressif et lisible que les libraries réactive-fonctionnelles très à la mode en ce moment.

                PostgreSQL est réputé pour avoir le meilleur moteur d'optimisation de requête SQL au monde (à tel point qu'il est aussi utilisé par d'autres outils) et pour avoir testé et écrit des choses vraiment compliquées avec, mis à part de très rare cas (vraiment très rare) avec les versions récentes de PostgreSQL plus tu écris le SQL simplement et naïvement, et mieux ça se passe.

                Des langages qui ont essayé de substituer au SQL, ça existe, mais aucun ne fait consensus, et à mon avis ce n'est pas pour rien: aucun de ceux que j'ai pu rencontrer ne permettait réellement d'être à la fois généraliste et d'abstraire des fonctionnalités avancées du SQL dans quelque chose de plus simple.

                Je pense honnêtement, au vu de ce que ça permet de faire, que de concevoir un langage plus simple que le SQL pour le remplacer semble impossible, quant bien même il pourrait sûrement être amélioré (je pense notamment à la syntaxe horrible pour les accès au json). Il y a des cas où c'est possible et ça marche, mais c'est presque systématiquement des langage qui sont en fait des DSL (Domain Specific Language), conçus pour répondre à des problématiques métier, et qui par conséquent ne peuvent être utilisé en dehors.

                Après, rien n'empêche d'imaginer un jour écrire un SQL-v2, qui soit une nouvelle langue plus moderne, mais je pense que sa complexité sera au moins équivalente au SQL lui même.

                • [^] # Re: Scylla/MongoDB

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

                  J'ai appris le SQL, il y a 20 ans. J'ai écris un backend de traitement business complet avec pendant 2 ans. Mon problème était surtout la syntaxe dont les subtilités varies selon là où l'on est (parenthèse ou non, label sous entendu ou pas, …). Peut-être que certain IDE sont meilleur que d'autres par contre. Mais le langage n'est pas récursif dans le sens ou selon le niveau d'imbrication la syntaxe change.

                  Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur,

                  ça c'est souvent faux : Tu peux faire des horreurs si ce que tu écris, implique inutilement de parcourir chaque ligne d'une table.

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

                • [^] # Re: Scylla/MongoDB

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

                  (et d'ailleurs, PostgreSQL est un SGDB qui respecte le standard, presque le seul, hors fonctionnalités qui vont au delà du standard)

                  Mouais, faut pas creuser trop loin ;) Je n'ai pas testé récemment, mais un truc comme ça :
                  CREATE TABLE T_UNIK (C INT CONSTRAINT PK PRIMARY KEY);
                  INSERT INTO T_UNIK VALUES (1), (2), (3);
                  SELECT * FROM T_UNIK;
                  UPDATE T_UNIK
                  SET C = C + 1;

                  te générais une violation de la contrainte d'unicité. Il existe une syntaxe Postgres pour y parvenir (déclarer la contrainte DEFERRABLE INITIALLY DEFERRED), mais il est dommage qu'il faille une extension propre à Postgres pour avoir le comportement attendu par le standard

                  Ça s'apprend, et c'est pas compliqué en vrai. J'en fais depuis des années certes, donc c'est difficile de me mettre dans la peau de quelqu'un qui apprend de zéro, mais je l'ai appris à un moment ou un autre. Le seul changement de paradigme un peu perturbant, je pense, c'est de raisonner de façon ensembliste (bien que le SQL ne soit pas réellement une transposition de la théorie des ensembles, il s'en inspire). Toute personne qui travaille sur un langage qui gère correctement les collections et a un système de typage complet y trouvera beaucoup de choses familières. Enfin, pour des requêtes simples, et même certaines plus complexes, il n'y a définitivement pas besoin d'être mathématicien, ni même de connaître quoi que ce soit à propos de la théorie des ensembles.

                  Le changement de paradigme est quelque chose de délicat. C'est "facile" pour moi aussi, mais quand je vois le code de certains, et vois du code "procédurale" en lieu et place d'un code "ensembliste", ça fait mal (et les performances s'en ressentent).

                  Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur, ce qui le rend bien plus accessible que la majeure partie de langages qu'on manipule tous les jours, qui vous nous exposer des détails techniques complexes pour permettre de contourner les faiblesses de ton processeur ou te forcer à gérer ta mémoire par toi même. Le SQL s'affranchit complètement de toutes ces contraintes qui polluent la sémantique, et te permet de réfléchir uniquement à tes données. Il te fourni une langue pour exprimer simplement des transformations de collections de données. C'est même bien plus expressif et lisible que les libraries réactive-fonctionnelles très à la mode en ce moment.

                  Tout dépend où tu positionnes le curseur lorsque tu dis que le langage ôte la responsabilité de devoir penser performance. Si l'objectif c'est d'exploiter une base de données déjà existante, alors oui, c'est vrai dans 95% des cas (les 5% restants, c'est pour les requêtes que tu es obligé d'écrire autrement tellement les performances sont catastrophiques).

                  Si par contre, il y a aussi l'aspect conceptuel à prendre en compte, alors là non, SQL ne fait absolument pas le boulot à ta place.

                  PostgreSQL est réputé pour avoir le meilleur moteur d'optimisation de requête SQL du monde libre (à tel point qu'il est aussi utilisé par d'autres outils) et pour avoir testé et écrit des choses vraiment compliquées avec, mis à part de très rare cas (vraiment très rare) avec les versions récentes de PostgreSQL plus tu écris le SQL simplement et naïvement, et mieux ça se passe.

                  Désolé, mais je corrige (en gras ma modification). PostgreSQL ce fait largement poutrer par d'autres SGBD propriétaires sur de nombreuses requêtes (il est mauvais sur les COUNT, sur les requêtes avec trop de jointures, etc…). Ce qui ne l'empêche absolument pas d'avoir un bon moteur comparer à d'autres SGBD comme MySQL/MariaDB.

                  (à tel point qu'il est aussi utilisé par d'autres outils)

                  En plus d'être performant, il est libre et gratuit, et avec une licence libre très permissive (style BSD ou MIT). Il peut donc être inclus quasiment sans restriction, contrairement à d'autres moteurs ayant fait le choix d'une licence comme la GPL. Ca aide beaucoup ;)

                  Des langages qui ont essayé de substituer au SQL, ça existe, mais aucun ne fait consensus, et à mon avis ce n'est pas pour rien: aucun de ceux que j'ai pu rencontrer ne permettait réellement d'être à la fois généraliste et d'abstraire des fonctionnalités avancées du SQL dans quelque chose de plus simple.

                  Tout à fait. Le seul truc que je reproche à SQL, c'est la syntaxe du SELECT : j'aurais préféré mettre le nom des colonnes APRES la clause FROM, et pas avant. Cela faciliterait l'écriture en la rendant plus naturelle, surtout avec les IDE d'aujourd'hui. Un IDE ne peut pas proposer l'aide à la complétion sauf à renseigner la clause FROM avant, et à revenir ensuite préciser les colonnes (ce qui rompt l'écriture "naturel" de la requête)

            • [^] # Re: Scylla/MongoDB

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

              C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?

              Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données.

              C'est pas parce que ça stocke de la donnée que c'est la même chose. Envoyer un recommandé et un sms, c'est de "l'envoi de message" pourtant. C'est de la sémantique ce que tu tente de faire, mais quand tu sort d'ACID tu quitte le monde de la base de données tel que tu semble le comprendre, c'est comme si tu te mettais à stocker à la main sur disque ou via ftp. Si on ignore ça, on a le genre de surprises que tu décrit.

              [PostgreSQL] convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin)

              Tu vois t'es encore entrain de comparer des choux et des patates. L'un ne stock rien sur disque et est là pour faire de la latence faible a un modèle de stalabilité… particulier. Là où l'autre écrira toujours tout sur disque fourni largement plus de garanties etc. Bon perso je trouve que redis est le roi du goodenought, mais c'est une autre histoire.

              Postgre est une excellente base de données et ça se voit car son moteur est très flexible et tiens la dragée haute à des moteurs pensés directement pour cette flexibilité (je parle de rocksdb ou cockroachdb qui sont des moteurs qu'on utilise pas directement normalement) alors que pg existe depuis 25 ans. AWS s'en sert par exemple pour produire leur solution compatible mongodb (mais ils n'utilisent pas le support jsonb libre, ils ont leur propre truc à eux). Mais il ne faut pas croire pour autant que tout est gratuit son event/notify est anémique face à de vraies solution (pareil pour redis).

              • [^] # Re: Scylla/MongoDB

                Posté par  . Évalué à 10 (+10/-0). Dernière modification le 06/08/21 à 13:43.

                C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?

                Non; je pense qu'il reproche à MongoDB d'avoir fait des choix de design et marketing très douteux ainsi que d'avoir réussi à violer presque systématiquement les maigres garanties annoncées dans leur doc pendant ses 5+ premières années d'existence. Ce qui est fondamentalement un problème différent que de trouver que les garanties offertes par un outil ne sont pas adaptés à son besoin.

                Ça a commencé par publier des benchmarks montrant à quel point ils étaient "rapides" alors que la configuration par défaut de Mongo était de ne pas garantir la durabilité des écritures acceptés (ie. non persisté dans un WAL).

                Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.

                Côté garanties documentées, garanties réellement implémentées et configuration par défaut, on est passé par toutes les étapes possibles de WTF.

                Il me semble qu'un changement significatif a eu lieu vers la version 3 et au moment où Aphyr les a mis en pièce. Ils ont commencé à chercher à afficher des garanties raisonnables et à les implémenter correctement. Le surnom snapshat for database de mongo ne vient pas de nul part; et tu peux aisément comprendre que suite à cet historique des gens s'en tiennent le plus loin possible.

                • [^] # Re: Scylla/MongoDB

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

                  Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.

                  Tu peux pas balancer ça un vendredi et pas suivre avec au moins une description rapide d’un ou deux bug :)
                  Surtout qu’il faut un compte et tout pour le bug tracker.

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

                  • [^] # Re: Scylla/MongoDB

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

                    Dans les bugs encore récent et drôle, tu as des requêtes "upsert" pour mettre à jour ou insérer. Ces requêtes peuvent te dire des trucs du genre "error: _id already exists"…

                  • [^] # Re: Scylla/MongoDB

                    Posté par  . Évalué à 5 (+3/-0). Dernière modification le 06/08/21 à 19:01.

                    Je n'ai malheureusement pas bookmarké à l'époque :(

                    Tu avais des trucs genre "Je mets à un jour champ avec une virgule dedans" ça t'éclate 1 ou 4 documents en les remplissant de merde, mutant les types ou autre. Je n'ai plus les détails, mais je fouillai le bug tracker pour identifier mes problèmes et était effaré de voir sur le nombre de connerie du genre. C´était systémique.

                • [^] # Re: Scylla/MongoDB

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

                  Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière1.

                  Tu parle d'une version d'il y a 6 ans. C'est très vieux. Même pour pg, si tu prends une version d'il y a 6 ans, tu aura de gros gap (par exemple avoir des déploiement un peu plus sympa que du primaire/secondaire ou dans tout ce qui est partitionnement). Je ne parle même pas de redis qui était très balbutiant il y a 6 ans.

                  Critiquer aujourd'hui un logiciel si vieux, dans un domaine qui évolue autant (postgresql ne supporte pas de versions aussi vielles). C'est à minima non pertinent.

                  Ensuite le marketing, je comprends et en même temps je ne comprends pas pourquoi débrancher son cerveau. Sur un sujet dont c'est ton domaine s'appuyer sur les discours marketing, plus que sur l'architecture ça ne me parait pas être une bonne idée et c'est pas comme si mongo inc étaient les seuls à parler de mongo. De la même manière qu'il faut pas trop accorder d'importance au market de datastax (la boite derrière cassandra) ou d'elastic pour elasticsearch. Ils sont éventuellement intéressant pour savoir quel marché intéresse la boite, mais ça ne vas pas plus loin.

                  Si tu veux te marrer regarde redis et hazelcast :

                  C'est peut être désolant, mais il y a un marché et donc des gens qui se battent.


                  1. j'avais vu des trucs très très chelou avec mysql 

                  • [^] # Re: Scylla/MongoDB

                    Posté par  . Évalué à 10 (+10/-0). Dernière modification le 06/08/21 à 19:10.

                    Critiquer aujourd'hui un logiciel si vieux, dans un domaine qui évolue autant (postgresql ne supporte pas de versions aussi vielles). C'est à minima non pertinent.

                    Le truc c'est que tu ne critiques pas le logiciel mais l'entité qui est derrière et son fonctionnement. Mongo a bâti sa place en mentant ouvertement (au minimum par omission délibérée et répétée).

                    Qu'un produit ait des limites annoncées ou quelques bugs est dans l'ordre des choses. Mais quand quelqu'un a passé au minimum 5 ans à mentir sur ses garanties (on parle d'une DB), ça ne me choque pas que quelqu'un puisse ne pas vouloir s'en approcher pour des raisons éthiques ou techniques. D'autres diront que les choses ont changées ces derniers temps et ne verront aucun problème à récompenser ce comportement. Je peux comprendre les deux points de vue.

                    Ensuite le marketing, je comprends et en même temps je ne comprends pas pourquoi débrancher son cerveau. Sur un sujet dont c'est ton domaine s'appuyer sur les discours marketing, plus que sur l'architecture ça ne me parait pas être une bonne idée et c'est pas comme si mongo inc étaient les seuls à parler de mongo

                    On ne parle pas de marketing. On parle de mentir sur les garantie offertes dans les documentations techniques, d'avoir des configurations volontairement dangereuses par défaut pour faire croire qu'on est pas si lent que ca, et d'oublier de parler de comment tu as obtenu tes chiffres.

                    Personnellement, je trouve triste d'être OK avec ça.

                    • [^] # Re: Scylla/MongoDB

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

                      Personnellement, je trouve triste d'être OK avec ça.

                      C'est pas une question d'être ok ou pas. Avant de reprocher ça a mongo, ça pourrait être reproché à un paquet de logiciels même non commerciaux. Mais aussi à Intel, AMD, Nvidia et n'importe quel fabriquant de carte mère. Tu utilise du x86 ? C'est triste d'être ok avec ça.

              • [^] # Re: Scylla/MongoDB

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

                je trouve que redis est le roi du goodenought

                Clairement, c'est comparer des choux et des patates :) Comparer mongo ou mysql avec un vrai sgbr, c'était déjà douloureux. mainteant si tu rajoute un cache, on ne va plus s'y retrouver :D

                PS: on m'informe à l'instant qu'un troll s'est caché dans ce message.

              • [^] # Re: Scylla/MongoDB

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

                Tu vois t'es encore entrain de comparer des choux et des patates. L'un ne stock rien sur disque et est là pour faire de la latence faible a un modèle de stalabilité… particulier. Là où l'autre écrira toujours tout sur disque fourni largement plus de garanties etc. Bon perso je trouve que redis est le roi du goodenought, mais c'est une autre histoire.

                C'est faux comme affirmation. Par défaut, Redis écrit tout sur le disque, et de façon synchrone en plus, comme PostgreSQL.

                Les deux ont une latence relativement faible, mais Redis est bien plus efficace avec un très grand nombre de connexions.

                Redis permet de faire des transactions qui sont (de mémoire) presque ACID. Je n'y a pas retouché depuis 3~4 ans, mais j'ai testé dans tous les sens à l'époque de la version 2.8 et 3, et ça marche.

                Redis ce n'est pas goodenought, ça dépend comment tu le configure, mais presque toutes les bases de données quel que soit leur type, te permettent de les configurer pour les rendre plus rapide et moins safe, ou plus lentes et très safe.

                On a utilisé Redis sur des productions pendant plusieurs années, on a jamais eu de soucis particulier, ça marche comme c'est écrit.

        • [^] # Re: Scylla/MongoDB

          Posté par  (site Web personnel) . Évalué à 5 (+2/-0). Dernière modification le 06/08/21 à 08:31.

          Le problème de postgresql, c'est que ça manque de multi sites / maîtres qui marche hors de la boite:(

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

          • [^] # Re: Scylla/MongoDB

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

            Le problème est surtout que le retournement maitre/esclave est compliqué et tu peux te retrouver dans un mode split-brain qui est un problème hyper-complexe avec une base SQL. En gros, il faut 3 bases pour que cela marche.

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

            • [^] # Re: Scylla/MongoDB

              Posté par  (site Web personnel) . Évalué à 3 (+2/-2). Dernière modification le 06/08/21 à 12:45.

              C'est révolutionnairement logique: il faut deux classes sociales pour renverser la troisième !

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

            • [^] # Re: Scylla/MongoDB

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

              disclaimer: fan de Pg, et pas expert pour un sous

              Le problème du split brain, c'est un problème qui est partagé par toutes les setups qui se veulent haute-dispo. La solution doit être évidemment pensée pour qu'il n'y en aie pas. Plus facile à dire qu'à faire… surtout qu'on se limite souvent au périmètre du la bdd, alors qu'il faut pouvoir analyser le système dans son ensemble. Ceci-dit, la linéarité maître-esclave fournit des outils en plus pour éviter ce cas (timelines) et en général elle se prête bien au modèle d'intégrité des SGBR.

              Si on se limite au périmètre de la sgbr, certes pg n'a pas de solution clef en main comme mongo ou elastic. Et je dirais que c'est pour le mieux, car cela pousse les gens à mieux réfléchir à leur solution (et, espérons le, à sortir du périmètre de la bdd uniquement). Au contraire, mongo et elastic vont te donner beaucoup de misères dans les scénarios où justement ça me fonctionne plus comme il faut… ce qui est en fait contre productif :) (de bonne foie, cet argument peut s'appliquer à toute solution HA)

              Sur le point de la réplication, pg a eu un développement exemplaire de sa solution de réplication. Elle a évoluée petit à petit à partir d'une base solide, certes lentement, mais en ne compromettant jamais l'existant: Pg t'offre la garantie qu'une requête au moment transactionnel "t" donnera le même résultat sur tous les réplicas, ou une erreur*. C'est une opinion qui est largement répandue et que je partage. Si on compare à mysql, il y avait plusieurs méthodes de réplication, chacune avec des limitations différentes, et aucune ne garantissant une réplication parfaite. Il est de plus possible (je dirais, indispensable même) de tirer profit de la numérotation des transaction pour mieux coordonner ses différents application clientes de la bdd.

              Pour en revenir à la question de quelle solution est supérieure aux autres, et bien je dois dire que c'est celle que l'on comprenne et pour laquelle on est prêt à développer. Faire du mongo ou ES en multi-nodes, pourquoi pas, mais alors jamais il ne faut dépendre de leur intégrité supposée. Avoir une archi maître-maître, c'est aussi utiliser des types de données différents qui sont "fusionnables" afin d'éluder le problème de la résolution de conflits. Pg a aussi certains fork proprios faisant du maître-maître, mais il faut bien comprendre les tenants et aboutissants pour en faire un bon usage, et certainement pas s'attendre à de meilleures performances et encore moins à ne pas devoir modifier ses applications.

              *: C'est le talon d'Achille de ce modèle: une requête active sur un replica suspend l'application de certaines transactions qui sont susceptibles d'entrer en conflit (par exemple, un drop table) et donc de toutes celles qui suivent (car les transactions sont appliquées dans le même ordre pour garantir l'exactitude de la réplication). Le risque c'est d'avoir un blocage/lag persistent qui fini par générer des erreurs après que le délais dépasse une valeur arbitraire.

        • [^] # Re: Scylla/MongoDB

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

          Bon, puis j'ai eu beaucoup trop d'emmerdes avec MongoDB

          Je suis plutôt « anti-Mongo » (encore plus depuis qu’ils ont changé de licence), entendre le nom MongoDB me fait le même effet qu’entendre le mot blockchain, mais y a un truc sur lequel Mongo est bien plus moderne, c’est la partie opérationnelle.

          Quand j’étais OVH on avait un cluster où il arrivait régulièrement qu’un des nœuds se désynchronise (je sais plus la raison exacte) et faire repartir le cluster c’était juste une histoire de rm -rf /var/lib/mongo/, restaurer le keyfile, et redémarrer Mongo. Il retrouvait ses petits et se resynchronisait tout seul.

          À côté de ça, on avait des pages de procédures pour restaurer un PG ou une MySQL après un failover.

  • # Un titre pareil...

    Posté par  . Évalué à -7 (+8/-16). Dernière modification le 06/08/21 à 22:14.

    … ne devrait pas être accepté.

    Amis (et amies ?) en charge de la modération, voulez-vous intervenir ?

    • [^] # Re: Un titre pareil...

      Posté par  . Évalué à 5 (+4/-1). Dernière modification le 07/08/21 à 12:20.

      tu pensais à quoi ? Peut-être que c'est toi qui a juste l'esprit mal placé…

      • [^] # Re: Un titre pareil...

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

        C'est une faute de grammaire grave, celle de confondre un verbe avec un nom propre.

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Un titre pareil...

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

        Pas besoin d'avoir l'esprit mal placé, juste d'avoir de la culture (et d'être assez vieux).

        Le titre est pour moi une référence au sketch "Le viol de Monique", fait par Coluche en 1979. On le trouve sans souci en cherchant sur le web, mais pour éviter de chercher, il est sur youtube.

        Il suffit d'écouter jusqu'à 1 minute 28:

        Vous savez comment on l'appelle dans mon quartier: "Monique, deux qui la tiennent, trois qui la niquent".

        • [^] # Re: Un titre pareil...

          Posté par  . Évalué à -3 (+8/-11).

          Merci Misc ;)

          Je me rends compte que ce n'était pas évident pour tout le monde. En ce qui me concerne, ce titre m'a sauté à la figure. Et nul doute que l'auteur savait très bien ce qu'il écrivait. Il a voulu faire sourire, mais il a surtout démontré une triste disposition, latente dans logiciel libre, à diverses formes de sexisme. Ici, la culture du viol.

          • [^] # Re: Un titre pareil...

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

            Il y plein de blagues qui parlent de la mort. Est-ce une culture de la mort ?

            Il y a plein de blagues sur les blondes? Est-ce une culture de la blonde?

            J'ai essayé d'en trouver non offensante*:

            • Combien de tour fait un bébé dans un micro onde avant d'exploser?
            • Je ne sais pas, j'ai du mal à compter quand je me masturbe.

            *: mais je n'en ai pas trouvé :(

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

            • [^] # Re: Un titre pareil...

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

              L'humour sexiste, c'est de l'humour.

              Sexiste.

              J'aimerais lire linuxfr.org sans me frotter à ce genre d'humour, même s'il passe inaperçu à moins de connaître Coluche et d'entendre la consonance (un peu lointaine, certes) entre un acte sexuel et une référence à la mythologie.

              Ma pétition n'est pas autant dirigée à l'équipe de modération finalement, qu'à toi, @devnewton : ok, c'est pas sympa de ma part de te montrer du doigt, j'admets. C'est désagréable, il y a de quoi se mettre sur la défensive.

              Mais franchement, a-t-on besoin de placer un trait d'humour tirés par les cheveux, en forme de scène de viol, parce que le nom du projet sur lequel on écrit est féminin ? À quel genre de communauté on contribue de cette façon ? Je doute que tu aurais été aussi spontanément créatif avec un nom masculin.

              Non, non, ceci n'est pas un encouragement ;)

            • [^] # Re: Un titre pareil...

              Posté par  (site Web personnel) . Évalué à 5 (+8/-5). Dernière modification le 09/08/21 à 09:58.

              Il y plein de blagues qui parlent de la mort. Est-ce une
              culture de la mort ?

              Non, parce que la mort est un phénomène biologique globalement inévitable qui arrive à tout le monde. Je pense qu'on peut difficilement dire que le viol est inévitable, ni ignorer sa repartition suivant des lignes de genre.

              Il y a plein de blagues sur les blondes? Est-ce une culture de
              la blonde?

              Non, mais clairement, on peut voir ça comme une culture ou il est sociétalement accepté de se moquer des gens pour la couleur des cheveux et leur genre, surtout une fois qu'on s’aperçoit qu'il y a des blagues qui ne sont pas envisagé.

              Ton exemple est assez parlant, parce que je pense que dire "il y a plein de blagues sur les chatains" aurait été beaucoup plus surprenant et moins naturel.

              Déjà parce qu'il n'y en a pas vraiment, malgré le fait qu'on peut trivialement changer le genre et la couleur de cheveux dans n'importe quel blague.

              Ensuite, parce "la blonde" évoque un personnage, mais "le chatain" non.

              Donc oui, le fait que "la blonde" évoque un personnage traduit quelque chose au niveau de la société.

            • [^] # Re: Un titre pareil...

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

              C’est toujours la même histoire, ce genre d’humour ça tombe vite à plat.
              Coluche s’en sortait parce que c’était Coluche, que c’était son boulot, qu’il était doué, qu’il était drôle et que son public venait le voir pour ce genre d’humour.
              Ah, et aussi, parce qu’on comprenait assez vite que c’était du 2nd degré et qu’il y avait un message sous jacent.

              La tu choppes un public, qui ne vient pas pour ça, à froid, avec une référence obscure (c’est pas son sketch le plus connu, clairement), sur un sujet qui plus est sensible.
              Faut pas s’étonner de se prendre un bide.

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

              • [^] # Re: Un titre pareil...

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

                La tu choppes un public, qui ne vient pas pour ça, à froid,
                avec une référence obscure (c’est pas son sketch le plus connu,
                clairement)

                Oui, et puis, Coluche, il semble ne plus faire trop de spectacle. Je me demande ce qu'il devient, j'irais voir après ma réunion d'équipe.

              • [^] # Re: Un titre pareil...

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

                Le pattern X qui la tiennent, Y qui la Z est plutôt connu en humour français.

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

                • [^] # Re: Un titre pareil...

                  Posté par  (site Web personnel) . Évalué à 3 (+4/-3). Dernière modification le 09/08/21 à 18:18.

                  Je n’ai jamais vu ce « pattern » autrement que dans sa forme originale.

                  • [^] # Re: Un titre pareil...

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

                    Juste de tête comme ça, je pense aux Inconnus, un flim avec Chabat et la blague de Monsieur et Madame Deukil…

                    Je veux bien qu'il faille tout expliquer aux petits nouveaux, mais dans les commentaires on en tient un qui n'avait pas compris la référence mythologique.

                    Donc les jeunes, au lieu de regarder des youtubeurs débiles, vous allez me relire tout Homère et tous les humoristes français (oui même Anne Roumanov, ça vous apprendra à faire les malins).

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

                • [^] # Re: Un titre pareil...

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

                  Vu le bouillon que tu t’es prit, je suis pas sur qu’il soit aussi connu que ce que tu penses.
                  Le simple fait que misc ait du clarifier la référence devrait te mettre la puce à l’oreille.

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

          • [^] # Re: Un titre pareil...

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

            Ce titre m'a aussi sauté à la figure, mais même avec des explications (nom/verbe, référence…) il faut bien avouer que le mot Hécube, n'apparaît qu'en tant que nom propre dans mon dictionnaire. Du coup, je ne comprends toujours pas. Et c'est bien dommage. En général j'apprécie l'humour de Devnewton.

            « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Un titre pareil...

      Posté par  (site Web personnel) . Évalué à 4 (+8/-7). Dernière modification le 07/08/21 à 16:16.

      Pourquoi? Parce que l'humour peut faire mourir de rire ? Parce que les références mythologiques sont anti laïques ? Parce que les Inconnus pourraient porter plainte pour plagiat de leur chanson Y'en a marre du rap ?

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

  • # Ah ouais quand même

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

    Écrite en Java (pour les perfs),

    OMG !

    elle utilisable […] ou via des API dans tous les bons langages mais aussi en Python ou Node.js.

    J'ai ressenti une grande perturbation dans la force trollique…

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Ah ouais quand même

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

      J'ai ressenti une grande perturbation dans la force trollique…

      C'est pas faux. Node.js n'est pas un langage xD (bon, je dénote encore 2 trolls dans la même phrase, je me limite à celui qui est le moins subjectif :) )

Envoyer un commentaire

Suivre le flux des commentaires

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