FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 18

utilise redis ( http://jster.net/blog/mienfield-author-interview mais bon il utilise aussi node

à mon avis les zset de redis sont pertinents pour ce cas,
(perso je maintiendrais plutôt moi même les listes dans le code et utiliserais redis pour le load save

Tron (./510) :
Hadoop ?

bien connu pour son faible temps de réponse ^^

Sinon, nosql veut dire à peu près tout et rien (sauf une chose : t'es has been, maintenant il faut faire du big machine deep data learning, rien que pour le swag), et beaucoup de critères vont d'abord dépendre de ta volumétrie. Si elle reste assez faible, n'importe quelle techno (y compris SQL) fera l'affaire, et d'autres critères vont primer (par exemple le fait de déjà maîtriser la techno, ou le fait qu'elle soit déjà utilisée dans le même projet pour ne pas déployer une autre bdd rien que pour ce besoin).

Sans connaître tes autres contraintes, Redis est pensé pour ce genre de besoins et est facile à déployer, ça pourrait être un bon choix.

Brunni (./509) :
Je dois choisir un système de DB pour faire une sorte de leaderboard (garder les users plus actifs sur un jour, semaine, mois). Il y a des contraintes supplémentaires et je peux faire part à la team d'engineering de limitations aussi, en fonction de ce qui prend sens techniquement. Mais j'ai aucune idée de sur quoi partir et sur comment chercher. Je lis depuis quelques heures les yeux vides, et chacun ont leurs use cases mais je ne vais pas trouver un site qui me dit "si vous voulez faire un leaderboard faut prendre redis".
Ce truc m'enseigne raisonnablement que je ferais mieux de passer sur du NoSQL (ça tombe bien on est déjà sur Mongo), mais après…
Vous avez des expériences à partager ?

Pas personnellement, mais:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

Je ne connais pas tes besoins précis, mais si tu as besoin de classer tes utilisateurs sur des fenêtres de temps, tu pourrais peut-être te tourner vers une base Time Series (ex: InfluxDB) ou un truc un peu moins spécifique à ce cas comme elasticsearch. Dans les deux cas, tu pourras calculer tes données en semi temps réel. (Elasticsearch à un délai d'indexation des documents qui peut varier selon la charge)

Quoi qu'il en soit, ce dont tu as besoin, et les contraintes supplémentaires que tu ajouteras, dépendent de ta volumétrie et de tes besoins annexes. Chaque système à ses avantages et inconvénients.

Kevin Kofler (./513) :
Pas personnellement, mais:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

En effet, une base non-relationnelle et orientée document n'est pas terrible pour faire du relationnel. Mais là, ça veut simplement dire que l'équipe de Diaspora n'est pas capable d'analyser son propre besoin, ce n'est pas le problème de MongoDB.
Les trams ne sont pas terribles pour traverser l'Atlantique, ça ne remet pas en cause leurs autres qualités.

GC > ElasticSearch ? pour moi c'est quand même orienté indexation plein-texte, non ?

En bref, une BDD SQL peut ramer à fond sous certaines utilisations, une solution spécialisée est plus rapide, mais devient inutilisable dès que les contraintes changent. Toutes les solutions suxent à mort.

flanker > En fait c'est orienté indexation mais pas plus spécifiquement full-text qu'autre chose. Après ouais c'est orienté recherche/agrégation, mais du peu que j'ai compris, ça pourrait coller. Il est capable de te prendre une liste de documents (ex: des événements) sur une plage de dates, de te sommer certains champs et de trier comme il faut… Tu dois logiquement pouvoir t'en servir pour faire un genre de leaderboard.

Merci de vos réponses! Oui, ElasticSearch et Redis semblent adaptés, c'est ce que j'ai entendu. Mais ce qui m'intéresse c'est la démarche. Il y a tellement de systèmes de DB et quand tu lis une page comme http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html (qui est en fait vieille maintenant que je vois l'URL), difficile d'en sortir "c'est celui-là que je veux". Je serais curieux de savoir selon quelle démarche tu peux choisir un système de DB, à moins d'être un expert et d'avoir un peu tout testé bien sûr.

Brunni (./518) :
Merci de vos réponses! Oui, ElasticSearch et Redis semblent adaptés, c'est ce que j'ai entendu. Mais ce qui m'intéresse c'est la démarche. Il y a tellement de systèmes de DB et quand tu lis une page comme http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html (qui est en fait vieille maintenant que je vois l'URL), difficile d'en sortir "c'est celui-là que je veux". Je serais curieux de savoir selon quelle démarche tu peux choisir un système de DB, à moins d'être un expert et d'avoir un peu tout testé bien sûr.

déjà, contrairement à ce qu'on lit souvent, il ne faut surtout pas exclure les bases SQL classiques, surtout PosgreSQL qui s'est améliorée pour ajouter des fonctions qu'on trouvait plutôt dans les noSQL à la base. En terme de perfs, tu peux avoir des surprises.
Ensuite, la dimension du besoin est vraiment importante. Certaines solutions ont été conçues pour les besoins de Google ou Facebook (au prix de grosses contraintes, parfois), et si tu n'as pas leurs besoins, elles n'ont pas spécialement d'intérêt.
Après, c'est moins vrai maintenant, mais il y a quelques années, la plupart de ces bases n'étaient pas forcément super stables et plantaient facilement ; je me souviens notamment d'un motif d'insertion/lecture/suppression dans du Cassandra qui me permettait d'écrouler un petit cluster de test de 70 cœurs en un quart d'heure (et parfois, les données étaient corrompues après le plantage \o/). Pour d'autres usages, ça tenait parfaitement.

Le truc c'est qu'on peut tout faire avec une base SQL, mais c'est pas toujours suffisamment performant (ça dépend de la volumétrie, parfois ça scale très mal (ça dépend là aussi), et il arrive fréquemment que la modélisation relationnelle soit plus un problème qu'une solution. (i.e. quand ça n'apporte rien de positif: les objects)
En réalité, la base SQL c'est un peu le couteau suisse de la base de données. Si c'était vraiment naze, ça ferait longtemps qu'on aurait arrêté de s'en servir, et si c'était meilleur que tout, on aurait pas inventé d'autres types de bases de données qui sont bien plus avantageux dans des cas spécifiques. (Tout comme un couteau suisse est un outil génial quand tu pars en pique nique, randonnée ou camping, chez toi tu es bien mieux loti avec un tire-bouchons et un couteau d'office)

Pour ce qui est de choisir un système NoSQL, il faut garder en tête qu'il n'existe pas de solution universelle. Il y a plein de types de systèmes (relationnal, document storage, key-value store, graph, time series database, moteur de recherche, …) et beaucoup de recoupement entre chacun des types. La plupart des systèmes SQL/NoSQL rentrent dans plusieurs de ces typologies sans forcer, mais ils sont toujours meilleurs dans l'une d'entre elles par rapport aux autres.
Pour faire ton choix, tu dois être capable d'identifier ce que tu veux faire de ta donnée et vers quel(s) type(s) de système tu voudrais te tourner en conséquence. Puis, tu dois prendre en compte ta volumétrie et les performances attendues. Déterminer si ça doit être scalable horizontalement ou verticalement (ou les deux). Prendre en compte les systèmes dont tu disposes déjà et que tu maîtrises bien (ex: une base SQL). Te renseigner ce qui se fait de mieux au niveau du type de système dont tu aurais besoin. Et là alors, tu peux peut-être arriver à faire le bon choix

(PS: ça vous dit de forker ?)

(vous pouvez continuer ici, perso ça ne me dérange pas )

(je vote aussi pour un fork )

Merci de l'explication GC, c'est clair c'est cool mais bon……… je n'ai aucune idée de tout ça, ni ordre de grandeur etc.
Sympa la comparaison entre SQL et le couteau Suisse

(un digress à la rigueur, mais c'est mon dernier mot )

(Après 10 gress ce sera postgress ? )

( )

La semaine dernière j'ai voulu regarder Roseta Stone si ça valait le prix, mais après le test j'ai vu que ça ressemblait à du duolingo, mais payant, donc pas intéressé, et depuis ils m'envoient 3 emails par jour pour me pousser à m'inscrire. Je viens de me désinscrire (j'aurais pu le faire avant), mais c'est moyen comme méthode...

Tu veux apprendre quelle langue ?

Zerosquare (./528) :
Tu veux apprendre quelle langue ?

Je voulais me remettre au Chinois, mais même si duolingo n'a pas le mandarin, il y a plein d'apps qui sont des clones, juste pour le Chinois, et c'est gratuit ^^

Je pensais que tu le parlais déjà ^^

Non il parle le Sionihc

Et si je faisais une base SQL qui ne contenait que des clés primaires, clés étrangères, et un champ à chaque table qui contenait le blob de données d'une base NoSQL, est-ce que j'aurais réuni les deux mondes avec efficacité ?

Mais de quel "blob de données" parles-tu ?

Brunni > Fait un tour du côté de BerkeleyDB, c'est quand même sacrément robuste...

Meowcate (./532) :
Et si je faisais une base SQL qui ne contenait que des clés primaires, clés étrangères, et un champ à chaque table qui contenait le blob de données d'une base NoSQL, est-ce que j'aurais réuni les deux mondes avec efficacité ?

Euh non, pas vraiment. Si tu stockes tes données sous forme de blobs, tu t'enlèves la possibilité de faire des requêtes SQL sur les données dans le blob. Il peut souvent être intéressant de faire des requêtes sur autre chose qu'une clé.

je vote contre le fork, !yn ftw

Fait un tour du côté de BerkeleyDB, c'est quand même sacrément robuste...

"Robuste" n'est pas le mot que j'aurais employé pour une DB publiquement documentée comme capable de se DoSser toute seule en corrompant les fichiers sans aide extérieure, ou d'être DoSsée par la corruption des données sur le FS
30 CVE corrigés sur la dernière année, dont 27 de CVSSv2 6.9 / CVSSv3 7.8.

La maintenance de BDB est un gros problème dans les distros Linux:
* beaucoup de packages, y compris des packages importants, en dépendent transitivement;
* la licence AGPL des Berkeley DB 6.x fait que cette série de versions n'est que marginalement packagée, parce que devenue incompatible avec quantité de programmes qui avaient l'habitude d'utiliser BDB;
* les Berkeley DB 5.x, encore sous licence Sleepycat, ne sont pas (publiquement) maintenues;
* les bugfixes récents apportés par Oracle ne peuvent pas être backportés pour les raisons de licence sus-mentionnées - bref, les distros Linux utilisent "toutes" des versions passoires;

Et d'un point de vue utilisateur, je sais que quand il a fait une version spéciale filtrage off-memory, pour pouvoir gérer des datasets plus gros, l'auteur de msieve s'est fait nettement ***** pour paramétrer BDB pour son use case. Ca s'apparentait à du combat.

En résumé, je conseille de faire bien attention avant de s'enfermer avec BDB, pour quelque utilisation que ce soit

Mnesia ?

Lionel Debroux (./537) :
"Robuste" n'est pas le mot que j'aurais employé pour une DB publiquement documentée comme capable de se DoSser toute seule en corrompant les fichiers sans aide extérieure, ou d'être DoSsée par la corruption des données sur le FS

Ah ? Tiens, je suis passé à côté de ça...
(Sinon, 30CVE c'est pas exceptionnel, j'ai l'impression... c'est beaucoup, mais ça me paraît dans la moyenne).

Après, ce que je trouve le plus chiant, c'est que le changement de version majeure s'accompagne quasi systématiquement d'une opération de rebuild de la base.

Meow: pense a ajouter des clefs secondaires et terciaires!!!