NoSQL - Page 1

Hello,

Y a-t-il des gens ici qui font du noSQL ? Je n'arrive pas vraiment a voir dans quel cas ca pourrait m'etre utile. Je viens de lire cet article : http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Et ca me rappelle le probleme qu'on a eu il y a 3 ans dans la boite ou j'etais, on avait le feed de notre reseau social genere avec redis, et c'etait totalement la merde. Redis nous servait de cache en fait, donc on avait toujours mysql, mais on s'est vite retrouve avec des problemes.

Donc auqnd les db nosql sont-elles pratiques pour une application web ?

Une base NoSQL, en l'occurrence Redis, est une des technos de base du système (qui n'est pas une appli Web) sur laquelle la petite équipe dans laquelle je suis a travaillé depuis le printemps 2011. Je suis un de ceux qui ont le moins interagi avec Redis, ceci dit.
Comme vous avez dû le voir, Redis est fait pour stocker des types de données simples: hashes clé-valeur, sets, etc. Et les footprints disque, RAM et CPU de Redis sont beaucoup plus faibles que ceux des principaux SGBDR, donc c'est plus sympa pour l'embarqué.

MongoDB n'était pas une possibilité pour nous car le code ne prête aucune attention au désalignement des accès (du moins, c'était le cas en 2011, 2012 et encore 2013, je vérifiais de temps en temps), ce qui le rend donc peu portable, sans modifs non officielles pas souvent mises à jour, hors des x86/x86_64. Or, on voulait pouvoir tourner notamment sur des ARM < v7.

Pour les traitements où il y a beaucoup de relations entre éléments, les bases de données relationnelles restent plus adaptées, bien sûr. Il y en a pour toutes les tailles: MySQL/MariaDB, PostgreSQL, Oracle, SQLite3.
Et pour les séries temporelles, il y a d'autres bases de données plus adaptées que Redis.

C'est moi, ou même l'exemple de "bonne" utilisation qu'ils donnent dans l'article [les séries TV] est en fait mauvais ? Je veux dire, avec leur modèle et une solution non-relationnelle, comment on fait un truc aussi basique qu'obtenir la liste des séries dans lesquelles un acteur a joué ? C'est le premier truc qui m'a frappé, et si c'est déjà apparent sur un exemple simple, ça l'est d'autant plus pour un réseau social. Après, j'y connais quasiment rien en BDD, donc je passe peut-être à côté de quelque chose
EDIT : ah ben tiens, j'avais pas lu la fin de l'article :

About three months into development, it was still humming along nicely on MongoDB. One Monday, at the weekly planning meeting, the client told us about a new feature that one of their investors wanted: when they were looking at the actors in an episode of a show, they wanted to be able to click on an actor’s name and see that person’s entire television career. They wanted a chronological listing of all of the episodes of all the different shows that actor had ever been in. (...) The client expected this feature to be trivial. If the data had been in a relational store, it would have been. As it was, we first tried to convince the PM they didn’t need it. After that failed, we offered some cheaper alternatives, such as linking to an IMDB search for the actor’s name. The company made money from advertising, though, so they wanted users to stay on their site rather than going off to IMDB.
This feature request eventually prompted the project’s conversion to PostgreSQL.

Et donc, des spécialistes du dév web/BDD n'avaient même pas envisagé une évolution aussi évidente à la conception ? Je vais être méchant, mais ils m'ont pas l'air très expérimentés...

Je pense que l'idée était de faire un site vraiment "sur mesure" qui maximise l'économie de ressources et la scalabilité.
Ma boîte a conçu une grosse appli professionnel en PHP pour un client important. Nous avons beaucoup travaillé sur la communication et essayé de rendre cela au plus proche de leurs besoins. L'un des principes de KISS est de choisir la solution la plus adaptée, et non de réfléchir à ce que le client pourrait vouloir de plus à l'avenir (je ne dis pas pour autant que c'est une mauvaise approche).
Un an plus tard, il nous envoie une demande de v2 où nous avons beaucoup modifié ça et là, depuis qu'il voulait du "tout interactif et sans rechargement". Après avoir collé deux ou trois patchs AJAX à la grande majorité des pages, nous nous sommes rendus compte que si le client avait pu anticiper ses besoins (et ce n'est pas à nous de savoir qu'il veut des modifications du comportement de l'UI), une grande partie du travail aurait pu être fait en Angular, nous économisant bien du travail et surtout de la future maintenance.

