Quelles grandes limitations dois-je attendre des serveurs SQL liés?

Notre produit est basé sur Microsoft SQL Server. Actuellement, nous utilisons trois bases de données et les avons toujours déployées sur une seule instance SQL Server.

Les trois bases de données sont OLTP, OLAP et audit. La base de données OLAP contient des données entrantes massives sur EOD provenant à la fois d'OLTP et d'audit, à l'aide de requêtes de bases de données croisées.

Des questions

Si nous devions déployer ces trois bases de données sur trois instances Standard Edition distinctes à l' intérieur d'un même serveur physique, et les lier ensemble à l'aide de la fonction de serveur lié de SQL Server:

1. Quelle sera la transparence du code d'application? À quel changement dois-je m'attendre?
2. Les données entrantes vers OLAP représentaient 50 à 100 000 lignes, 200 à 500 Mo de charge utile par EOD. Quelle baisse de performances dois-je attendre?
3. À quelles autres grandes limitations dois-je m'attendre?

Contexte

Actuellement, nous présentons notre premier client potentiel avec plus de 500 utilisateurs simultanés.

Nous rédigeons une spécification de serveur, qui comprend 64 cœurs et 256 Go de RAM. Pour que SQL Server utilise toutes ces ressources abondantes, le client devrait acheter Enterprise Edition, qui pour SQL Server 2016 n'est disponible qu'en licence par cœur.

Nous craignons que le coût des licences à lui seul (64 x 7400 $) les fasse baisser. Je pense donc à diviser la base de données en trois instances de l'édition Standard et à les relier ensemble, en espérant que la fonction de liaison sera transparente à partir du code de l'application.

Quelle sera la transparence du code d'application? À quel changement dois-je m'attendre?

Pas du tout transparent. Attendez-vous à des changements majeurs.

Vous devez être préparé à une dégradation très importante des performances.

La requête distribuée (le cadre des serveurs liés) utilise un modèle OLEDB général quel que soit le serveur à l'autre extrémité. Il est vrai qu'une cible SQL Server peut être en mesure d'offrir des informations plus complètes (métadonnées, statistiques, etc.), mais le résultat est encore loin d'être aussi étroitement intégré ou capable qu'une opération native entre bases de données.

Les requêtes distantes ont la réputation méritée de performances lentes et de mauvais choix de plan par l'optimiseur. Les instructions qui modifient des données (supprimer, insérer, mettre à jour, fusionner) sont particulièrement sujettes au fait que le modèle de base est souvent celui d'un curseur.

Si vous n'avez jamais besoin d'effectuer des requêtes inter-instances ad hoc , vous pouvez peut- être régler manuellement chaque requête stockée pour des performances acceptables, mais cela demande beaucoup de travail et le succès n'est en aucun cas garanti.

Pour les opérations en vrac cross-exemple, vous seriez beaucoup mieux en utilisant des opérations en vrac réel ( bcp, BULK INSERT, SSIS ... etc.) Entre les instances que l' utilisation de serveurs liés.

Cela dit, l'idée de base me semble beaucoup plus problématique qu'elle n'en vaut la peine. Spécifiez le matériel qui fonctionnera dans les limites de l'édition standard; ou, si le client requiert des performances supérieures, procurez-vous un plus gros serveur et utilisez Enterprise Edition.