Je développe une application Web et j'utilise actuellement SQL Server 2008 pour cela. Mais je envisage de passer à une autre base de données (SimplesDB) pour améliorer les performances.
J'ai un processus d'arrière-plan qui insère jusqu'à 10000 rangées toutes les heures dans une table spécifique. Cette table est également lue de pour afficher les données dans l'application Web. Lorsque le processus d'arrière-plan est exécuté, l'application Web est inutilisable car la connexion DB est terminée.
En conséquence, je pense à passer à la simplicité d'Amazon pour améliorer les performances. La simplicité d'Amazon est-elle optimisée pour ce cas d'utilisation? Sinon, y a-t-il une autre solution que je pourrais utiliser?
4 Réponses :
Under 3 Les inserts par seconde ne vont pas donner une séance d'entraînement à la SGBM si la quantité de données à insérer dans chaque opération d'insertion est phénoménale. De même, 10 lectures par seconde sont peu susceptibles de trop contraintes tout SGBD compétent, sauf s'il y a un facteur de complication que vous n'avez pas mentionné (telles que "les lectures sont des agrégats d'agrégats sur l'ensemble du SGBD qui accumulera des milliards de documents après une période donnée. de ... Eh bien, 100 000 heures pour le premier milliard d'enregistrements, soit environ 4 000 jours, soit environ 10 ans).
Votre problème est le niveau d'isolement que vous utilisez. Sauf si vous le modifiez, SQL Server (et de nombreuses autres bases de données) fonctionnent en mode qui sélectionne bloquera des lectures non engagées. Vous souhaitez modifier SQL Server de telle qu'il utilise MVCC à la place (la valeur par défaut pour Oracle; MySQL et SQL Le serveur l'a à la fois aussi) et votre problème disparaîtra.
de Définir le niveau d'isolation de transaction (transact-sql) : < / p>
Lisez commis
Spécifie que les déclarations ne peuvent pas lire données qui ont été modifiées mais non commis par d'autres transactions. Cette empêche les lectures sales. Les données peuvent être changé par d'autres transactions entre déclarations individuelles dans le transaction en cours, entraînant Lectures non remboursables ou données fantômes. Cette option est la valeur par défaut SQL Server.
Le comportement de la lecture commise dépend sur le cadre de la LIVE_COMMITTED_SNAPSHOT Database Option:
- Si read_committed_snapshot est défini sur OFF (par défaut), le moteur de base de données utilise des verrous partagés pour empêcher les autres transactions de modification des lignes pendant La transaction actuelle exécute un Lire l'opération. les serrures partagées aussi bloquer la déclaration des lignes de lecture modifié par d'autres transactions jusqu'à ce que L'autre transaction est terminée. Le type de verrouillage partagé détermine quand Ce sera libéré. Les serrures de rangées sont libéré avant la prochaine ligne est traité. Les serrures de page sont libérées lorsque la page suivante est lue, et tableau Les serrures sont libérées lorsque la déclaration Finitions.
- Si read_commTaD_Snapshot est défini sur On, le moteur de base de données utilise la ligne Versioning pour présenter chaque déclaration avec un cohérent transactionnellement instantané des données comme il existait à le début de la déclaration. Les serrures sont non utilisé pour protéger les données de mises à jour par d'autres transactions.
quand le lecture_commoded_snapshot L'option de base de données est activée, vous pouvez utiliser le ReadCommouverte table indique à Demander un verrouillage partagé au lieu de la ligne Vérification des déclarations individuelles dans les transactions fonctionnant à la lecture Niveau d'isolement engagé.
(emphase ajoutée)
Changez votre configuration de base de données pour activer lecture_commoded_snapshot sur ON.
Aussi, essayez de conserver vos transactions aussi courtes que possible et assurez-vous de vous engager la transaction dans votre processus d'arrière-plan (cela fait les 10 000 insertions d'une heure) car si elle ne se déclenche jamais, alors sélectionnera pour toujours (en défaut Paramètres).
Les transactions courtes sont essentielles pour éviter le blocage.
Comprendre les transactions et l'impasse est absolument essentielle pour comprendre comment fonctionne des bases de données relationnelles / transactionnelles. Pour plus, voir: rhphost.com/sql-tandard/8277Final/lib0058.html
Merci, cela semble résoudre le problème. Site Web charge sans problèmes lors des insertions maintenant.
Comme d'autres l'ont dit, la quantité de données que vous écrivez dans la base de données n'est pas un problème. SQL Server peut facilement gérer beaucoup plus de données que cela. Personnellement, j'ai des tables qui prennent des centaines de milliers de dollars à des millions de lignes à l'heure sans problème et les gens lisent les rangées toute la journée sans ralentissement.
Vous devrez peut-être consulter des lectures sales en modifiant le niveau d'isolement des relevés de lecture ou en utilisant l'indice avec (nolock).
Vous devez regarder à l'aide de l'objet de téléchargement en vrac dans .NET pour charger vos données dans la base de données. Utilisez des lots de 1000-5000 en fonction des performances que vous voyez lors des tests. Vous aurez besoin de jouer avec le numéro pour obtenir la meilleure performance. L'insertion en vrac insertion de données dans la table vous donnera une performance spectaculaire mieux que l'insertion de la ligne d'enregistrements à la ligne. Assurez-vous de ne pas faire tout le téléchargement en une seule transaction. Vous devriez faire une transaction par lot.
À quoi ressemble le disque IO lorsque vous écrivez dans la base de données?
Quel modèle de récupération avez-vous défini pour la base de données? La récupération complète de la base de données nécessitera beaucoup plus d'IO que d'utiliser le mode de récupération simple. Utilisez uniquement la récupération complète si vous avez besoin du point de restauration de temps qui l'accompagne.
Dans un suivi de la réponse de Joel, vous devrez peut-être envisager de définir des valeurs appropriées pour PAD_IDEX et FILLFCEDOR sur vos index. Si vous n'avez pas spécifié ces options, vos insertions peuvent faire beaucoup de ré-pagination sur vos index, ce qui ralentirait considérablement vos temps d'écriture de manière significative.
10 000 inserts / HR = 2.7 ... / SEC ne doivent pas tuer une base de données. MySQL et PostgreSQL peuvent facilement faire cela. SQL Server devrait vraiment pouvoir aussi bien.
C'est ce que je pensais ... mais je reçois des blocages. La table est verrouillée pendant les insertions et donc les stalles de l'application Web car il ne peut pas lire les données de la DB lorsque le processus d'arrière-plan insère des données.
@RksPst: Une impasse est probablement survenue, non pas à cause du volume de données, mais avec la manière dont les données se frayient un chemin dans cette table.
Pourquoi 10 000 écrit-il par heure "HIGH", mais 36 000 sont des lectures par heure "faible" (10 / sec * 3600 sec / heure)?
Eh bien, je pose des API et effectuez un certain traitement des résultats, puis les données sont insérées à l'aide de LINQ.
Il y a le premier problème juste là. Les inserts de rangée par rangée sont le moyen le moins efficace d'obtenir des données dans une table SQL Server. Voir ma réponse ci-dessous sur l'insertion des données en vrac.
En tant que commentaire sur les commentaires, il ne faut pas se souvenir d'une heure d'heure ne se traduit pas par une seconde moyenne. Souvent, il y a des rafales. C'est là que la nécessité d'une performance accrue pourrait venir.