> Techniquement, il est plus coûteux d'effectuer dans la même seconde 10
> (ou 100 ou 1000) recherches sur 10 (100, 1000) tables différentes que les
> mêmes recherches sur la même table. En effet dans un cas, on accèdera à
> des indexs différents (et des tables différentes) donc pas d'utilisation des
> différents niveaux de cache (de celui du processeur à celui du disque en
> passant par ceux du système) alors que des recherches sur les mêmes
> tables via les mêmes indexs utiliseront ces caches.
Et c'est reparti avec une quesion de noob : si la grosse table a la même taille que la somme des petites, l'index de la grosse aura une taille proche de la somme des tailles des index des petites, non ? Et une fois chargés en cache, ça devrait revenir à peu près au même, non ?
> Au final s'il ne peut être question de corriger l'application, la meilleure solution
> est probablement celle de la multiplication des bases, car elle permet de plus
> facilement gérer des sauvegardes, restauration, administration en général pour
> chaque cours.
Ça me semble être un avantage, en effet, tout en minimisant en outre le temps pour réaliser les sauvegardes. Pas du point de vue de l'admin, bien sûr, mais du point de vue usager (durée de blocage).
> Sinon, pour le dimensionnement, je pense que la meilleur solution c'est de monter
> un prototype et de tester les deux solutions aux limites d'exploitation prévue.
Encore un domaine que je ne connais pas du tout. Y'aurait-il un moyen simple de faire jouer en parallèle des milliers d'instances de Selenium [http://seleniumhq.org/] (ou tout autre truc dans le genre) ?
[^] # Re: Merci !
Posté par natsirt . En réponse au message Gérer *beaucoup* (vraiment !) de bases MySQL. Évalué à 1.
> (ou 100 ou 1000) recherches sur 10 (100, 1000) tables différentes que les
> mêmes recherches sur la même table. En effet dans un cas, on accèdera à
> des indexs différents (et des tables différentes) donc pas d'utilisation des
> différents niveaux de cache (de celui du processeur à celui du disque en
> passant par ceux du système) alors que des recherches sur les mêmes
> tables via les mêmes indexs utiliseront ces caches.
Et c'est reparti avec une quesion de noob : si la grosse table a la même taille que la somme des petites, l'index de la grosse aura une taille proche de la somme des tailles des index des petites, non ? Et une fois chargés en cache, ça devrait revenir à peu près au même, non ?
> Au final s'il ne peut être question de corriger l'application, la meilleure solution
> est probablement celle de la multiplication des bases, car elle permet de plus
> facilement gérer des sauvegardes, restauration, administration en général pour
> chaque cours.
Ça me semble être un avantage, en effet, tout en minimisant en outre le temps pour réaliser les sauvegardes. Pas du point de vue de l'admin, bien sûr, mais du point de vue usager (durée de blocage).
> Sinon, pour le dimensionnement, je pense que la meilleur solution c'est de monter
> un prototype et de tester les deux solutions aux limites d'exploitation prévue.
Encore un domaine que je ne connais pas du tout. Y'aurait-il un moyen simple de faire jouer en parallèle des milliers d'instances de Selenium [http://seleniumhq.org/] (ou tout autre truc dans le genre) ?
Encore merci de vous pencher sur ma misère...