Saik

Pour ce qui est de mes bornes, ce sont deux champs bien définis qui marquent la période de validité d'une valeur : valeur valable entre le cycle x et le cycle y. Dans l'idée on peut voir ça comme des dates mais une itération de l'algorithme se déroulant en un temps assez long, je dois fonctionner par numéro d'itération plutôt (afin de retrouver les valeurs par itération, chose évidemment impossible par date). La seconde borne est donc forcément supérieure à la première. Je vais voir pour ce qui est des performances en regroupant les transactions, mais le fait d'utiliser postgre n'est pas un problème étant donné qu'il est facilement utilisable avec PHP (l'interface sera un site web PHP) Je peux aussi dans une certaine mesure stocker des valeurs agrégées, en fait pour tout cycle terminé (de base 8 cycles par jour, l'idéal serait à l'avenir de l'augmenter à 12 ou plus, mais là ça dépendra de la puissance de calcul qu'on pourra donner au programme... '), mais mes opérations de moyenne, min et max se faisant sur de petits ensembles (à peu près 4 en moyenne), je devrais rajouter 75% d'enregistrements en plus (25% par opération). Évidemment point de vue calcul c'est assez intéressant, mais point de vue stockage ça alourdi encore les données. Je ne sais pas si je suis assez clair, en tous cas merci pour ces indications

Ah, je ne savais pas que ce genre de bases existait mais ça a l'air de correspondre assez bien à ce que je cherche. Merci Je vais regarder aussi du côté de Cassandra... Le tout étant évidemment de trouver un système qui marche à l'instant I mais qui soit aussi extensible car un grand nombre de données sont appelées à être ajoutées !!!

Merci pour vos réponses Pour ce qui est de la conservation des données, oui, en l'état actuel les données sont indéfiniment conservées. Je dois voir s'il n'est pas possible de ne conserver que des données intermédiaires (genre de valeurs moyennes) pour les plus anciennes, mais je n'ai pas trop d'espoir de ce côté là... Les requêtes sont simples : sélection d'un ensemble de valeurs en fonction de deux des INTs (bornes min et max), calcul de moyenne, du min et du max. La fréquence de lecture n'est pas encore bien définie, mais devrait tourner autour de la 50aine de requêtes/seconde uniquement. L'écriture se fait en continu (pas de pic, pas spécialement de temps mort non plus, donc à 500k requêtes on est à une moyenne d'un peu moins de 6 par seconde), mais la nature du site m'autorise à faire un gros import tous les minutes par exemple plutôt que plusieurs valeurs uniques par seconde... Bref, la charge de calcul n'est pas extraordinaire, seul le volume de données l'est réellement. Pour la taille de champs, 32 bits suffisent. Merci en tous cas pour le retour

Bonjour à tous Voilà, je suis amené à enregistrer un très grand nombre d'informations dans une base de données : de l'ordre des 500000 nouveaux enregistrements par jour (amené à augmenter mais pas exponentiellement, peut-être à doubler/tripler dans les prochains mois). Une donnée enregistrée ne sera que très improbablement modifiée, mais sera lue régulièrement. Un enregistrement correspond à une ligne dans une table contenant 4 clefs étrangères (INT7) et trois autres champs INT10. Ma question est donc : à votre avis, quelle genre de structure serait idéale pour stocker ce genre d'informations (clustering avec plusieurs mini serveurs, ...) ? Je n'ai aucune expérience en d'aussi gros volumes de données et suis donc "un peu" perdu, jusqu'ici je n'avais l'habitude que d'utiliser un simple serveur mysql pour chaque projet. Merci par avance pour toute aide éventuelle