Planification de la capacité de disque et de RAM
La planification de la capacité disque et mémoire d'un serveur de base de données est un art noir. Plus c'est mieux. Plus vite c'est mieux.
À titre indicatif, je propose ce qui suit:
- Vous voulez plus d'espace disque que vous n'en aurez JAMAIS besoin.
Estimez au mieux votre espace disque nécessaire pour les 3 à 5 prochaines années, puis doublez-le.
- Vous aurez besoin de suffisamment de RAM pour conserver vos index de base de données en mémoire, gérer votre requête la plus grosse au moins deux fois et toujours disposer de suffisamment d'espace pour un cache de disque de système d'exploitation sain.
La taille de l'index dépend de votre base de données et tout le reste dépend fortement de votre ensemble de données et de la structure de votre requête / base de données. Je vais proposer "au moins deux fois la taille de votre table la plus grande", mais notez que cette suggestion ne s'applique pas aux opérations d'entreposage de données très volumineuses, où la table la plus grande peut contenir des dizaines ou des centaines de gigaoctets.
Chaque fournisseur de base de données dispose de quelques instructions pour optimiser les performances de votre disque, de votre mémoire et de votre noyau de système d'exploitation. Consacrez un peu de temps à cette documentation avant le déploiement. Ça aidera.
Analyse comparative de la charge de travail et planification de la capacité
En supposant que vous n'avez pas encore déployé…
De nombreux systèmes de base de données sont livrés avec des outils d'analyse comparative. Par exemple,
PostgreSQL est livré avec
pgBench .
Ces outils devraient constituer votre première étape dans l'analyse des performances des bases de données. Si possible, vous devriez les exécuter sur tous les nouveaux serveurs de base de données pour avoir une idée du travail que le serveur de base de données peut accomplir.
Armée maintenant d'un repère brut ABSOLUTELY MEANINGLESS, considérons une approche plus réaliste du benchmarking: chargez votre schéma de base de données et écrivez un programme qui le remplit avec des données factices, puis exécutez les requêtes de votre application sur ces données.
Cette analyse compare trois éléments importants: 1. Le serveur de base de données (matériel) 2. Le serveur de base de données (logiciel) 3. La conception de votre base de données et son interaction avec (1) et (2) ci-dessus.
Notez que cela nécessite beaucoup plus d’efforts que de simples tests prédéfinis, tels que pgBench: Vous devez écrire du code pour effectuer le remplissage et vous devrez peut-être écrire du code pour exécuter les requêtes et le temps d’exécution du rapport.
Ce type de test est également beaucoup plus précis: puisque vous travaillez avec votre schéma et vos requêtes, vous pouvez voir leur performance et vous offrir la possibilité de profiler et d'améliorer votre base de données / requêtes.
Les résultats de ces tests constituent une vue idéalisée de votre base de données. Pour être sûr, supposons que vous n'atteignez que 50 à 70% de ces performances dans votre environnement de production (le reste étant un coussin qui vous permettra de faire face à une croissance inattendue, aux pannes matérielles, aux modifications de la charge de travail, etc.).
C'est trop tard! C'est en production!
Une fois que vos systèmes sont en production, il est vraiment trop tard pour "évaluer" - Vous pouvez activer brièvement la journalisation et le minutage des requêtes et voir combien de temps il faut pour les exécuter. Vous pouvez également exécuter des requêtes de "test de contrainte" sur de grands ensembles de données pendant heures. Vous pouvez également consulter l'utilisation du processeur, de la mémoire vive et de l'E / S (bande passante du disque) du système pour avoir une idée de sa charge.
Malheureusement, tout ce que vous ferez sera de vous donner une idée de ce que fait le système et un vague concept de la proximité de saturation.
Cela nous amène à…
Surveillance continue
Tous les tests de performance dans le monde ne vous aideront pas si votre système détecte soudainement des modèles d'utilisation nouveaux / différents.
Pour le meilleur ou pour le pire, les déploiements de bases de données ne sont pas statiques: vos développeurs vont changer les choses, votre ensemble de données va s'agrandir (ils ne semblent jamais rétrécir), et vos utilisateurs vont créer en quelque sorte des combinaisons insensées d'événements que vous n'aviez jamais prédits lors des tests.
Afin de planifier correctement la capacité de votre base de données, vous devez mettre en place un système de surveillance des performances pour vous avertir lorsque les performances de la base de données ne répondent plus à vos attentes. À ce stade, vous pouvez envisager des actions correctives (nouveau matériel, schéma de base de données ou modifications de requête pour optimiser l'utilisation des ressources, etc.).
Remarque: Il s'agit d'un guide générique et de très haut niveau permettant de dimensionner votre matériel de base de données et de déterminer l'ampleur des abus pouvant en résulter. Si vous ne savez toujours pas comment déterminer si un système spécifique répond à vos besoins, consultez un expert en bases de données.
Il existe également un site Stack Exchange spécifiquement dédié à la gestion de base de données: dba.stackexchange.com . Recherchez dans leurs archives de questions ou parcourez les balises spécifiques à votre moteur de base de données pour obtenir des conseils supplémentaires sur le réglage des performances.