J'aimerais quelques suggestions de ressources en ligne (blogs, guides, etc. - non forums) pour m'aider à devenir bon à la conception de bases de données SQL Server haute performance qui fonctionnent avec de grandes quantités de données et ont de lourdes charges en termes de rotation des données. et requêtes par minute.
suggestions?
La charge dont je parle est principalement en termes de rotation des données. La table principale comporte jusqu'à un million de lignes, environ 30 champs de données de taille variable et sont mis à jour avec environ 30-40000 nouvelles lignes par jour et au moins 200 000 lignes sont mises à jour chaque jour avec de nouvelles données. Ces mises à jour se produisent sur une base continue tout au long de la journée. De plus, toutes les modifications et les mises à jour doivent être tirées de la base de données tout au long de la journée pour garder un grand indice Lucene à jour.
4 Réponses :
Ceci est le sujet mieux exploré d'abord avec des livres car il est hautement technique et complexe.
Je vais souligner que les personnes qui ont créé ce site Web incluent plusieurs qui travaillent avec de très grandes bases de données. Vous pouvez apprendre beaucoup d'eux. http://lessthandot.com/
Voici quelques ressources sur le dépannage et l'optimisation des performances dans SQL Server, que j'ai trouvé vraiment utile:
http: / /updates.sqlservervideos.com/2009/09/Power-Up-With-SQL-Server-SQL-Server-Performance.html
En particulier, une utilisation efficace d'index peut être un énorme booster de performance. Je pense que la plupart des applications Web, dans la plupart des cas, font beaucoup plus de lecture que d'écrire. En outre, la sargabilité d'une expression peut avoir un impact sérieux sur la performance.
sonne comme une charge assez gérable sur un serveur modéré - vous n'avez pas dit quels types d'opérations de lecture se produisent alors que ces insertions et ces mises à jour se déroulent (autres que les extractions de Lucene) et la taille (octets-sage / Type de données-Wise) des données (la cardinalité que vous avez donnée semble bien).
À ce stade, je recommanderais simplement d'utiliser Meilleures pratiques régulières SQL Server - déterminer un schéma qui est approprié (normaliser, puis dénormaliser uniquement si nécessaire), Examiner les plans d'exécution < / a>, utilisez l'assistant de syntonisation d'index, Utilisez les DMVS < / a> Pour trouver les indices non utilisés et les supprimer, Choisissez des index en clustere soigneusement pour gérer les divisions de page, choisissez soigneusement les types de données et la taille et Utilisez l'intégrité référentielle et les contraintes dans la mesure du possible pour donner l'optim Izer autant d'aide aussi possible. Au-delà, ce sont des compteurs de performance et que votre installation de matériel / logiciel est réglée.
Dans beaucoup / sur la plupart des cas, vous n'avez jamais besoin d'aller au-delà de cela pour réinitialiser votre architecture.
Cependant, même après tout cela, si la charge de lecture est lourde, les inserts et les mises à jour peuvent provoquer des problèmes de verrouillage entre les lectures et les écrit, puis vous envisagez des décisions architecturales pour votre application.
Aussi, les millions de randonnées et 200K mises à jour par jour ne m'inquiètent pas - mais vous mentionnez Lucene (c'est-à-dire indexation de texte intégral), donc probablement certaines des colonnes sont plutôt grandes. Mise à jour de grandes colonnes et les exporter prennent évidemment beaucoup plus longtemps - et bien plus de bande passante et io. 30 colonnes dans une table de rangements étroits avec des colonnes de type de données traditionnelles constitueraient une histoire complètement différente. Vous voudrez peut-être consulter le profil de mise à jour et voir si vous devez partitionner la table verticalement pour déplacer certaines colonnes de la rangée (si elles sont grandes, elles seront déjà stockées hors de la rangée) pour améliorer le comportement de verrouillage.
Ainsi, la clé essentielle lorsque vous avez de lourdes chargée de lecture: les inserts et les mises à jour doivent être aussi rapides que possible, verrouillez le moins possible (éviter l'escalade de verrouillage), mettre à jour comme peu d'index que possible pour prendre en charge l'opération de lecture.
Si la charge de lecture est si lourde (de sorte que les insertions / mises à jour commencent au conflit) mais ne nécessite pas de 100% d'informations à jour (par exemple, un délai de 5 minutes ou 15 minutes n'est pas perceptible), vous pouvez avoir une lecture Seule la version de la base de données qui est maintenue (soit une réplication identique, indexée différemment pour la performance, dénormalisée ou modélisée différemment - comme un modèle dimensionnel). Peut-être que vos indices de Lucene peuvent contenir des informations supplémentaires pour que les opérations de lecture coûteuses reposent tous à Lucene - c'est-à-dire que Lucene devient couvrant pour de nombreuses grandes opérations de lecture, réduisant ainsi votre chargement de lecture sur la base de données aux lectures essentielles qui prennent en charge les inserts / mises à jour (celles-ci sont généralement Petites lectures) et la partie transactionnelle de votre application (c'est-à-dire que l'écran d'informations sur le service clientèle utiliserait la base de données régulière, tandis que votre tableau de bord horaire utiliserait la base de données secondaire).
Merci beaucoup pour la réponse détaillée - devront suivre cela pour tout digérer.
Les liens sont un 404 maintenant; Serais-je trop grossier pour demander des liens frais?
Pouvez-vous nous donner quelques idées de quelle charge vous attendez-vous s'il vous plaît?