Appel à contributions de la Fondation MariaDB auprès des universités

Posté par  . Édité par Davy Defaud, Ysabeau 🧶 🧦 et ZeroHeure. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
22
5
nov.
2019
Base de données

La Fondation MariaDB lance un appel à contributions auprès des enseignants et de la communauté afin de contribuer à un curriculum de formation théorique et pratique sur les bases de données, en s’appuyant tout ou partie sur MariaDB. Kaj Arnö, président de la Fondation MariaDB, viendra présenter l’initiative à Paris le 12 novembre à 16 h au Bistro du Canal (75010), juste avant l’événement organisé par le Fonds de Dotation du Libre et le CNLL à Cap Digital.

L’objectif de cet enseignement est de s’attaquer à la pénurie de compétences avancées sur les bases de données et d’améliorer la pédagogie sur les aspects algorithmiques (caches, structures des index, prédiction de jointure, tables de hachage sans verrou, etc.) qu’il faut aujourd’hui environ dix ans à acquérir. Kaj Arnö présentera également la feuille de route de MariaDB (10.5).

Aller plus loin

  • # s’attaquer à la pénurie de compétences avancées sur les bases de données

    Posté par  . Évalué à 9. Dernière modification le 05 novembre 2019 à 21:53.

    s’attaquer à la pénurie de compétences avancées sur les bases de données

    Pardon, mais, p'tet que le problème vient du fait que la doc est contre-intuitive? Chose qui sera jamais corrigée par des rencontres au sommet…

    Désolé si je suis amer, mais je me tape (connotation négative volontaire) des systèmes "embarqués" (beaglebone black, 512Mio de ram, ça va, les ressources sont larges) sous debian, dont les softs utilisent mysql… pardon, mariadb.
    Vu que "peu" de ram, systèmes sur mmc, distants (plusieurs 100aines de km, on peut pas y aller en un jour), et proprio (mea culpa) j'ai essayé de désactiver l'overcommit.

    Soit. Sous linux, pas de souci, ça se fait en 1 ligne de conf. Par contre, ben, mariadb démarrait plus: pour une DB utilisée par 3 processus, il lui faut 10 threads/process, chacun bouffant sa dose de MébiOctets de RAM… bien trop pour l'usage.
    Lecture de manpage. Modif de fichiers de conf. Essai… rien ne change. Réduire le nombre de threads ou la taille des caches ne fait RIEN, contrairement a ce que promets la manpage…

    Alors, je sais, c'est pas fait pour l'embarqué, mais je dois faire avec, jusqu'a ce qu'on migre vers ce bon vieux sqlite, mais quand même, pourquoi qu'elle semble mentir, la doc? Pourquoi que c'est si dur de trouver des infos? Pourquoi qu'embarquer ce machin dans du proprio (désolé, vraiment, j'aimerai pouvoir release le code en libre, ma boîte y gagnerais même en qualité de code, parce que la, quand je lis le code, je pleure) embarqué, c'est pas possible?

    Avant de s'attaquer aux problèmes avancés, attaquer la base serait p'tet pas mal.
    Merci de votre lecture, vous pouvez moinsser maintenant :)

    • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

      Posté par  (site web personnel) . Évalué à 9.

      Tu sembles être le candidat idéal pour contribuer à la documentation !
      https://mariadb.com/kb/en/library/contributing-to-the-mariadb-project/

    • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

      Posté par  (site web personnel) . Évalué à 9.

      À la fois, une grosse part du boulot des enseignants chercheurs consiste à écrire de la documentation didactique : cours et exercices. Même si on est nuls et paresseux (fonctionnaires, tout ça…) créer des formations sur un sujet devrait aboutir aussi à l'amélioration de la qualité des documentations.

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

      Posté par  . Évalué à 3.

      Si je comprend bien pour essayer de résoudre un hypothétique problème potentiel tu as modifié un paramètre (qui a des conséquences majeures sur tout le système) et tu t'es retrouvé avec un problème réel. L'overcommit, à moins de savoir très exactement ce qu'on fait, il vaut mieux ne pas y toucher.

      Pour mieux contrôler comment la mémoire de MariaDB est utilisée je trouve que MySQLTuner est intéressant.

      • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 novembre 2019 à 00:23.

        L'overcommit, à moins de savoir très exactement ce qu'on fait, il vaut mieux ne pas y toucher.

        Faudrait… «une formation théorique et pratique sur les bases de données» :-)

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

        Posté par  . Évalué à 2.

        En quoi est-ce mal? Le OOM killer n'est pas particulièrement prédictible et je me suis déjà retrouvé avec une machine qui freeze à cause d'une fuite mémoire dans un de mes scripts.
        Pour une machine distante j'ai décidé de désactiver l'overcommit, au moins le script incriminé plante tout de suite. Mais si tu as une meilleure idée je suis preneur.

      • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

        Posté par  . Évalué à 3. Dernière modification le 10 novembre 2019 à 02:30.

        Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.

        Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.

        N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.

        Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.

        SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?

        • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

          Posté par  . Évalué à 3. Dernière modification le 11 novembre 2019 à 07:10.

          J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.

          Alors essaie déjà :
          ulimit -v mémoire_max_en_Ko

          À lancer depuis le shell avant la commande concernée (dans un script dédié, sinon les suivantes seront impactées aussi).
          Pour plus de détails, man bash, puis taper /ulimit
          (man ulimit concerne une version générale beaucoup plus limitée).

          N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse.

          J’ai vu le cas de logiciels (notamment un navigateur web pour lequel c’est flagrant, peut-être Midori, mais je ne suis pas sûr) qui allouent une quantité de mémoire très importante mais n’en utilisent réellement qu’un peu. Peut-être est-ce un préalable à une gestion interne de l’allocation mémoire qui permet de la simplifier.

          Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus.

          Et en n’allouant pas de swap (une façon efficace de ne pas en utiliser), est-ce que MySQL fonctionne quand même ou pas ?
          J’aurais tendance à penser que la taille mémoire totale (physique + swap) fixe une limite à l’overcommit, mais ça reste à voir…

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

            Posté par  . Évalué à 2.

            ulimit -v mémoire_max_en_Ko

            Pas con, j'essaierai. Je pense que mysql va se ramasser, mais ça vaut le coup d'essayer.

            J’ai vu le cas de logiciels (notamment un navigateur web pour lequel c’est flagrant, peut-être Midori, mais je ne suis pas sûr) qui allouent une quantité de mémoire très importante mais n’en utilisent réellement qu’un peu.

            Tous les navigateurs graphiques que j'ai essayé pour le moment en font partie, virtualbox aussi. Ce sont les seuls que j'aie remarqués pour l'instant.

            Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus.

            Et en n’allouant pas de swap (une façon efficace de ne pas en utiliser), est-ce que MySQL fonctionne quand même ou pas ?

            Sans problème. C'est juste que, du coup, il y a plus de 600Mio de réservés sur un système qui n'en a que 512Mio. Tant que ça marche…
            Honnêtement, ça fait longtemps que je n'utilise plus de fichier d'échange: à quoi bon? C'est juste un coup a user plus vite le disque et faire quasi freeze le kernel. Je préfère de loin qu'un gros bloatware comme [insérer ici un navigateur mainstream de votre choix] se mange un oom kill. Et l'hibernation est plus lente qu'un cold-boot sur mes machines depuis bien avant que j'aie un SSD.

            J’aurais tendance à penser que la taille mémoire totale (physique + swap) fixe une limite à l’overcommit, mais ça reste à voir…

            Selon la doc (je voulais pas dire de connerie en me basant sur ma mémoire, un peu trop floue):

            • si overcommit = 0: le noyau essaie d'estimer la mémoire restante (swap+ram) lors d'un malloc;
            • si overcommit = 1: quand y'en a plus, y'en a encore;
            • si overcommit = 2 (mon réglage habituel et souhaité): si y'en a plus, y'en a plus.

            Par défault, c'est sur 0, et overcommit_ratio vaut 50 (% de ram+swap). Sauf que, l'estimation, elle se fait par allocation, si ma mémoire est bonne (la, j'ai la flemme d'aller lire plus avant, désolé), ce qui fait que si 10 process ont alloué 5 fois chacune 10% de ta mémoire totale, mais sans la remplir, bah ça marche. Jusqu'a ce qu'une appli remplisse réellement la mémoire, bien sûr.

        • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

          Posté par  . Évalué à 1.

          Et simplement donner un oom_score_adj de 1000 à ton service qui fuit et -100 à ton service qui doit survivre ?

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

          • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

            Posté par  . Évalué à 2.

            J'avoue ne pas savoir comment configurer l'oom killer.
            Le truc, c'est que le code qui fuit, une fois qu'on sait qu'il fuit, on le corrige (pour le coup, c'est un code à nous).
            Par contre, ben, comme on a aussi des problèmes hardwares, on a mis longtemps avant de détecter cette fuite (ça c'est fait de manière… fortuite, pour le coup).

            Donc bon, je dirais qu'en fait, le plus simple c'est juste de pas squatter la RAM, de sorte a ce que l'overcommit soit désactivable. En plus, si mysql se servait vraiment de tout ça, il marcherait pas (et on serait passé à autre chose depuis longtemps, probablement sqlite pour mon plus grand bonheur, qui aurai au passage drastiquement simplifié le déploiement puisqu'on peut gérer une BDD binaire et la packager, au moins, alors que j'ai l'impression qu'avec mysql, on peut juste dumper le SQL et le restaurer par script. Pas génial pour faire un paquet.).

            • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

              Posté par  . Évalué à 2.

              Hors de la remise en cause de vos choix, éviter que l'OOM killer flingue le service qui te sert à le piloter (et donc t'évite des centaines de km). Ça pourrait être sympa (si j'ai bien compris l'un des commentaires au dessus).

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

              • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                Posté par  . Évalué à 2.

                Sauf que le problème, c'est qu'il n'interviens jamais dans la configuration par défaut, et ça résulte en un système freeze. La configuration par défaut est faite pour des systèmes dans lesquels la maîtrise n'est pas pas un problème parce qu'on peut rebooter d'une manière ou d'une autre, le système par défaut n'est pas autonome.

                C'est (un de mes) mon soucis, justement: je me retrouve avec des softs (mysql ici) poussés par des débutants (avant que j'arrive, même si je ne me considère pas comme bon, j'ai un peu plus de recul qu'un étudiant, mais la boite a une histoire) parce que c'est ce qu'on apprend a l'école, mais l'école n'enseigne que des cas idéaux avec des ressources infinies, sans enseigner les cas ou les ressources sont limitées, qui existent pourtant dans la majorité des équipements informatiques (routeurs, switch, montres, radio-réveil, mobilier urbain, etc).

                Ce n'est pas simple a expliquer, et a gérer encore moins, surtout que je me considère plutôt comme tech que comme décisionnaire ou architecte… faut naviguer entre compréhension de l'histo et ses racines, sa propre considération de l'idéal et les réalités de la boîte… donc pardonnes mes biais, raccourcis et imprécisions

                • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                  Posté par  . Évalué à 0. Dernière modification le 13 novembre 2019 à 23:19.

                  Je ne comprends pas grand chose (tu peux désactiver l'overcommit, mais pas jouer sur l'OOM), mais ça a l'air triste. Tu m'excusera de ne pas m’apitoyer sur ton sort ? Tu as l'air de faire ça tellement bien tout seul. Tu passe beaucoup plus de temps à te plaindre du sort que de répondre aux astuces qui te sont proposées.

                  Je ne suis pas certain que tu ai choisi le meilleur endroit pour ton besoin d'empathie ;)

                  (en fait c'est même plus toi très agaçant de voir quelqu'un se plaindre et à chaque proposition qu'on lui fait en faire des caisses pour expliquer pourquoi le monde est cruel avec lui sans véritablement répondre)

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

                  • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                    Posté par  . Évalué à 3.

                    tu peux désactiver l'overcommit, mais pas jouer sur l'OOM

                    J'ai pas dit que je peux pas, j'ai dis que je ne sais pas faire, nuance.

                    Tu m'excusera de ne pas m’apitoyer sur ton sort ?

                    Sans le moindre problème.

                    Tu as l'air de faire ça tellement bien tout seul.

                    Ouai, non, en fait, je ne fais que parler de vécu, d'un type qui se démerde comme il peut pour que des systèmes expédiés au loin marchent sans intervention humaine, dans un respect complet de la Rache, méthodologie imposée par le patron.

                    Je ne suis pas certain que tu ai choisi le meilleur endroit pour ton besoin d'empathie ;)

                    J'ai autre chose a faire qu'attendre l'empathie. Je préfère en fait la laisser de côté, bien plus simple de s'améliorer en technique quand on met de côtés les sentiments.
                    Au pire, je peux finir a -10, et alors? Je n'en mourrai pas, j'apprendrais des remarques (à tout score, hein, de toute façon).

                    (en fait c'est même plus toi très agaçant de voir quelqu'un se plaindre et à chaque proposition qu'on lui fait en faire des caisses pour expliquer pourquoi le monde est cruel avec lui sans véritablement répondre)

                    Justement, voici ta phrase:

                    Hors de la remise en cause de vos choix, éviter que l'OOM killer flingue le service qui te sert à le piloter

                    Bon, à la relecture de mon dernier message, je note que je n'ai en effet pas indiqué n'avoir pas de connaissance sur le fonctionnement exact de l'OOM killer, je vais donc te plusser (je m'abstiens généralement, mais, tu est a -1 alors que c'est pertinent).

                    Cela dis, je ne sais plus si j'ai déjà explicité ça, mais l'OOM killer n'interviens jamais, ce qui cause un freeze du système. S'il faisait son boulot de tuer, les services (genre ssh et son tunnel inversé) soit redémareraient, soit seraient toujours exploitables.
                    Ici, je parle de freeze système, parce que l'OOM killer ne fait justement pas son boulot. Peut-être est-ce dû à la configuration par défaut, certes. Je compte vraiment creuser le sujet, je m'intéresse de plus en plus à cette partie qu'en tant que développeur je ne connais que trop: le contrôle des ressources d'un système. C'est plutôt passionnant en plus, connaître un peu mon système a pas mal changé ma façon d'architecturer le code, l'air de rien.

    • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

      Posté par  (site web personnel) . Évalué à 1.

      T'as changé quels paramètres de taille de buffer ? Généralement sur MySQL/MariaDB avec le moteur InnoDB c'est innodb_buffer_pool_size qui bouffe toute la RAM.

      • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

        Posté par  . Évalué à 2.

        J'ai lu les manpages, et essayé divers changements, sans effets actifs, parfois même avec des conflits entre la manpage et le binaire (debian, donc p'tet lié à des patch debian).

        Je me souviens pas, mais j'ai essayé de réduire déjà:

        • le nombre de threads, 15-20 thread/process pour notre usage, c'est un pur gâchis, et chacun consomme son quota;
        • la mémoire par thread;
        • le nombre de requêtes acceptables en parallèle;

        Et autres dont je n'ai plus souvenir: c'était y'a 4-5 mois, et je suis pas dba. Déjà que je dois apprendre à gérer un parc, faire une chiée de scripts, coder en C++ et former mes collègues, le tout sans moi-même être formé… pfiou. Le plus simple sera largement de remplacer ça par un outil plus adapté. Ce qui m'empêche pas de regretter la qualité faible de la doc. Pour le fun, j'essaierai un jour de me faire une vm avec d'autres BDD, et voir si j'arrive à mieux maîtriser l'occupation des ressources système.
        P'tet que je changerais d'avis et que je considérerai mysql comme le fleuron, après ça.

        • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

          Posté par  (site web personnel) . Évalué à 1.

          De mon expérience les paramètres les plus utiles pour limiter la connexion mémoire:

          • innodb_buffer_pool_size: taille du cache global InnoDB, le plus gros consommateur de mémoire
          • max_connections: chaque connexion va utiliser un thread, donc un large nombre de connexion va augmenter la consommation mémoire. Cela peut nécessiter de changer les clients pour limiter le nombre de connexions.

          Mysql/MariaDB c'est pas forcément le SGDB de meilleur qualité ou le mieux documenté, mais c'est clairement le plus populaire.

          • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

            Posté par  . Évalué à 2.

            Comme dit plus haut, le problème ici est surtout que c'était une connerie monstrueuse d'utilise celui-ci dans notre cas. C'est juste pas fait pour.

            Maintenant, essayer de réduire le dégât en attendant le temps de pouvoir migrer vers une vraie solution adaptée, aurait été de lire une doc qui ne mens pas. Ici, la doc m'a, selon moi, menti. Je parle de celle dans les pages de manuel ainsi que celle accessible sur le net, qui ne permets pas, de mémoire, aisément de choisir une version.

            c'est clairement le plus populaire.

            Windows est l'OS le plus populaire. Il a des qualités réelles, mais n'est que rarement choisi pour celles-ci, il est plutôt choisi par habitude plutôt qu'une analyse du plus pertinent pour l'usage. Linux devenant de plus en plus utilisé, nos distros font aussi des choix que je considère dans cette optique.

            • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

              Posté par  (site web personnel) . Évalué à 1.

              Peut-être que le choix de MariaDB est souvent orienté par sa popularité, mais il faut quand même reconnaître qu'il est capable de fonctionner dans des environnements variés.
              Après j'ai l’impression que ton problème vient premièrement du fait que tu as désactivé l'overcommit et pas de MariaDB lui-même, ce qui est un nid à problème en soit :-)

              • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                Posté par  . Évalué à 2.

                Après j'ai l’impression que ton problème vient premièrement du fait que tu as désactivé l'overcommit et pas de MariaDB lui-même, ce qui est un nid à problème en soit :-)

                Comme je l'ai dis, s'il était facile de configurer mariadb pour qu'il ne consomme que ce dont il a réellement besoin, j'aurai pu laisser l'overcommit désactivé, ce qui aurait fait certes crasher un soft à répétitition, mais aurais éviter un reboot physique du système. Et quand ledit reboot nécéssite de faire plus de 300 bornes, ben…

                Bref, le problème est d'une part le fait que l'overcommit fait freeze le système, et d'autre part le fait que mariadb est incapable de fonctionner avec moins de 600Mo de ram sans overcommit, alors qu'en pratique, mariadb n'a pas besoin de toute cette mémoire.

                Enfin, quand je dis que mariadb en est incapable, je veux surtout dire qu'il est extrêmement ardu de le configurer pour qu'il soit vraiment adapté à son environnement réel. Parce que, ben, la doc, elle est… disons, floue, pour être sympa.

                Cela dis, j'ai l'impression a te lire que tu n'as pas lu mes précédentes interventions, parce que j'ai déjà expliqué ces points. J'ai l'impression que tu ne fais que défendre un outil, en disant qu'il s'adapte aux usages, mais tu n'expliques a priori pas les usages ou tu l'as vu fonctionner?

                • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                  Posté par  (site web personnel) . Évalué à 2.

                  J'ai lu tes commentaires, et au départ j'essayais simplement de te conseiller sur quels paramètres changer.
                  J'ai administré des bases de données MySQL dans des serveurs allant de 600 MiB de mémoire à des centaines de GiB. Je trouve qu'un avantage de MySQL et MariaDB est leur versatilité, capable de fonctionner dans des environnements très différents en terme d'usage.
                  Par contre ça reste un SGBD complexe à configurer, on est d'accord, mais tous les SGBD le sont, c'est pour ça que ces formations sont utiles. La doc existe, mais est complexe, mais c'est le cas pour tous les SGBD actuels.

                  • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

                    Posté par  . Évalué à 2.

                    Rassures-toi, je n'ai rien contre toi, comme personne n'a rien contre moi ici, probablement.

                    Les débats sont crus, mais je crois qu'on est dans une communauté ou justement on ne cache pas ses idées, et si on répond en argumentant, c'est bien preuve de respect, non? Même si on peut se perdre, parfois.

                    Le problème ici, est que je ne suis pas DBA, que mysql semble avoir une lib pour l'embarqué, mais, même si mon patron s'en foutrait s'il le savait, ça me ferait agir contre la GPL, et je ne veux pas.
                    Parce que oui, il semble qu'il existe un moyen de faire tourner mysql/mariadb en mode standalone, ce qui serait plus approprié pour notre besoin.

                    J'ai administré des bases de données MySQL dans des serveurs allant de 600 MiB de mémoire à des centaines de GiB. Je trouve qu'un avantage de MySQL et MariaDB est leur versatilité, capable de fonctionner dans des environnements très différents en terme d'usage.

                    C'est un fait, après tout, on arrive a le faire tourner sur des beaglebone black, à 512Mio de RAM.
                    Même avec tout la mauvaise foi du monde, je ne pourrais le lui enlever.

                    c'est pour ça que ces formations sont utiles. La doc existe, mais est complexe

                    L'une des raisons pour lesquelles je cherche a partir de ma boîte, c'est que j'ai bien compris que je sers plus a former des gens sortis de l'école qu'a coder. Et que je n'aurais jamais aucune formation moi-même.

                    mais c'est le cas pour tous les SGBD actuels.

                    Mais certains sont plus faits pour certains usages, et mon coup de gueule originel est plutôt contre le fait que tous les SGBDR veulent se faire croire universels dans leur comm', alors qu'ils sont majoritairement fait pour des machines puissantes. Opinion perso, bien sûr, vu qu'au final, un système avec 512Mio de ram et un CPU arm 1GHz est déjà puissant pour moi, mais il ne suffit pas a respecter les specs recommandées par Debian de mysql/mariadb (vu que, sous debian, mariadb bouffe pas loin de 600Mio de RAM théorique).

Suivre le flux des commentaires

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