Base de données pour de l'écriture intensive

Bonjour à tous,

Décidément en ce moment je viens beaucoup vous embêter avec des questions de choix techniques

J'ai créé un petit script Node tout bête qui récupère le stream des tweets pour certains mot-clés. Le but est d'enregistrer en base, pour chaque mot-clé, combien de fois celui-ci est apparu dans les tweets.

Donc l'idée de l'algo est la suivante :

• J'écoute le stream
• À chaque tweet, je regarde lequel des mots-clés est présent parmi ceux que je surveille
• J'update en base de données le compteur pour ce jour, ou je le crée s'il n'existe pas encore

Grosso modo, j'ai besoin de trois informations en base :

• La date
• Le mot clé
• Le nombre de tweets pour ce jour

Donc une nouvelle ligne est créée pour chaque jour, ça pas de soucis. Par contre l'update du nombre de tweets peut se faire très très souvent (je dirais une à plusieurs fois par seconde au pire). J'aimerais donc savoir quelle serait la base de données (NoSQL j'imagine ? Je m'en fiche en fait, tant que ça fonctionne) la plus adaptée pour cet usage.

Pour la lecture des infos, je n'ai besoin d'aucune performance particulière. C'est vraiment l'écriture qui es critique.

Merci d'avance

Si tu fais ton truc avec node, je dirais que le plus simple est de garder un compteur en mémoire et de mettre à jour la base de donnée que toute les minutes par exemple :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

var tweets = 0;

tweeter.on('tweet', function(tweet){
    tweets++;
});

setInterval(function(){
    bdd.addTweets(tweets);
    tweets = 0;
}, 60000);

Et si tu te poses la question du cas où tu recevrais un tweet en même temps que tu mets à jour la bdd, ça n'arrivera jamais. En fait, si ça arrive, une des fonction sera exécuté avant l'autre. Donc pas de soucis à se faire à ce niveau là.

Salut,

Ce que tu penses être très souvent n'est en fait pas grand chose pour une bdd.

Je viens de tester, sur du MySQL, 28619 lignes, la requête suivante prend 0.094 secondes à s'exécuter :

1
2
3

UPDATE test
SET count = count + 1
WHERE day = DATE(NOW())

Ça te donne environ 78 ans où tu peux faire environ 10 requêtes par secondes. (On ne peut pas échapper des tildes ?)

Je suis sous Windows, MySQL installé sur HDD, donc niveau perf, je suis sûr qu'il est très facile de faire mieux, mais je voulais juste démontrer que nos PC peuvent facilement gérer ces quelques requêtes à la seconde.

Après, si cela ne te suffit pas, tu peux faire comme Berdes te l'a suggérer : stocker le compte et réduire le nombre d'UPDATE.

Sinon probablement que redis est adapté à ce genre de chose.

Redis est bien adapté au écriture rapides et très simples (compteurs, stats, …) par contre pour quelques modifications par seconde je suis pas sûr qu’on puisse parler d’intensif, ni que le gain par rapport à du SQL soit flagrant.

Pour un ordre de grandeur, Redis peut écrire plusieurs dizaine de milliers de ligne par secondes (chez moi ça tourne à ~200 000 requetes/seconde).

Bah ce qu'il veut c'est faire du comptage. Tu fais une clé avec le mot-clé + date et tu fais des INCR dessus. Il n'a quasi rien a stocker (donc le fait que ce soit en RAM n'est pas gênant) et il fait des opérations très simple (elles sont dispo dans les commandes redis de base).

Je dis pas qu'il gagnera beaucoup de temps vis a vis d'un SQL mais en tout cas ça sera largement suffisant.

Il y a 2 inconvénients à utiliser Redis pour le besoin actuel : c'est une base en mémoire (RAM), si on coupe le serveur on perd les données, donc pas forcément adapté aux stats mais plutôt au memcached. C'est une base clé/valeur(s), mais si tu souhaites effectuer des recherches sur une clé ce n'est pas forcément super pratique. J'ai rédigé un mini-tuto avant le passage à la version 3 si ça t'intéresse : http://gokanekinci.ovh/fr/database/nosql/key-value/redis.html

Peut-être que MongoDB serait plus adapté au besoin.

Tiens je suis étonné, il me semblait avoir répondu oO

Suite à vos réponses, j'en déduis que l'écriture n'est pas si intensive que ça. Je vais donc pour l'instant rester sur du MySQL classique, et voir ce que ça donne. Si vraiment ça met mon serveur à genoux, j'adopterai la solution de Berdes, en réduisant quelque peu l'intervalle.

Merci

Il y a 2 inconvénients à utiliser Redis pour le besoin actuel : c'est une base en mémoire (RAM), si on coupe le serveur on perd les données

Oui et non, il y a des moyens simples de rendre le truc persistant ou du moins facilement rattrapable. Mais bon effectivement vu les besoin ,autant utiliser n'importe quel base qu'il connait déjà