> > Je sais pas si le sens en japonais est aussi precis, mais en chinois, > c'est "dent" sans plus de precision (il est employe dans "se brosser les > dents" par exemple). Du coup, j'avais interprete ca en mode "macher les > donnees". J'etais pas si loin. >
Oui c'est l'idée! > Sympa la pres' sinon. > Merci :-) > Mais je me demande (question utile cette fois): Le code est clairement > super modulaire et c'est tres appreciable (c'est le point que tu mets en > avant) mais ruby en soit est pas super rapide pour ce genre d'operations. > Qu'est-ce que ca donne sur des gros volumes de donnees? As-tu des > comparaisons avec d'autres solutions? Est-ce que tu es capable de donner un > ratio "temps d'execution" par rapport aux "gains de productivite" et/ou > "maintenabilite du code"? > La cible est plutôt les datasets de taille moyenne (donc quelques centaines de Mo à quelques Go par "nuit", voire plus selon le type de traitement) que des gros volumes. Cela dit on peut optimiser de plusieurs façons, notamment en détectant les boucles critiques et en déléguant le traitement de certaines choses aux outils pertinents sur ces boucles (ex: utiliser le bulk load de votre database destination, utiliser freebcp pour exporter des gros volumes de données de SQLServer, appeler des outils comme "embulk" à certaines phases du traitement etc), tout en gardant le contrôle du work-flow global avec Ruby ce qui apporte beaucoup de souplesse. On peut également paralléliser le traitement (que ça soit avec un dév custom, lancer N processes, ou encore avec le prototype Kiba Pro d'engine multi-threadé qui permet de lancer le même job en mode multi-cores, efficace même sur MRI lorsqu'on a des tâches qui sont "IO bound"), si c'est pertinent. J'ai remarqué par ailleurs qu'il est fréquent de surestimer le volume à traiter dans nos données (j'avais mentionné ça à Rulu en 2012 dans un autre talk <https://youtu.be/LW863DOXqZQ?t=16m2s>), donc on a parfois de bonnes surprises quant au débit obtenu :-) Pour les cas où le débit brut est absolument essentiel (centaines de Go par jour, To etc), il est préférable d'utiliser d'autres solutions (et je travaille aussi avec d'autres outils que Ruby pour ça, creusant actuellement le big data etc etc). En conclusion, on peut travailler sur des volumes de données de taille raisonnable (notamment dans mon cas, je travaille souvent avec des startups SaaS en B2B, où le ratio "valeur de la data / coût du traitement" est plus important qu'en B2C, et ou les sources de données sont souvent du http où ruby n'est plus le bottleneck), tout en gardant un fort niveau de qualité. J'espère que ça répond correctement à ta question! Thibaut -- http://thibautbarrere.com/ > > 2015-11-10 14:34 GMT+08:00 Thibaut Barrère <[email protected]>: > >> Hello Florian, >> >> J'ai une question inutile. >>> Etant donne que le HanZi veut dire "dent", est-ce le nom que tu voulais >>> donner a ta gem? Si oui, pourquoi? >>> >> >> C'est bien le nom que je voulais donner (enfin plutôt "croc" dont j'ai vu >> souvent que c'était la signification plus précise). >> >> Quand je travaille sur des données, j'ai souvent l'impression qu'il faut >> un peu "tailler dedans", creuser, etc; voilà un peu le lien même s'il n'est >> pas primordial, le nom est court et facile à retenir et ça m'allait bien >> également :-) >> >> -- Thibaut >> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> [email protected] >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse >> [email protected]. >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Railsfrance". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
