C'est une question canonique sur la planification de la capacité des bases de données.
En relation:
Je cherche à créer une question canonique d’outils et de méthodes de planification de la capacité des bases de données. Ceci est destiné à être une question canonique.
Évidemment, le flux de travail général est le suivant:
- Mettez votre scénario en place
- Ajouter la surveillance
- Ajouter du trafic
- Évaluer les résultats
- Remédier en fonction des résultats
- Rincer, répéter jusqu'à ce que raisonnablement heureux
N'hésitez pas à décrire différents outils et techniques pour différents serveurs Web, frameworks, etc., ainsi que les meilleures pratiques.
Réponses:
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:
Estimez au mieux votre espace disque nécessaire pour les 3 à 5 prochaines années, puis doublez-le.
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.).
la source
En règle générale, vous avez besoin de cas d'utilisation réalistes pour tester les performances. Une meilleure pratique consiste à impliquer les développeurs d'applications et les utilisateurs finaux.
Enregistrez ce qu’ils font habituellement, paramétrez-le (contenu, nombre d’actions simultanées) pour chaque cas d’utilisation.
Ensuite, créez le côté client. Une seule machine physique ne suffit souvent pas pour augmenter la charge de production.
Ensuite, allumez-le, évaluez, améliorez et testez à nouveau.
Vous serez surpris où les bottlnecks montent.
la source