Sarc Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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 Lien vers le commentaire Partager sur d’autres sites More sharing options...
xpatval Posté 22 Mai 2006 Partager Posté 22 Mai 2006 Lecture et changement...Changement ou chargement ? Et si c'est changement, cela signifie donc update ? (je sais, je n'ai qu'un neurone...) xpatval Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sarc Posté 22 Mai 2006 Auteur Partager Posté 22 Mai 2006 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... Lien vers le commentaire Partager sur d’autres sites More sharing options...
ludo88 Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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é Lien vers le commentaire Partager sur d’autres sites More sharing options...
robinsonvendredi Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sarc Posté 22 Mai 2006 Auteur Partager Posté 22 Mai 2006 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... Lien vers le commentaire Partager sur d’autres sites More sharing options...
robinsonvendredi Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Anonymus Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
ludo88 Posté 22 Mai 2006 Partager Posté 22 Mai 2006 (modifié) 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 Lien vers le commentaire Partager sur d’autres sites More sharing options...
xpatval Posté 22 Mai 2006 Partager Posté 22 Mai 2006 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 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sarc Posté 22 Mai 2006 Auteur Partager Posté 22 Mai 2006 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 22 Mai 2006 Partager Posté 22 Mai 2006 mon livre de référence SQL : SQL Avancé Programmation et technique avancé - Joe Celko 2° Edition - Edition Vuibert Lien vers le commentaire Partager sur d’autres sites More sharing options...
astro Posté 30 Mai 2006 Partager Posté 30 Mai 2006 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" Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant