Posté par case42 .
En réponse au journal NoSQL ou pas ?.
Évalué à 4.
Dernière modification le 30 avril 2012 à 11:40.
Je ne suis pas du tout expert en la matière mais voici tout de même quelques data points qui peuvent être intéressants.
Y a deux ans on utilisait Django+Postgres , et on a voulu essayer Django+NoSql (je sais plus laquelle, probablement couchdb) parce que le coté schema-less avait l'air de bien coller avec nos méthodes de développement agiles, ou plutôt, le paradigme "a schéma" de sql venait tout le temps nous ralentir parce qu'on changeait tout le temps de schéma, et donc on voulait voir si l'herbe était plus verte en face. A l'époque, c'était pas le cas, et on est vite vite revenu chez mémé.
Plus tard, on a bazardé Django et Postgres et on est passé a Node.js sans base de donnée du tout (pour ceux qui suivent pas, on fait un serveur de jeu temps-réel). Un beau jour on a voulut commencer a collecter des statistiques sur nos parties, et je me suis dit qu'une base NoSql serait pas mal pour ca. Donc j'ai mis en place une couchdb, et avec quelques lignes dans le serveur (sans même rajouter un module dédié vu que c'est une API REST) , celui-ci pousse un gros document JSON avec toutes les données de la partie dans le couchdb.
Ça avait été rapide et facile, j'étais plutôt content. Plus tard je me suis mis écrire des "vues" couchdb pour commencer a faire remonter des infos intéressantes du couchdb. Ça a été un peu galère au début, mais globalement j'ai réussi a faire ce que je voulais faire sans trop souffrir ( et quand t'écris ta première vue map/reduce qui marche, t'es content ;) ).
Et puis un jour, ca c'est mis a plus marcher. Le serveur continuant et bourrer la DB de documents, mais toutes les vues étaient cassées. A force de recherche je me suis rendu compte que suite a un changement dans le serveur, les documentes envoyées dans la DB avaient beaucoup grossis et dépassaient une limite interne de couchdb. Il fallut que j'applique un patch trouve au fin fond d'une obscure mailing-list pour que ca remarche. Autant dire que c'était pas très agréable et que ca donne pas énormément confiance.
Depuis ca re-marche bien sans aucun problème, si ce n'est un problème de performance qui était causé par la façon naïve dont j'avais écrit une de mes vues, un passage par #couchdb sur freenode a résolut le problème en quelques minutes.
Si c'était a refaire, je le referais, sauf que je pense que je prendrais plus de temps a peser le pour et le contre entre couchdb et mongodb . Je pense que mongodb aurait été plus adapté a cette application ou on ne fait que "bourrer" une DB de documents sans jamais les updater , mais j'aurais été obligé de rajouter une dépendance a mon serveur vu que mongodb n'a pas d'API REST.
# Mon expérience...
Posté par case42 . En réponse au journal NoSQL ou pas ?. Évalué à 4. Dernière modification le 30 avril 2012 à 11:40.
Je ne suis pas du tout expert en la matière mais voici tout de même quelques data points qui peuvent être intéressants.
Y a deux ans on utilisait Django+Postgres , et on a voulu essayer Django+NoSql (je sais plus laquelle, probablement couchdb) parce que le coté schema-less avait l'air de bien coller avec nos méthodes de développement agiles, ou plutôt, le paradigme "a schéma" de sql venait tout le temps nous ralentir parce qu'on changeait tout le temps de schéma, et donc on voulait voir si l'herbe était plus verte en face. A l'époque, c'était pas le cas, et on est vite vite revenu chez mémé.
Plus tard, on a bazardé Django et Postgres et on est passé a Node.js sans base de donnée du tout (pour ceux qui suivent pas, on fait un serveur de jeu temps-réel). Un beau jour on a voulut commencer a collecter des statistiques sur nos parties, et je me suis dit qu'une base NoSql serait pas mal pour ca. Donc j'ai mis en place une couchdb, et avec quelques lignes dans le serveur (sans même rajouter un module dédié vu que c'est une API REST) , celui-ci pousse un gros document JSON avec toutes les données de la partie dans le couchdb.
Ça avait été rapide et facile, j'étais plutôt content. Plus tard je me suis mis écrire des "vues" couchdb pour commencer a faire remonter des infos intéressantes du couchdb. Ça a été un peu galère au début, mais globalement j'ai réussi a faire ce que je voulais faire sans trop souffrir ( et quand t'écris ta première vue map/reduce qui marche, t'es content ;) ).
Et puis un jour, ca c'est mis a plus marcher. Le serveur continuant et bourrer la DB de documents, mais toutes les vues étaient cassées. A force de recherche je me suis rendu compte que suite a un changement dans le serveur, les documentes envoyées dans la DB avaient beaucoup grossis et dépassaient une limite interne de couchdb. Il fallut que j'applique un patch trouve au fin fond d'une obscure mailing-list pour que ca remarche. Autant dire que c'était pas très agréable et que ca donne pas énormément confiance.
Depuis ca re-marche bien sans aucun problème, si ce n'est un problème de performance qui était causé par la façon naïve dont j'avais écrit une de mes vues, un passage par #couchdb sur freenode a résolut le problème en quelques minutes.
Si c'était a refaire, je le referais, sauf que je pense que je prendrais plus de temps a peser le pour et le contre entre couchdb et mongodb . Je pense que mongodb aurait été plus adapté a cette application ou on ne fait que "bourrer" une DB de documents sans jamais les updater , mais j'aurais été obligé de rajouter une dépendance a mon serveur vu que mongodb n'a pas d'API REST.