Y a-t-il un avantage à établir plusieurs connexions à la base de données pour les insertions SQL ?

Question

J'écris un projet lié à l'acquisition massive de données. Actuellement, j'utilise .NET Framework 4.8 et le package Mysql pour initier des connexions et insérer des données dans le serveur de base de données.

Je vais insérer environ 400 000 lignes/seconde. Je crains que la connexion SQL ne devienne un goulot d'étranglement pour mon programme. Je veux savoir si j'utilise SQL pour créer une connexion multithread et utiliser la file d'attente du consommateur pour insérer des données, cela sera-t-il plus rapide et en vaudra-t-il la peine (avantages et inconvénients) ?

Dans mon instinct, ce serait plus rapide, mais je ne suis pas sûr des performances que cela fournirait en termes de surcharge de thread. Je ne suis pas un expert SQL, ce serait donc formidable si quelqu'un pouvait expliquer les avantages et les inconvénients de l'ouverture de plusieurs connexions SQL sur plusieurs threads.

Answer 1

Rumeurs, opinions, ouï-dire, faits, benchmarks liés aux versions, quelques expériences personnelles, etc...

Plusieurs threads peuvent améliorer le débit, mais il existe des limites :

• La limite supérieure du débit est d'environ la moitié de la limite théorique. (votre "certain pourcentage") (Il s'agit d'un benchmark basé sur un package multithread ; j'ai oublié le nom ; c'était il y a dix ans.)
• Plusieurs threads seront en compétition les uns avec les autres sur les mutex et autres mécanismes de verrouillage nécessaires.
• À partir de la version 5.7, 64 threads constituent la limite multithread pour MySQL ; au-delà de cela, le débit stagne, voire chute. (Source : de nombreux benchmarks Oracle se vantent qu'une version est nettement meilleure que la précédente.) (Pendant ce temps, la latence par thread atteint des sommets.)
• Si possible, chaque thread doit traiter les données par lots.

Traitement par lots :

• LOAD DATA 是一次从单个线程 INSERT 大量行的最快方法。但是，如果您包括将文件写入 LOAD coût, ce qui peut le rendre plus lent que l'insertion par lots.
• Batch INSERT suit. Mais il est plafonné à « centaines » de lignes lorsqu'une certaine limite ou des « rendements décroissants » sont atteints.
• Les insertions par lots sont 10 fois plus rapides que l'insertion d'une ligne par INSERT 查询插入一行的速度的 10 倍。因此，它（或 LOAD DATA requête. Par conséquent, il (ou LOAD DATA) vaut la peine d'être utilisé pour une ingestion à grande vitesse. (Source : De nombreux différents tests chronométrés.)

Source des données :

• Certaines sources de données ne doivent transmettre qu'une seule ligne à la fois (par exemple, les données des capteurs d'un véhicule toutes les N secondes). Cela nécessite une couche intermédiaire pour traiter les données par lots.
• Discussion sur la collecte de données : http://mysql.rjweb.org/doc.php /staging_table

Que se passe-t-il après le chargement des données ? Bien entendu, il ne s’agit pas d’une table en écriture seule.

• La normalisation est utile pour réduire l'encombrement du disque ; il est préférable de l'effectuer par lots. Voir Standardisation
• PARTITIONing Rarement utile, à part éventuellement effacer les anciennes données. Voir Partition
• Les énormes tableaux de « faits » sont difficiles à rechercher ; pensez à créer des données récapitulatives au fur et à mesure que vous ingérez : Tableaux récapitulatifs
• Vous pouvez même effectuer le traitement ci-dessus, puis jeter les données originales. Il semble que vous receviez un téraoctet de données par jour.