OK, OK. Je vais pas répondre à tout, mais dans le désordre...
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.
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.
Dans les orientées colonnes, les times series et les bases de données graphes, tu as un travail de modélisation de tes données au moins aussi important qu'en SQL parce que les techno t'y obligent
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.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
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 :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Tu mélange beaucoup de choses... NoSQL c'est des technologies de base de données, BigData c'est mot-valise qui a était bien trop marketé pour garder encore sont sens de jeu de données trop gros pour entrer dans les bases de données standards
Cet amalgame, 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.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique... Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
(depuis 20 l'évolution étant ce qu'elle est les bases de données classiques ont considérablement augmentée leur capacité et une partie des techniques BigData sont devenues classiques comme le partitionnement).
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.
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.
C'est très discuté parce que relativement peu de techno suivent véritablement cette courbe et quand elles le suivent on parle de période allant de quelques années à 10 ans. Relancer continuellement dessus 20 ans après n'a pas de sens.
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 ?
Cette manière de tout amalgamer pour rejeter c'est un peu comme si je disais que SQL c'était vraiment nul parce que les ORM c'est de la merde.
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 bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 5.
OK, OK. Je vais pas répondre à tout, mais dans le désordre...
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.
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.
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.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
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 :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Cet amalgame, 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.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique... Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
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.
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.
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 ?
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 bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.