:: DEVELOPER ZONE
Comme mentionné plus tôt, les accès disques représentent une limitation. Ce problème devient de plus en plus apparent, au fur et à mesure que les données sont de plus en plus nombreuses, et que les techniques de cache deviennent impossibles. Pour les grandes bases de données, lorsque vous accédez aux données plus ou moins aléatoirement, vous pouvez être sûr que vous aurez besoin d'un accès disque pour lire, et de plusieurs autres pour écrire. Pour minimiser le problème, utilisez des disques avec des temps d'accès très faibles.
Augmentez le nombre de disques disponibles (et donc, réduisez le coût d' un accès), en pla¸ant des données sur d'autres fichiers via des liens symboliques.
Utiliser des liens symboliques
Cela signifie que vous allez faire un lien symbolique sur le fichier d'index et/ou le fichier de données sur un autre disque. Cela améliore les lectures et écriture (surtout si ces disques ne sont alors utilisés qu'à ¸a). See Section 7.6.1, « Utiliser des liens symboliques ».
Le parallélisme signifie que vous avez plusieurs disques matériel, et que vous écrivez le premier bloc de données sur le premier disque, puis le second bloc de données sur le second disque, et le n-ième bloc sur le n-ième disque, etc. Cela signifie que si la taille normale de vos données sont moins grand que le nombre de disque disponibles, vous obtiendrez alors des performances additionnées. Notez que le parallélisme est très dépendant du nombre de disque disponibles et du système d'exploitation. See Section 7.1.5, « Utiliser vos propres tests de performance ».
Notez que la différence de performance avec le parallélisme est très dépendante des paramètres. Suivant la fa¸on avec laquelle vous avez configuré les disques en parallèle, et le nombre de disque que vous utilisez, le facteur d'amélioration peut être très variable. Notez que vous devez faire votre optimisation en lecture aléatoire ou séquentielle.
Pour plus de robustesse, vous pouvez utiliser des disques en RAID 0+1 (parallélisme et réplication), mais dans ce cas, vous aurez besoin de 2*N disques pour contenir vos données sur N disques. C'est probablement l'option la plus sûre, si vous avez le budget pour cela. Vous risquez aussi d'avoir à investir dans un système de gestion de gros volume de données pour gérer cela efficacement.
Une bonne option est de garder les données semi-importantes (qui peuvent être regénérées) sur un disque RAID 0 tandis que les données vraiment importantes (comme les informations d'hôtes et les log) sur un disque de type RAID 0+1 ou RAID N. RAID N peut être un problème si vous avez de nombreux accès en écrire, à cause du temps de modification des bits de parité.
Sous Linux, vous pouvez améliorer les performances (jusqu'à 100% en charge
n'est pas difficile) en utilisant hdparm pour configurer votre interface
disque. La commande suivante doit être une série de bonnes options de
hdparm pour MySQL (et probablement d'autres applications) :
hdparm -m 16 -d 1
Notez que la performances et la robustesse des solutions ci-dessus dépendent
de votre matériel, et nous vous conseillons vivement de tester votre
système soigneusement après avoir utilisé hdparm! Consultez le manuel de
hdparm pour plus de détails. Si hdparm n'est pas utilisé correctement,
le système de fichiers peut être corrompu. Sauvegardez tout avant d'expérimenter.
Vous pouvez aussi modifier les paramètres suivants sur le système de fichiers que la base de données utilise :
Si vous n'avez pas besoin de savoir quand un fichier a été accédé la dernière
fois (ce qui n'est pas utile avec un serveur de base de données), vous pouvez
monter votre système de fichier avec l'option -o noatime.
Sur de nombreux systèmes d'exploitation, vous pouvez monter des disques avec
l'option -o async pour que le système de fichiers soit modifié de manière
asynchrone. Si votre serveur est raisonnablement stable, vous devriez obtenir de
bonne performances sans sacrifier la stabilité (cette option est activée par
défaut sur Linux).
© 1995-2005 MySQL AB. All rights reserved.
