Discussion :

[pas30]

Bonjour,

Voici ma problématique :

J'utilise à ce jour PHP et mysql pour stocker et gérer les données. Mais là j'ai besoin de stocker et modifier un flot de données énorme (plus de 25 000 000 requêtes par jour et le serveur risque de ne pas tenir la charge). Avec mysql il est quasi certain que celà ne tiendra pas. J'ai pensé à l'usage des fichiers ou au table MEMORY

Voici les données que j'aimerais stocker et manipuler :

2 colonnes qui seront : IDENTIFIANT et NOMBRE

On compte pour chaque identifiant le nombre d'appel

ex : IDENTIFIANT 256 NOMBRE : 5897
Celà signifie que l'identifiant 256 a reçu 5897 visites sur la page

Ce qui signifie que dans le cas de fichier texte il va falloit rechercher la ligne avec l'identifiant pour ajouter dans la colonne NOMBRE +1
Est-ce à votre avis la solution ? Est-ce que les fichiers textes sont plus performants dans un cas comme celui ci ? Ou alors faudrait-il utiliser des fichiers csv ? Ou encore une table MEMORY

Vous l'aurez compris je cherche la meilleure solution possible pour stocker des flots de données très important. MYSQL prend énormément de ressources, est-ce que celà vient de la simple connexion MYSQL ou des écritures/lectures dans les fichiers MYSQL ?
Merci pour votre aide

[grunk]

25M de requêtes par jour tu peux utiliser n'importe quelle solution ,sur un seul serveur , je pense que c'est pas envisageable.

Pour tenir ce genre de charge il faut basculer sur des structures plus importantes.

Sinon pour répondre à tes questions :

- Fichier : tu vas économiser la connexion mysql mais ca va être un galère sans nom dès que tu vas vouloir utiliser les données; Sans parler des accès disque. 25M de requête si tu gère un système de fichier à la main tes disques dur vont pas vivre très longtemps à mon avis.

- Memory : Si tu n'as pas besoin de conserver les données c'est une solution. pour rappel en memory , un reboot et les données on disparues. Sans comtper qu'il faudra certainement plusieurs dizaine de Go de mémoire pour gérer ton flux de requêtes.

[Benjamin Delespierre]

Environ 290req/s donc, ça donne 3ms max par requête, vu que mêmes les requêtes les plus simples sur des tables performantes mettent environ 6ms, ça va être tendu pour tenir la charge (de plus qu'on parle ici de moyenne, les pics risquent effectivement de tout faire planter).

Je crois effectivement que ton infrastructure n'est pas bonne. Il faudrait songer à utiliser un cluster de serveur SQL (ou NO-SQL) pour répartir la charge. Et coté serveur d'application, PHP et Apache ça risque également d'être difficile, les requêtes vont s'empiler jusqu'a saturation de la mémoire. J'ai fait quelques tests, et avec 250hits/s, ça plante en 1/4 heure sur une machine de 2Go de mémoire - sans parler que la plupart des requêtes sont tout simplement abandonnées (timeout TCP). Avec un serveur qui a plus de guts, on peut cependant monter plus haut.

D'autres serveurs d'application sont plus efficaces sous forte charge, tu devrais considérer l'usage de NodeJs qui est célèbre pour ses perfs spectaculaires.
Coté SGBD, tu devrais regarder du coté de Cassandra (utilisée par FaceBook) qui est optimisé pour le travail en cluster et qui est extrêmement rapide. Après, il faut voir non seulement le nombre de requêtes/s mais aussi le volume de données (une fois le disque plein, bonjour les plantages).

On ne peut pas tout faire avec une stack LAMP, désolé

[riete]

Je débarque avec mes gros souliers. A mon avis se poser les bonnes questions est déjà un bon point de départ.

25 M de requêtes par jour. Tu dois travailler sur un projet qui brasse pas mal d'argent pour avoir à traiter autant de données. Les personnes qui te demandent une telle performances doivent quand même avoir un minimum de conscience pour s'apercevoir de la puissance de feu qu'il faut mettre en oeuvre pour accomplir une telle tâche. Si ce n'est pas le cas, il faut les mettre au courant avec les informations qui ont été fournies par les personnes avant moi.

S'ils sont conscient, il ont sûrement prévu un budget ou alors ils faut les reprogrammer ;-).

Ne serait il pas judicieux de fractionner les données et de repartir les tâches sur plusieurs serveurs esclaves eux même controlé par un maitre dont la tâche serait d'aller récupérer les résultat chaque jours. Reste à savoir combien de serveur seraient nécessaire pour accomplir la tâche sans qu'il y ai combustion :-P

[pas30]

Alors déjà j'ai 4 gros serveurs et les 25 millions de hits sont gérés par apache sans problème. Les revenus de ce service ne seront pas énormes malheureusement et il me faut une solution adaptée. Les données seront simple à gérer car 2 colonnes c'est tout. MYSQL ne me semble pas du tout la solution
Les fichiers textes sont parait-il moins lourd beaucoup moins lourd et d'ailleurs des sociétés utilisent les fichiers textes pour stocker les données et ensuite toutes les 2 heures par exemple rebasculer les données dans mysql

[grunk]

Alors déjà j'ai 4 gros serveurs et les 25 millions de hits sont gérés par apache sans problème

Dans ton premier message tu parles de requête.

je pense qu'on avait tous compris requête au sens SGBD. Si c'est un hit au sens serveur web ce n'est effectivement plus du tout la même chose.

Les données seront simple à gérer car 2 colonnes c'est tout. MYSQL ne me semble pas du tout la solution

Effectivement , pour 2 colonnes un sgbdr n'est absolument pas adapté , il vaut mieux se tourner vers une solution noSql (mongoDB , couchDB ...)