Stockage de tonnes de données

[Sarc]

Bonjour à tous,

Je suis en train de réfléchir à comment optimiser un stockage (et utilisation : lecture et changement) de plusieurs centaines de milliers de données... Par exemple pouvoir stocker des données sur toutes les cases d'un échiquier de 1000*1000 cases.

Vaut-il mieux créer des fichiers texte qui géreront chacun par exemple 100*100 cases, et d'en faire 100 ? Ou créer plusieurs tables SQL pour séparer également les données en plusieurs "sous-parties" ?

Sachant que si je lis un fichier texte, aucun script ne pourra écrire dessus en même temps... Faut-il un très bon serveur pour gérer autant de données ?

Bref, j'avoue n'avoir jamais eu à traiter autant de données, et mes BDD sont plutôt plus petites, donc j'aimerais avoir quelques idées de gestion de grosses bdd comme ça, avec si possibles conseils de gestion de ces données...

Merci d'avance

[xpatval]

Lecture et changement...Changement ou chargement ? Et si c'est changement, cela signifie donc update ? (je sais, je n'ai qu'un neurone...)

xpatval

[Sarc]

Oui j'ai mis changement pour ne pas sombrer dans les profondeurs d'un anglicisme abusif et honteux pour les Français.

Oui donc read and update les données, c'est bien ce que je voulais dire

Par exemple, si un visiteur modifie une des cases de l'échiquier, je devrais parcourir le fichier pour modifier la ligne, et je sais pas combien de temps ça prendrait, et si ça tiendrait s'il y a beaucoup de changements par seconde...

[ludo88]

la question m'interesse pas mal, j'ai un outil de stat et je gere plusieurs centaines de milliers d'enregistrements par mois et je fais des calculs dessus + des classement en fonction des stats ...

Pour l'instant j'ai opté pour une seule table, ca marche encore (lentement) mais bientot ce sera plus possible (je pensais à diviser ma table en au moins 10 sous table mais je me pose la question des classements (je vais faire 10 * plus de requetes) ?? Sinon j'ai l'option de la réorganisation puside l'archivage mais ca va etre très couteux en ressources je pense.

Ludo

PS désolé de squatter ton topic sarc mais je pense que c'est lié

[robinsonvendredi]

Ca dépend si les modifications sont faites par plusieurs personnes en même temps et quand.

Si c'est principalement de la lecture avec une mise à jour la nuit, un stockage sur XML est peut être une bonne solution.

Si les mises à jour sont fréquentes et faites simultanément par plusieurs personnes : base de données. Oublie les fichiers plats à moins que tu ne souhaites développer ton propre moteur SQL...

Maintenant si ça va au-dela du simple stockage et qu'il existe des contraintes entre les cases de l'échiquier, jette un coup d'oeil à Prolog.

[Sarc]

Pas de soucis Ludo, si tout le monde peut apporter sa pierre et son expérience !

Robinson, je peux donc opter pour une base de données, mais reste à savoir s'il vaut mieux diviser mon échiquier en plein de sous parties par exemple de 10 000 enregistrements plutôt que de garder énormément d'enregistrements...

Pareil, je me demande s'il est préférable de mettre des infos "vides" pour une case de l'échiquier vide, ou alors de ne mettre en BDD que les cases pleines... Sachant que pour tester si une case est dans la BDD, je devrai faire travailler SQL, alors que si je sais d'ores et déjà que toutes les cases sont mises, je n'aurai pas ce genre de requètes à faire...

[robinsonvendredi]

Oui tu pourrais gérer les cases vides/pleines dans une table à part.

Sinon tout dépend de la complexité des requêtes.

Si tu as des plans de requêtes qui consomment beaucoup de ressources, tu peux opter pour une base de données avec procédures stockées comme MaxDB par exemple.

C'est une base de données conçues comme une alternative à Oracle.

SAP a fait des benchmarks qui laissent reveur

[Anonymus]

Je le répète assez souvent, mais.. sur un dédié classique, je gère une table de 3,5 millions d'enregistrements, et ca se passe pas trop mal

(Bon, c'est vrai, ca rame, et je vais changer de serveur... mais jusqu'à 3.5 millions, ca passait )

mysql est fait pour gérer de grosses tables, et le fait très bien. Après, il faut le serveur qui va avec, mais j'ai pour avis que ca sera toujours plus rapide de laisser mysql gérer ca que la même chose en php. Chacun son boulot, et le langage utilisé pour gérer le moteur sql est plus largement plus rapide que celui pour le site.

[ludo88]

pour info sur des requetes moyennement compliquées sous mysql avec un mutualisé bas de gamme j'avais des réponses correctes (- de 1 sec temps de requete) jusqu'a 100000 éléments en gros.

La pour un peu plus de 500000 avec le chargement de la page on est plutot dans les 10 à 15s et la courbe ne va pas dans le bon sens a mon gout : ca s'oriente vers del'exponetielle... il faut que je refasse des bench mais la je suis sous un dédié start 300 donc pas top non plus se sera mieux que le mutu bas de gamme mais bon ...

Modifié 22 Mai 2006 par ludo88

[xpatval]

Je dirais surtout que la base n'est pas réellement un problème. Ce qu'il faut est une bonne réflexion sur la structure des tables (quels index, ni trop ni pas assez, quel type de champ) et donc par conséquent des requêtes optimisées, savoir si les mises-à-jours peuvent être effectuées par plusieurs personnes dans le même temps, s'il est préférable ou non de locker la ou les tables, etc etc...

xpatval

[Sarc]

Au passage, limite hors-sujet : il y a sur le hub une belle liste de sites traitant le PHP en long, en large, en travers... mais pas grand chose sur le SQL "avancé" avec des exemples d'optimisation des index etc, avec des méthodes d'optimisation des données, de structures intelligentes, etc...

Vous auriez des ressources ?

[Spidetra]

mon livre de référence SQL :

SQL Avancé

Programmation et technique avancé - Joe Celko

2° Edition - Edition Vuibert

[astro]

c'est quoi comme type de donnée ? du texte?

a la limite si tu as beaucoup d'espace libre, pas trop de ressource mémoire, et que ces données ont a peu pret toute la meme taille, et que tu as pas besoin de rechercher dedans, tu peux envisager la solution "fichier texte"