lundi 31 août 2015

MongoDB c'est bien , mais ...


Depuis quelques temps j'utilise mongoDB, une base de donnés NoSQL pour un projet personnel. Je ne suis pas un expert en BD mais je voulais quand même partager mon avis sur cet outil, dans l'espoir d'en apprendre certainement un peu plus encore via des retours de lecteurs...

Pourquoi mongoDB?

Tout d'abord je tiens a préciser que même si j'adore manipuler des concepts abstraits, j'ai en général une approche très pragmatique des choses. Le choix de mongoDB pour mon projet c'est donc fait sur ces critères, c'est tout :
  • C'est du NoSQL (et je voulais voir l'intérêt du NoSQL)
  • C'est un projet "mature"
J'avoue n'avoir pas fait plus d'étude de marché que ça, car de toutes façon je pense que c'est en utilisant une techno' qu'on se rend vraiment compte de ses qualités et défauts...

Pour faire quoi ?

Sans rentrer dans les détails de mon projets, je collecte des données sur Twitter. Voici quelques éléments pour se faire une idée de l'ordre de grandeur des données, collectées en 3 semaines :
  • 5,4 Millions de Tweets
  • 770 milliers de profils Twitter (ainsi que leur liste d'abonnements, c'est à dire de quelques centaines à quelques milliers d'identifiants de comptes pour chaque profil.)
Ça tourne sur un serveur de chez Online sous Ubuntu. (~16€/mois, cliquez sur le lien pour voir les spécifications du serveur.)

Les "plus" de mongoDB

Voici ce que j'ai apprécié dans l'utilisation de mongoBD:
  • C'est un projet mature , ce qui veux dire qu'on trouve plein de "driver" (moyen de se connecter à la base pour y mettre ou récupérer des données.). J'ai même trouvé un driver en Lua,  ;) c'est dire ....
    On trouve aussi un tas d'aide sur stack overflow, ou ailleur.
    En plus d'utiliser une BD locale, j'utilise aussi les services de mongoLab (DBaaS), qui sont franchement bien, et l'équipe support est géniale (ils m'ont super bien aidé!!).
  • C'est souple on peut tout modifier en cours de route, et les collections de données peuvent stocker des éléments hétérogènes. C'est une base sans schéma, cela veux dire qu'on est pas obligé de déclarer à l'avance le format des données. On peut stocker des nombre, des chaînes de caractères, et des tableau pouvant eux aussi contenir des éléments de ce type. Vous pouvez composer ces types à l'infini pour stocker vos données. Bref ce que vous mettez dans un JSON se transpose directement en mongoDB. C'est très simple , et puissant à la fois.
    C'est très appréciable quand on fait de la recherche et qu'on ne peut pas tout prévoir à l'avance.
  •  

Mais il y a aussi des "moins"

Tout n'est pas rose, et j'ai aussi bien galéré sur certains points:
  • Il n'y a pas, a proprement parler, de tri-aléatoire.Il peut être assez courant, quand on manipule beaucoup de donnes, de ne parfois qu'en prendre une petite partie, aléatoirement, on appelle cela de l'échantillonnage... Et bien bizarrement mongoDB ne fait pas cela! Même simplement demander à la BD de "trier" aléatoirement les données extraites grâce à une requête, ça n'existe pas. Cette dernière opération peut etre faite ailleur, mais cela oblige alors de d'abord charger toutes les données pour les mélanger ensuite: ce n'est pas très efficace...
  • Il n'y a pas de moyen simple de contrôler la mémoire (RAM) que consomme mongoDB. Dans la pratique ça peut etre assez gênant. J'aurai bien aimé pouvoir limiter la RAM utilisé, en acceptant bien sur une baise de performance. Ce qui fait que en pratique, il est conseillé de dédier entièrement un serveur à mongoDB. Sinon les autres applications risquent d'être "à l'étroit"...
  • Certaines opérations ne se font pas , et sans message d'erreur!
    Certaines fonctionnalité ne marchent pas, ... comme dans toutes les techno', mais il aurait été appréciable surtout pour une base de données, d'avoir un message d'erreur indiquant que l'opération n'a pas été faite.
  • Il y parfois des choix difficilement explicable. Voici un exemple...
    Il y a moyen de filtrer une requête par son type de donné (nombre , chaîne de caractère, etc...), c'est très utile puisque c'est une base sans schéma par conséquent un même champ peut parfois contenir un nombre ou une chaîne de caractère.  Par contre pour les tableaux (pouvant eux aussi contenir des éléments hétérogènes), la logique est telle qu'il est impossible de savoir si le type d'un champs est un tableau ou pas !! Par contre on peut savoir si le tableau contient un nombre ou une chaîne de caractère...
