à mon travail, nous avons une petite base de données (comme dans deux cents tables et peut-être un total de million de rangées environ).
Je m'attendais toujours à ce qu'il soit assez rapide dans l'ordre de plusieurs milliers d'insertion par seconde et avec des requêtes qui prennent des millisecondes une fois la connexion établie.
Bien au contraire, nous avons des problèmes de performance pour que nous ne reçoivent que quelques centaines d'insertions par seconde et interrogent, même les plus simples prendraient pour toujours.
Je ne suis pas enterré si c'est le comportement / la performance standard ou nous faisons quelque chose de mal. Par exemple, 1500 requêtes qui impliquent une joignant 4 tables sur une colonne clé unique prennent environ 10 secondes. Il faut 3 minutes pour charger 300k de données au format XML dans la base de données à l'aide d'inserts simples sans violer aucune contrainte.
La base de données est SQL Server 2005 et dispose d'un riche modèle de dépendance relationnelle, ce qui signifie beaucoup de relations et de catégorisations sur les données ainsi qu'un ensemble complet de contraintes de contrôle pour les codes de catégorisation et plusieurs autres choses.
sont ces temps non? Sinon, ce qui pourrait affecter la performance? (Toutes les requêtes sont effectuées sur des colonnes indexées)
5 Réponses :
Un modèle de «dépendance relationnelle riche» n'est pas propice aux vitesses d'insertion rapides. Chaque contrainte (clé primaire, vérifications de valeur, et surtout les clés étrangères), doit être vérifiée pour chaque enregistrement inséré. C'est beaucoup plus de travail qu'un "insert simple".
Et il ne mord pas que vos insertions n'ont aucune violation de contraintes, le temps va probablement être tout en vérifiant vos clés étrangères. Sauf si vous avez des déclencheurs aussi, parce qu'ils sont encore pires.
Bien sûr, est-il possible que la seule chose qui soit fausse, c'est que votre table d'insertion est la parent-fk pour une relation FK "FK" pour une autre table THA oubliée d'ajouter un index pour le côté enfant-FK Sur la relation FK (ce n'est pas automatique et est souvent oublié). Bien sûr, cela espérait avoir de la chance.: -)
Indexation est un facteur majeur ici, lorsqu'il est fait correctement, ils peuvent accélérer de manière très bien des instructions, mais rappelez-vous qu'un index fera la marquage d'un insert ainsi que le serveur met également à jour les données, mais également les index. L'astuce ici est:
1) Déterminez les requêtes qui sont vraiment rapides critiques, ces requêtes doivent avoir des indices optimaux pour eux.
2) Le facteur de remplissage est important ici aussi. Cela fournit un espace vide à une page d'index pour remplir plus tard. Lorsqu'une page d'index est remplie (suffisamment de lignes sont insérées), une nouvelle page doit être créée à prendre plus de temps. Cependant, les pages vides occupent l'espace disque.
Mon astuce est ceci, pour chaque application I définie des priorités comme suit:
1) Vitesse de lecture (Sélectionnez-la, une mise à jour, certaines Supprimer) - plus cette priorité est élevée, plus les index, je crée
2) vitesse d'écriture (insertion, mises à jour, certaines suppression) - plus cette priorité est élevée, les moins indexés que je crée
3) Efficacité de l'espace disque - plus cette priorité est élevée, plus mon facteur de remplissage est élevé
Remarque Cette connaissance s'applique généralement à SQL Server, votre kilométrage peut varier sur un DBMS différent.
L'évaluation de la déclaration SQL peut également aider ici aussi, mais cela prend un vrai pro, prudent où et une analyse de jointure peut aider à déterminer les goulots d'étranglement et où vos requêtes souffrent de la souffrance. Activez les plans de showplan et de requête, évaluez ce que vous voyez et planifiez en conséquence.
Regardez également SQL Server 2008, des jointures indexées!
Les contraintes ajoutent une petite pénalisation de performance. Il doit également mettre à jour des index pour chaque insertion. Et si vous ne mettez pas de multiples inserts dans une seule transaction, le serveur de base de données doit exécuter chaque insertion comme une nouvelle transaction séparée, le ralentissant plus loin.
150 requêtes / deuxième jointure 4 tables sonne normale, bien que je ne connaisse pas grand chose de vos données.
Pour avoir une comparaison approximative: le Record de référence TPC-C pour SQL Le serveur se situe autour de 1,2 mil transactions par minute, et cela ressemble à ceci au cours des 4 dernières années environ (sous la forme de la limite de 64 CPU OS). C'est quelque chose dans le Balpark des transactions Vous devez maintenant accumuler ce haut sur le matériel de la ligne à votre déploiement réel et obtiendrez le ballon de ballon où définir vos attentes pour le traitement de la transaction OLTP sural . .
pour les données téléchargez le courant Record World est Environ 1 ToB en 30 minutes (si c'est toujours à jour ...). Plusieurs dizaines de milliers d'inserts par seconde sont assez ambitieux, mais réalisables, lorsqu'ils sont correctement effectués sur du matériel grave. L'article du lien contient des astuces et des astuces pour ETL High Trauguput (par exemple. Utilisez plusieurs flux de téléchargement multiples et affinciez-les vers NUMA NOWES).
Pour votre situation, je conseillerais avant tout Mesure Donc, vous découvrez les goulots d'étranglement, puis demandez à questions spécifiques comment résoudre des botlenecks spécifiques. Un bon point de départ est le et files d'enregistrement blanc .
très bonne réponse. Une note cependant, 1,2 million de TPM = 20 000 TPS.
"Je m'attendais toujours à ce qu'il soit assez rapide dans l'ordre de plusieurs milliers d'insertion par seconde et avec des requêtes qui prennent des millisecondes une fois la connexion établie."
(a) Les performances de la base de données dépendent de 99% sur la quantité d'E / S physique (sauf si vous êtes sur un petit site à l'aide d'une base de données en mémoire, qui peut permettre de reporter tous les E / S physiques jusqu'à la journée. est fait). (b) les E / S de la base de données impliquent non seulement les E / S physiques réels aux fichiers de données, mais également les E / S physiques pour persister les journaux / journaux / ... (et la journalisation est souvent faite en mode double (c.-à-d. deux fois) depuis que par exemple environ deux décennies). (c) De quelle manière la "quantité d'inserts" correspond à la "quantité d'E / S", est complètement déterminée par la quantité d'options que le concepteur de base de données est disponible pour optimiser la conception physique. Une seule chose peut être dite en général à ce sujet: les systèmes SQL échouent principalement (fournir les options nécessaires pour transformer les "dizaines de milliers d'inserts" pour simplement être "quelques centaines de centaines" d'E / S physique). Ce qui signifie que "des dizaines de milliers d'inserts" implique également des "milliers d'E / S physique", ce qui implique généralement des "dizaines de secondes". "Les" dizaines de milliers par seconde ")" tandis que "des requêtes sont plus lentes" ("millisecondes par requête", impliquant "moins de 1000 requêtes par seconde"). Que l'attente est absurde.
L'attente était due au fait que les questions que j'utilise sont assez complexes que les inserts.