Discussion :

[StouffR]

J'ai une application qui a pour but de collecter des événements de logs pour les centraliser afin qu'ils soient consultables par des utilisateurs.
Une partie "statistiques" permet d'avoir des informations pertinentes sur l'ensemble de ces événements.
Jusque là, pas de soucis

Par contre, j'ai 6000 sources qui envoient environ 1 000 000 d'événements cumulés par jour. 50 utilisateurs simultanés peuvent se connecter dessus.

Au fur et à mesure de la montée en charge, les performances de l'application ont fortement chutées lors de recherches.
La recherche a été limitée à l'adresse IP pour alléger les performances.
Il n'y a qu'une rétention de 1 mois des données.
J'ai prévu de changer le matériel pour quelque chose de bien plus costaud.
Par contre, je me pose des questions sur ma méthode de récupération et d'affichage des données :

Tous les collecteurs de l'application envoient directement les logs dans une table de la base de données. La table n'a que les index là où il faut sans autre fioriture.
Les statistiques sont calculées en pleine nuit. Les données sont stockées dans des tables à part. Affichage très rapide.

J'ai pensé à plusieurs axes d'améliorations :

1/ Envoyer les événements directement sous forme de fichiers dans une arborescence classant les événements par adresse ip sous forme de répertoire et les événements seraient dans des fichiers horodatés (pointage sur les fichiers concernés plus rapide, mais recherches dans les fichiers plus longues) ;

2/ Partitionnement des adresses IP dans la table (aucune idée de l'amélioration des performances) ;

3/ Répartir les adresses par groupe d'utilisateurs (tous les utilisateurs n'accèdent pas à tous les équipements. Mais certains en ont en commun avec d'autres).
Il y aurait un traitement à fréquence régulière (ex : 5 min) qui ferait la répartition dans plusieurs tables.
Le temps de traitement impose un temps de réponse plus long ;

4/ Répartir les adresses IP par table ou bien répartition par base de données séparées. 6000 tables ou bases de données et voire plus, trop lourd et limitation de MySQL.

Auriez-vous un avis sur ces choix ?
Est-ce que vous penseriez à quelque chose de plus efficace ?

[CinePhil]

Est-ce que vous penseriez à quelque chose de plus efficace ?

Changer de SGBD ?

Sans structure de la BDD, volumétrie des tables et exemple de requêtes lentes, difficile de répondre.

A priori, la démarche actuelle semble bonne et des 4 "améliorations" que tu proposes, je n'envisagerais tout au plus que le partitionnement. Et encore faudrait-il l'éprouver sur un environnement de test avant de le mettre en production.

Quand tu dis "50 utilisateurs", ce sont 50 utilisateurs de l'application qui utilise la BDD avec un seul utilisateur MySQL ou 50 utilisateurs MySQL ?