Solution de stockage de données volumineuses et de haute concurrence SQLserver

Avec le nombre croissant d'utilisateurs et l'activité quotidienne et la valeur maximale qui montent en flèche, les performances de traitement des bases de données sont confrontées à d'énormes défis. Partageons le plan d'optimisation de la base de données pour la plate-forme actuelle des 100 000 pics. Discutez avec tout le monde et apprenez les uns des autres pour vous améliorer !

Cas : Plateforme de jeu.

1. Résoudre la concurrence élevée

Lorsque le nombre de connexions client atteint le pic, la maintenance et le traitement des connexions par le serveur ne seront pas fait ici pour le moment. Lorsque plusieurs demandes d'écriture sont envoyées à la base de données, plusieurs tables doivent être insérées à ce moment-là, en particulier certaines expressions qui sont stockées par dizaines de millions par jour. Au fil du temps, la manière traditionnelle d'écrire des données de manière synchrone n'est évidemment pas recommandée. . Après les expériences, , qui a été beaucoup amélioré grâce à l'insertion asynchrone, mais en même temps, certains sacrifices doivent être faits sur les performances de lecture des données en temps réel.

Il existe de nombreuses méthodes asynchrones. La méthode actuelle consiste à transférer les données de la table temporaire vers la table réelle via le travail à intervalles réguliers (5 min, 10 min... selon les paramètres requis).

1. Il existe le tableau original A, qui est également le tableau réellement utilisé lors de la lecture.

2. Créez B et C avec la même structure que la table A d'origine pour le traitement du transfert de données. Le processus de synchronisation est C->B->A.

3. Établissez le travail Job1 qui synchronise les données et la table qui enregistre l'état d'exécution du Job1. La chose la plus importante lors de la synchronisation est de vérifier l'état actuel du Job1 si les données du Job1 sont en cours de synchronisation. vers A, puis les données du serveur sont stockées dans C, puis les données sont importées vers B. Ce lot de données sera transféré vers A lors de l'exécution du prochain travail. Comme le montre la figure 1 :

Dans le même temps, afin de garantir la sécurité et de faciliter le dépannage, une procédure stockée qui enregistre l'intégralité de l'instance de base de données doit être utilisée pour vérifier la l'exécution du travail entraîne un délai plus court. Si une défaillance anormale se produit, le personnel concerné doit être informé rapidement par d'autres moyens. Par exemple, écrivez dans la table email et SMS, laissez un programme de notification TCP lire et envoyer régulièrement, etc.

Remarque : si les données d'une journée atteignent des dizaines de G et s'il existe des exigences de requête pour cette table (le partitionnement sera mentionné ci-dessous), l'une des meilleures stratégies est :

Vous peut synchroniser B avec plusieurs serveurs partageant la pression des requêtes et réduisant la concurrence entre les ressources. Étant donné que les ressources de l'ensemble de la base de données sont limitées, comme une opération d'insertion, un verrou partagé sera d'abord obtenu, puis une certaine ligne de données sera localisée via l'index clusterisé, puis mise à niveau vers un verrou intentionnel requis par SQL Server. demander un entretien de verrouillage différent en fonction de la taille de la mémoire, provoquant une concurrence pour les ressources. Par conséquent, la lecture et l'écriture doivent être séparées autant que possible et peuvent être divisées en fonction du modèle commercial ou des règles établies ; dans les projets de plateforme, la priorité doit être donnée à garantir que les données peuvent être insérées efficacement.

Inévitablement, l'interrogation du Big Data consommera certainement beaucoup de ressources. Si vous rencontrez une suppression par lots, vous pouvez passer à une méthode par lots cyclique (comme 2000 éléments à la fois), afin de ne pas provoquer ce problème. Le processus provoque le blocage de la bibliothèque entière, entraînant des bogues imprévisibles. Après pratique, c’est efficace et réalisable, mais cela ne fait que sacrifier l’espace de stockage. Les champs contenant une grande quantité de données dans la table peuvent également être divisés en nouvelles tables en fonction des exigences de la requête. Bien entendu, celles-ci doivent être définies en fonction des besoins de chaque scénario commercial, et une solution adaptée mais pas flashy peut être conçue.

2. Résoudre le problème de stockage

Si les données d'une seule table atteignent des dizaines de gigaoctets chaque jour, il est naturel d'améliorer la solution de stockage. J’aimerais maintenant partager mon propre plan pour rester en première ligne malgré les ravages de la flambée des données ! Voici un exemple pour partager mon humble opinion sur mon propre environnement :

Table de données existante A, une seule table ajoute 30 Go de données chaque jour et utilise la synchronisation asynchrone des données pendant le stockage. Certaines tables ne peuvent pas effacer les données après. partitionnement, vous pouvez également diviser les groupes de fichiers en groupes de fichiers et attribuer les groupes de fichiers à différents disques pour réduire la concurrence pour les ressources IO et assurer le fonctionnement normal des ressources existantes. Combinez maintenant les exigences pour conserver les données historiques pendant 5 jours :

1 À ce stade, vous devez utiliser le travail pour générer un plan de partitionnement basé sur la fonction de partition, tel que le partitionnement basé sur l'ID utilisateur ou le champ horaire. ;

2. Déplacer la table Après le partitionnement, la requête peut localiser rapidement une certaine partition via l'index correspondant

3. Transférer les données de partition inutiles vers une table avec la même structure et le même index ; via les partitions de fusion de tâches, puis effacez les données de ce tableau.

Comme le montre la figure 2 :

Capturez de longs temps de requête grâce au suivi des requêtes SQL et utilisez la procédure stockée intégrée de SQL sp_lock ou les vues dm_tran_locks et dblockinfo Affichez le type et la granularité des verrous qui existent sur l'instance actuelle.

Après avoir localisé l'instruction de requête spécifique ou la procédure stockée, prescrivez le bon médicament ! Le médicament guérit la maladie !

Ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article pourra apporter de l'aide à l'étude ou au travail de chacun. J'espère également soutenir le site Web PHP chinois !

Pour plus d'articles liés aux solutions de haute concurrence et de stockage de Big Data Sqlserver, veuillez prêter attention au site Web PHP chinois !