J'ai d'ailleurs tendance à remarquer qu'on pense que les devs web peuvent modifier leurs applications en un claquement de doigts du client, tandis qu'on juge qu'une appli non-web nécessite du travail et du recul.
J'imagine que passer des INT aux BIGINT pour les vues de Youtube a dû se faire sans embarras. Après tout, c'est juste le type de données à changer dans une colonne, non ?

Meowcate (./4) :
Je pense que l'idée était de faire un site vraiment "sur mesure" qui maximise l'économie de ressources et la scalabilité.

Certes. Mais quand tu as un minimum d'expérience, tu peux prévoir d'avance certaines pistes d'évolutions auxquelles le client n'a pas encore pensé, et en parler dès le début (en lui faisant bien comprendre que s'il veut un truc optimisé aux petits oignons pour sa demande initiale, le travail et le coût de modification seront importants si la demande change par la suite).

Meowcate (./4) :
J'ai d'ailleurs tendance à remarquer qu'on pense que les devs web peuvent modifier leurs applications en un claquement de doigts du clie

[mauvaise langue]
À force de dire des choses comme "on suit la méthodologie Agile, inutile de réfléchir à tout dès le début, on adaptera au fur et à mesure" et "oh une nouvelle technologie qui vient de sortir, pas finie et sur laquelle il n'y a aucun recul, dépêchons-nous de l'utiliser partout pour pas être ringards", faut pas vous étonner de récolter ce que vous semez, hein
[/mauvaise langue]

Meowcate (./4) :
tandis qu'on juge qu'une appli non-web nécessite du travail et du recul.

Tu parles, ouais. Tous les clients veulent pouvoir changer d'avis comme de chemise, et s'offusquent quand tu leur expliques que ça va nécessiter du travail supplémentaire (j'ai déjà du mal à leur faire comprendre ça pour de l'électronique, qui est quelque chose qui existe physiquement, alors pour du soft...)

Ca me fait penser à mon patron dans la boîte où je suis maintenant qui m'a dit qu'il voulait pouvoir tout changer (sur notre site principal) tous les 2 mois s'il a envie. Je suis le seul développeur, et quand je lui explique que j'ai pas envie de me presser pour ne pas faire de mauvais choix, il ne comprend pas ^^

Zerosquare (./3) :
Et donc, des spécialistes du dév web/BDD n'avaient même pas envisagé une évolution aussi évidente à la conception ? Je vais être méchant, mais ils m'ont pas l'air très expérimentés...

Pour moi, par défaut, il faut prendre du SQL (et si possible du PostgreSQL #troll# ).Et si jamais on a de bonnes raisons pour passer à du noSQL, on reste quand même sur du SQL. On ne passe au noSQL que si on n'a absolument pas le choix.
Après, le noSQL est un vaste monde, avec beaucoup de solutions très différentes, dont certaines sont intéressantes : bases hiérarchiques (LDAP), bases de données orientées graphe (difficile de calculer un chemin de longueur 5 ou 6 avec une base SQL), ou bases de données qui acceptent des grosses volumétries (contrairement à du SQL qui restera toujours très limité en taille), bases de données clef-valeurs qui seront plus performantes (pour faire du cache).

(ça serait pas mieux dans la section appropriée ?)

mm si, ca peut etre deplace ^^

./6 tout pareil. On m'a demandé si il n'existait pas un framework php

-qui permette de manipuler l'interface comme "avec java et wxwidgets"
-qui soit utilisable en prod
-qui soit donc facile à développer selon les besoins du marketing
-qui face des camemberts et tout en ajax, beaux interactifs et customisables
-le tout avec des données réelles venant d'une base
-et hébergé chez nous.

ben... on a pas trouvé!

GWT n'a pas convaincu (moche) et google charts n'est utilisable qu'online.

si y'a des volontaires, y'a ptet un créneau à prendre

GWT est également plus ou moins abandonné par Google, non ? J'ai l'impression que ça vivote plus qu'autre chose… Ça fait un an que la version 3.0 est censée sortir, par exemple.

On voit qu'on tâtonne quand même encore beaucoup autour de la persistance de données, même en 2014. NoSQL ne veut pas dire grand chose, c'est simplement que pendant longtemps on a cru avoir résolu le problème avec une approche assez puissante pour couvrir l'essentiel des cas d'utilisation. On a appelé ça SQL, c'était cool parce que ça permettait d'avoir un standard et donc d'avoir plusieurs produits presque interchangeables plutôt que de devoir s'enfermer dans une seule solution. Et avec le recul, c'était certainement une étape fondamentale.

Malheureusement le problème n'est pas totalement résolu, depuis quelques années c'est l'explosion des sites qui ont envie de faire des analyses comportementales de leurs utilisateurs (pour moi c'est surtout ça qui a lancé le besoin), et autres traitements qui ont besoin de manipuler *beaucoup* de données (désolé, j'ai dit "big data", un blâme pour moi) avec des contraintes que des bases SQL n'ont pas été conçues pour gérer. On se retrouve avec plein de nouvelles approches très différentes, certaines beaucoup plus simples et bas niveau que SQL, d'autres d'une complexité équivalente mais qui offrent d'autres possibilités (si on sacrifie des contraintes comme ACID, ou qu'on s'autorise des résultats approximés statistiquement plutôt qu'exacts, on peut faire des gros gains par ailleurs).

Mais tout ça n'en est encore qu'au début. On est en train de comparer SQL, qui est une solution très mature mais ne répond pas à tous les problèmes, à plein de choses très jeunes et très différentes qu'on regroupe toutes sous l'appellation floue "NoSQL". Certaines vont peut-être faire leur preuve et évoluer pour devenir des alternatives crédibles à SQL, la majorité va surement mourir (et MongoDB semble bien parti pour être dans la seconde catégorie). En attendant d'y voir plus clair, je suis tout à fait d'accord avec Flan : à moins de n'avoir vraiment aucune autre solution et de vouloir faire le pari de se baser sur une solution NoSQL, j'ai l'impression qu'il est encore un peu tôt pour se permettre de reposer dessus dans le monde professionnel, surtout si c'est pour un client et non pour soi.

Tiens, pour moi le besoin est arrivé avant l'analyse comportementale (qui pouvait se faire en batch), il est plutôt lié au big data (mais le vrai, celui avec plein de données) avec des besoins souvent simples (récupérer tous les messages d'une personne, tous les likes, etc.) mais énormes (dont très peu de boîtes concernées : Facebook, Twitter, Google). Faudrait que je regarde l'historique de ces bases, finalement je ne le connais pas tant que ça.

