Comment évolue-t-on SQL Server 2008 ou 2012?

Comment dimensionner SQL Server 2008 (ou 2012)? À sa base, je comprends qu'il y a deux options:

Augmenter:

Si le processeur est lié, je peux clairement voir passer de 1 cœur de processeur à 2 à 4. Ou si l'utilisation de la RAM augmente, il suffit d'ajouter plus de RAM. SQL Server 2008/2012 prend-il réellement le relais et évolue-t-il de cette façon en supposant AUCUN changement de niveau d'application? Pour minimiser la spéculation, supposons que je ne fais pas quelque chose de stupide comme la gravure de cycles CPU, les jointures croisées, etc.

Échelle:

Il n'est pas très clair comment la mise à l'échelle fonctionnerait. Je veux dire, si j'ai ajouté un autre serveur SQL juste à côté du premier, comment la requête sait-elle sur quel serveur s'exécuter? Existe-t-il un équilibreur de charge à l'avant (et est-il fourni avec le logiciel SQL Server?)? Cela implique-t-il des changements au niveau de l'application pour une mise à l'échelle pour fonctionner? Ou dois - je ai Shard les données et ont un code personnalisé qui appelle le serveur de base de données correcte en fonction des données sharding clé?

J'apprécierais la contribution de personnes plus expérimentées.

SQL Server n'est pas évolutif en tant que tel . Il évolue.

Il y a 3 zones pour ce faire, sous réserve des limitations d'édition

• Cœurs de processeur
• RAM
• Espace de rangement

Et bien sûr, utilisez une édition supérieure, par exemple Enterprise

SQL Server ne partage pas et aucune de ces solutions (vous pouvez rechercher des solutions de partitionnement MySQL) ajoute de la complexité et des frais généraux à un système.

La mise à l'échelle d'un serveur (+ nœuds de secours / miroir) est généralement assez simple avec de la RAM, des SSD, plus de volumes de disque pour diffuser les E / S, des disques séparés pour tempdb et les journaux, etc.

En outre, si vous trouvez que SQL Server est lié au processeur, sa conception et / ou ses index et / ou ses requêtes sont mal écrits, sauf si vous avez une charge massive.

Comme le dit gbn, SQL n'est pas vraiment évolutif comme les autres RDBM. Cependant, il y a un aspect de la mise à l'échelle que beaucoup de gens négligent et c'est de toujours avoir un système distinct pour les rapports.

Ne laissez jamais les rapports s'exécuter contre la production. Construisez-vous une base de données de rapports sur un autre serveur.

Idéalement, votre système de génération de rapports ne contiendrait que les données dont les rapports ont besoin et serait structuré et optimisé différemment de votre système de production.

Les données seraient introduites dans le système de rapport selon les besoins (c.-à-d. Une mise à jour toutes les heures de la production, de l'alimentation quotidienne, etc.).

Une approche rapide et sale (et très inefficace) consiste simplement à avoir une copie complète de la base de données de production sur un autre serveur. Cette copie peut être conservée via des sauvegardes complètes, l'envoi de journaux de transactions, la mise en miroir (avec snapshot), la réplication, etc.

Je ne recommande cependant pas cette approche. Les sauvegardes complètes et restaurées prennent du temps, en particulier sur les grandes bases de données. La réplication est compliquée et problématique. L'envoi de journaux vous laisse une base de données en lecture seule. La mise en miroir avec des instantanés peut être une bonne réponse, mais vous êtes toujours bloqué avec un schéma de production qui n'est pas optimisé à des fins de génération de rapports.

Un système de déclaration distinct est la voie à suivre.

Si le processeur est lié, je peux clairement voir passer de 1 cœur de processeur à 2 à 4. Ou si l'utilisation de la RAM augmente, il suffit d'ajouter plus de RAM. SQL Server 2008/2012 prend-il réellement le relais et évolue-t-il de cette façon en supposant AUCUN changement de niveau d'application?

Les différentes éditions de SQL Server ont des limitations différentes en termes de CPU et de mémoire qu'elles vont utiliser. Mais à part cela, la réponse est oui - si des cycles de CPU ou des pages mémoire vacants sont disponibles, le serveur va généralement les utiliser en cas de besoin, sauf configuration contraire.

Ou dois-je partager les données et avoir un code personnalisé qui appelle le bon serveur de base de données

Fondamentalement, oui. La «mise à l'échelle» est souvent effectuée lorsque vous devez éviter les conflits de verrouillage. Si vous avez des requêtes de longue durée avec un verrouillage étendu, vous souhaiterez peut-être les séparer des requêtes interactives "en temps réel" ou des cycles de mise à jour de requête démarrés par des utilisateurs utilisant une sorte d'interface et attendant une réponse rapide. Évidemment, prendre soin de cela nécessiterait des changements d'application (ou au moins des changements de middleware, si vous avez une conception à 3 niveaux).