Tout ceci est une vue personnelle issue d'une expérience spécifique sur mon projet.

Voilà, en espérant que ces informations vous soit utiles dans le choix de la BD que vous utiliserez pour vos projets. N'hésitez pas à commenter si vous voulez partager votre experience avec mongoDB ou d'autres types de bases de données.


mardi 4 août 2015

Statistique bayésiennes

Dans les écoles d'ingénieur on apprend naturellement des bases de statistiques, car c'est une science très utile dont on trouve des applications un peu partout...

Bien sur, comme pour tout ce qui est enseigné à l'école, on se concentre sur les techniques et méthodes qui sont éprouvées (et donc parfois un peu anciennes...). Ainsi quand il s'agit d'aborder la thématique des tests statistiques : ce qui permet de savoir si deux groupes de données A & B sont homogènes ou non, on utilise le test du Chi². Ce test n'est pourtant pas toujours le plus adapté à la situation...

C'est ce qu'explique cette courte vidéo (en français) :


The statistical innovation Clever Stats explained in details by Chief Data Scientist Hubert Wassner from AB Tasty on Vimeo.
Most testing solutions rely on statistical methods that take a frequentist approach to significance testing, such as the Student’s t-test and the Z test. While these methods have proved themselves valuable, and are viable in sectors such as pharmaceuticals and agriculture, they are not well-suited to the constantly changing online world.

Using these methods requires a strict methodology known as fixed horizon statistics, in which a sample size must first be defined, and in which no conclusion may be made before this size is reached. These constraints are no longer relevant to a world in which data and information constantly flows, and are accessible in real time.

Typiquement on veux savoir si un nouveau médicament (B)  est meilleur que l'ancien (A), ou si une phrase est plus vendeuse qu'une autre sur une page produit d'un site de e-commerce. On fait alors ce qu'on appelle un test A/B et on utilise un test statistique sur les données produites. Cependant le test du Chi², s'il est simple à mettre en oeuvre et rapide à s'exécuter, n'est pas exempt de défaut... Le plus important étant qu'il faut fixer à l'avance le nombre d'échantillons à tester. Tant que ce nombre n'est pas atteint le calcul du Chi² n'est pas valide ! (mais le calcul est réalisable). Ce qui fait que bon nombre de gens font des erreurs car ils utilisent ces valeurs pour faire des décisions...

Grâce au développement rapide de la puissance des ordinateurs, et à la large diffusion de librairies de statistique, il est possible maintenant d'aborder le problème du test statistique avec la vision de Thomas Bayes (d'où le nom des statistiques bayésiennes). Cela apporte principalement deux fonctionnalités très intéressantes :
  • Le test bayésien produit des informations statistique valide à tout instant.
    Il n'est donc pas nécessaire de prévoir le nombre d'échantillons à tester par avance, c'est au fur et a mesure de l'arrivée des données que l'on peut produire une information statistique pour aider à la décision.
  • Par construction ce test peu intégrer une connaissance a-priori. Par exemple, on peu spécifier que l'on connaît des informations sur le groupe A (ce qui est souvent le cas puisque c'est en général la version originale déjà exploitée.) Cela permet alors d'avoir des informations statistique utilisable bien plus tôt, et donc de pouvoir prendre des décision plus rapidement. Là où le test du Chi² sera plus 'lent', ne pouvant pas intégrer ces informations a-priori.
Par conséquent, le test bayésien est nettement plus adapté au contexte d'expérimentations sur le web, même si il est un peu plus compliquer à coder, et s'il nécessite un peu plus de temps calcul.