Après, un gros effet de mode, avec des gens qui pensent que comme la base n'est pas forcément structurée, il n'y a plus besoin de réfléchir au modèle de données, on peut benner en vrac toutes les infos dans la base et que ça marchera super bien. En pratique, c'est le contraire : quand on ne sait pas trop, il vaut mieux partir sur du SQL, le noSQL est vraiment pour des besoins spécifiques (d'où la multiplicité des bases : elles correspondent toutes à un besoin différent et très précis, vu que chaque boîte avait ses propres contraintes).

Au passage, le SQL classique évolue lui aussi ; en tout cas PostgreSQL qui permet maintenant certaines fonctions qui viennent du noSQL : stockage de documents JSON avec indexations de clefs, cartouche géo, …
J'espère qu'ils feront une évolution vers les graphes.
Comme Zeph, je pense qu'il y aura beaucoup de ménage dans les solutions existantes, et celles restantes seront vraiment intéressantes quand il y a énormément de données (les bases classiques pouvant faire le choix d'avoir des modes sans ACID).

flanker (./13) :
des gens qui pensent que comme la base n'est pas forcément structurée, il n'y a plus besoin de réfléchir au modèle de données, on peut benner en vrac toutes les infos dans la base et que ça marchera super bien.

Ah la la le classique. Alors que au contraire, c'est précisément quand le solution n'impose pas de structure qu'il est particulièrement important de bien réfléchir à comment on va structurer. De fait, en n'ayant pas de contrainte on a plus de possibilités et plus de manières de mal faire.

Sinon oui c'est pas mal de voir un peu de mouvement sur les bases traditionnelles. Chacun son truc, mais perso un truc qui m'a fait bien plaisir ça a été l'ajout de ICU à PostgreSQL. On peut réutiliser ORDER BY, plus obligé de tout trier dans l'appli.