Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.
Donc tu parle de contraintes d'intégrité et oui c'est la définition du NoSQL. Mais ce n'est pas arrivé de nulle part. Les mainframes commencent à montrer leur limite de scalabilité, on commence à vouloir créer des services mondiaux et des gens (en particulier Brewer) ont montré que les propriété ACID ne permettaient pas d'avoir à la fois un haut niveau de disponibilité et une tolérance aux problèmes réseaux1. Présenter ce travail comme des gens inconséquents me parait injuste et irrespectueux.
Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.
Ça c'est un avis. Tu as des gens qui font carrière sans en avoir besoin. C'est un peu comme dire que le typage statique on en a toujours besoin sauf quelques cas particulier. Ça n'a pas empêchés un paquet de monde de faire des choses incroyables avec un typage dynamique. Les données n'ont pas intrinsèquement un modèle, c'est l'usage qu'on en fait qui défini comment il est intéressant de les modéliser.
Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.
Quand tu parle de modélisation de données dans une base comme cassandra, tu as une série de ses colonnes qui vont servir à la fois de comment les données sont partitionnées, comment est-ce que tu va pouvoir les requêter et de comment va se comporter leur éventuelle suppression. Ça demande d'avoir une très bonne connaissance de tes données, de ce que tu va en faire et des volumes (à la fois de requête, de volume de données total, mais aussi par partition et de savoir quelle est la stratégie de rétention que vous avez). C'est très loin de ce que tu a l'air d'imaginer.
Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
Ça dépend de ce que tu appel extrêmement rare. Travailler avec plusieurs datacenter, je ne trouve pas que c'est extrêmement rare. Dans les années 2000 les SGBD ne savaient pas gérer des latences fortes entre leurs nœuds. Maintenant ils le font, mais ils ont rognés sur la performance ou la cohérence (on échappe pas au théorème CAP facilement). Et je parle ici de solutions de type fail over ou hot standby, le load balancing ou l'actif-actif multi DC, que je sache, aucun SGBD ne le propose en standard (et les solutions que je connais impliquent d'avoir une base NoSQL à côté des nœuds).
Il me semble que pas mal de monde le fait mais avec un cloud provider qui te cache toute cette difficulté. Quand tu utilise Amazone RDS, ils n'ont pas juste instanciés un pg pour toi, ils ont un énorme travail pour te cacher toute cette complexité.
Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour : [...]
NoSQL n'est qu'un détail dans tout ça. Hadoop contient une base NoSQL et des choses s'approchant de S3. Tu présente ce dernier comme une solution pourtant. Se lancer tête la première dans un truc aussi gros qu'hadoop c'est forcément compliqué, comme ça le serait avec n'importe quelle stack un peu grosse. Il est pourtant possible de ne déployer que ce dont on a besoin d'hadoop et d'avancer progressivement si on en a le besoin. Pour moi dans ce que tu décris c'est la prise de décision « flip the table » plus que la techno qui est un problème.
En plus les SGBDR en 2018 ont énormément évolués par rapport aux années 2010.
Cet amalgame [NoSQL - BigData], il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.
Au vu de ton expérience, je comprends, mais je me fou du discours marketing quand je prends une décision technique. Encore une fois hype et réactance même combat.
Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.
Excuse-moi oui je parlais de partitionnement réseau. Dis autrement de tolérance au partitionnement du cluster.
Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois... quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.
À partir du moment où tu es multi-dc. Si tu as une SLA demandée supérieure à ce que propose un DC par exemple, si ton service est utilisé sur plusieurs timezone et que tu veux des latences assez faible. Mais encore une fois aussi rare que tu l'imagine en quoi ça rend les développeurs de ces solutions inconséquent ?
Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?
Encore une fois je pense que tu mélange beaucoup de choses. Tu parlait du GHC et il y a eu des études dessus et Gartner n'est pas aussi bon que ce que leur théorie cherche à laisser croire. Ça aussi c'est du marketing.
Si c'est une façon de dire que les nouveautés commencent en étant inconnues, puis font l'objet de curiosité avant qu'elles soient assimilées, c'est un peu bateau. Pour ce qui est des blockchain, smartcontracts par exemple il n'existe pas de ce qui ressemblerait à un « plateau de productivité » comme l'annonce la théorie.
Pour les frameworks web si tu prend react par exemple il n'a pas connu de « creux de la désillusion » vu non plus d'ailleurs et angular semble plutôt descendre tranquillement de son apogée vers le fameux « plateau de productivité ». Les autres ? S'ils ont un « sommet des attentes surdimensionnées », alors ça ne touche généralement pas grand monde et ils ne survivent pas à ce qui s'apparenterait au « creux des désillusions ».
Bref la théorie marche quand elle veut bien.
Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.
Et pourquoi tu fais la distinction SQL / mauvais usage via un ORM ? Mais pas NoSQL / mauvais usages ?
Mais j'hésite pas une seconde si je pense que c'est le bon outil.
Très bien, mais quand tu présentent les créateurs de ces techno comme des gens inconséquent tu ne donne pas l'impression d'avoir cette hauteur (et d'autant plus quand tu mélange allègrement hadoop et nosql par exemple).
tu as eu plus tard les new-sql qui ignorent se problème en utilisant des horloges atomiques, l'idée étant que si chaque nœud peut faire confiance en l'horodatage les uns des autres, il est plus facile de se mettre d'accord. ↩
[^] # Re: Tout se paye un jour ou l'autre
Posté par barmic 🦦 . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4. Dernière modification le 24 décembre 2023 à 16:42.
Donc tu parle de contraintes d'intégrité et oui c'est la définition du NoSQL. Mais ce n'est pas arrivé de nulle part. Les mainframes commencent à montrer leur limite de scalabilité, on commence à vouloir créer des services mondiaux et des gens (en particulier Brewer) ont montré que les propriété ACID ne permettaient pas d'avoir à la fois un haut niveau de disponibilité et une tolérance aux problèmes réseaux1 . Présenter ce travail comme des gens inconséquents me parait injuste et irrespectueux.
Ça c'est un avis. Tu as des gens qui font carrière sans en avoir besoin. C'est un peu comme dire que le typage statique on en a toujours besoin sauf quelques cas particulier. Ça n'a pas empêchés un paquet de monde de faire des choses incroyables avec un typage dynamique. Les données n'ont pas intrinsèquement un modèle, c'est l'usage qu'on en fait qui défini comment il est intéressant de les modéliser.
Quand tu parle de modélisation de données dans une base comme cassandra, tu as une série de ses colonnes qui vont servir à la fois de comment les données sont partitionnées, comment est-ce que tu va pouvoir les requêter et de comment va se comporter leur éventuelle suppression. Ça demande d'avoir une très bonne connaissance de tes données, de ce que tu va en faire et des volumes (à la fois de requête, de volume de données total, mais aussi par partition et de savoir quelle est la stratégie de rétention que vous avez). C'est très loin de ce que tu a l'air d'imaginer.
Ça dépend de ce que tu appel extrêmement rare. Travailler avec plusieurs datacenter, je ne trouve pas que c'est extrêmement rare. Dans les années 2000 les SGBD ne savaient pas gérer des latences fortes entre leurs nœuds. Maintenant ils le font, mais ils ont rognés sur la performance ou la cohérence (on échappe pas au théorème CAP facilement). Et je parle ici de solutions de type fail over ou hot standby, le load balancing ou l'actif-actif multi DC, que je sache, aucun SGBD ne le propose en standard (et les solutions que je connais impliquent d'avoir une base NoSQL à côté des nœuds).
Il me semble que pas mal de monde le fait mais avec un cloud provider qui te cache toute cette difficulté. Quand tu utilise Amazone RDS, ils n'ont pas juste instanciés un pg pour toi, ils ont un énorme travail pour te cacher toute cette complexité.
NoSQL n'est qu'un détail dans tout ça. Hadoop contient une base NoSQL et des choses s'approchant de S3. Tu présente ce dernier comme une solution pourtant. Se lancer tête la première dans un truc aussi gros qu'hadoop c'est forcément compliqué, comme ça le serait avec n'importe quelle stack un peu grosse. Il est pourtant possible de ne déployer que ce dont on a besoin d'hadoop et d'avancer progressivement si on en a le besoin. Pour moi dans ce que tu décris c'est la prise de décision « flip the table » plus que la techno qui est un problème.
En plus les SGBDR en 2018 ont énormément évolués par rapport aux années 2010.
Au vu de ton expérience, je comprends, mais je me fou du discours marketing quand je prends une décision technique. Encore une fois hype et réactance même combat.
Excuse-moi oui je parlais de partitionnement réseau. Dis autrement de tolérance au partitionnement du cluster.
À partir du moment où tu es multi-dc. Si tu as une SLA demandée supérieure à ce que propose un DC par exemple, si ton service est utilisé sur plusieurs timezone et que tu veux des latences assez faible. Mais encore une fois aussi rare que tu l'imagine en quoi ça rend les développeurs de ces solutions inconséquent ?
Encore une fois je pense que tu mélange beaucoup de choses. Tu parlait du GHC et il y a eu des études dessus et Gartner n'est pas aussi bon que ce que leur théorie cherche à laisser croire. Ça aussi c'est du marketing.
Si c'est une façon de dire que les nouveautés commencent en étant inconnues, puis font l'objet de curiosité avant qu'elles soient assimilées, c'est un peu bateau. Pour ce qui est des blockchain, smartcontracts par exemple il n'existe pas de ce qui ressemblerait à un « plateau de productivité » comme l'annonce la théorie.
Pour les frameworks web si tu prend react par exemple il n'a pas connu de « creux de la désillusion » vu non plus d'ailleurs et angular semble plutôt descendre tranquillement de son apogée vers le fameux « plateau de productivité ». Les autres ? S'ils ont un « sommet des attentes surdimensionnées », alors ça ne touche généralement pas grand monde et ils ne survivent pas à ce qui s'apparenterait au « creux des désillusions ».
Bref la théorie marche quand elle veut bien.
Et pourquoi tu fais la distinction SQL / mauvais usage via un ORM ? Mais pas NoSQL / mauvais usages ?
Très bien, mais quand tu présentent les créateurs de ces techno comme des gens inconséquent tu ne donne pas l'impression d'avoir cette hauteur (et d'autant plus quand tu mélange allègrement hadoop et nosql par exemple).
tu as eu plus tard les new-sql qui ignorent se problème en utilisant des horloges atomiques, l'idée étant que si chaque nœud peut faire confiance en l'horodatage les uns des autres, il est plus facile de se mettre d'accord. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll