Azure SQL Database vs MS SQL Server sur une machine dédiée
J'exécute actuellement une instance de MS SQL Server 2014 (12.1.4100.1) sur une machine dédiée que je loue pour 270 $/mois avec les spécifications suivantes:
- Processeur Intel Xeon E5-1660 (six cœurs physiques 3,3 GHz + hyperthreading + turbo-> 3,9 GHz)
- Mémoire ECC DDR3 enregistrée de 64 Go
- SSD Intel de 240 Go
- 45000 Go de transfert de bande passante
Je joue avec Azure SQL Database depuis un petit moment maintenant, et j'ai eu l'idée de passer à leur plate-forme. J'ai lancé une base de données Azure SQL en utilisant leur niveau de tarification P2 Premium sur un serveur V12 (juste pour tester les choses) et j'ai chargé une copie de ma base de données existante (à partir de la machine dédiée).
J'ai exécuté plusieurs ensembles de requêtes côte à côte, un contre la base de données sur la machine dédiée et un contre la base de données P2 Azure SQL. Les résultats ont été quelque peu choquants: ma machine dédiée a surperformé (en termes de temps d'exécution) la base de données Azure d'une énorme marge à chaque fois. En règle générale, l'instance de base de données dédiée se terminait en moins de 1/2 à 1/3 du temps nécessaire à l'exécution de la base de données Azure.
Maintenant, je comprends les nombreux avantages de la plateforme Azure. Il est géré par rapport à ma configuration non gérée sur la machine dédiée, ils ont une restauration ponctuelle meilleure que la mienne, le pare-feu est facilement configuré, il y a de la géoréplication, etc., etc. Mais j'ai une base de données avec des centaines de tables avec des dizaines à des centaines de millions d'enregistrements dans chaque table, et ont parfois besoin d'interroger sur plusieurs jointures, etc., donc les performances en termes de temps d'exécution sont vraiment importantes. Je trouve juste choquant qu'un service de ~ 930 $/mois fonctionne mal à côté d'une location de machine dédiée de 270 $/mois. Je suis encore assez nouveau pour SQL dans son ensemble, et très nouveau pour les serveurs/etc., Mais cela ne s'ajoute-t-il à personne d'autre? Quelqu'un a-t-il peut-être un aperçu de quelque chose qui me manque ici, ou les autres fonctionnalités "gérées" d'Azure SQL Database sont-elles censées compenser la différence de prix?
En bout de ligne, je commence à dépasser même les capacités de ma machine dédiée, et j'espérais vraiment que la base de données SQL d'Azure serait un bon tremplin, mais à moins que je manque quelque chose, ce n'est pas le cas. Je suis encore une petite entreprise pour sortir et dépenser des centaines de milliers sur une autre plate-forme.
Quelqu'un a-t-il des conseils sur si je manque quelque chose, ou les performances que je vois correspondent-elles à ce que vous attendez? Ai-je d'autres options qui peuvent produire de meilleures performances que la machine dédiée que j'utilise actuellement, mais ne coûtent pas des dizaines de milliers/mois? Puis-je faire quelque chose (configuration/paramètre) pour ma base de données SQL Azure qui augmenterait le temps d'exécution? Encore une fois, toute aide est appréciée.
EDIT: Permettez-moi de réviser ma question pour peut-être la rendre un peu plus claire: c'est ce que je vois en termes de performances de temps d'exécution à prévoir, où un serveur dédié @ 270 $/mois surpasse bien le niveau Azure SQL DB P2 P2 de Microsoft @ 930 $/mois? Ignorez les autres "avantages" comme géré vs non géré, ignorez l'utilisation prévue comme Azure étant destiné à la production, etc. J'ai juste besoin de savoir si je manque quelque chose avec Azure SQL DB, ou si je suis vraiment censé améliorer BEAUCOUP mieux performances sur une seule machine dédiée.
Il existe une alternative de Microsoft à Azure SQL DB:
"Provisionner une machine virtuelle SQL Server dans Azure"
https://Azure.Microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/
Une explication détaillée des différences entre les deux offres: "Comprendre Azure SQL Database et SQL Server dans les machines virtuelles Azure"
Une différence significative entre votre SQL Server autonome et Azure SQL DB est qu'avec SQL DB, vous payez pour des niveaux de disponibilité élevés, ce qui est obtenu en exécutant plusieurs instances sur différentes machines. Ce serait comme louer 4 de vos machines dédiées et les exécuter dans un groupe de disponibilité AlwaysOn, ce qui changerait à la fois vos coûts et vos performances. Cependant, comme vous n'avez jamais mentionné la disponibilité, je suppose que ce n'est pas un problème dans votre scénario. SQL Server dans un VM peut mieux correspondre à vos besoins.
Perf et disponibilité mis à part, il y a plusieurs autres facteurs importants à considérer:
- Coût total: votre coût de location de 270 $ n'est qu'un des nombreux facteurs de coût. L'espace, la puissance et la cvc sont d'autres coûts physiques. Ensuite, il y a le coût de l'administration. Pensez au travail que vous devez effectuer chaque correctif mardi et lorsque Windows ou SQL Server envoie un service pack ou une mise à jour cumulative. Même si vous ne les testez pas avant de les déployer, cela prend encore du temps et des efforts. Si vous testez, il y a une deuxième machine et la duplication de l'instance de produit et de la charge de travail pour le test.
- Sécurité: il y a BEAUCOUP écrit sur la façon dont il est mauvais, dangereux et risqué de stocker toutes les données qui vous intéressent dans le cloud. Personnellement, j'ai vu des implémentations et des processus de sécurité bien pire avec les serveurs locaux (même dans les banques et les agences fédérales) que je n'ai vu avec aucun des principaux fournisseurs de cloud (Microsoft, Amazon, Google). Il faut beaucoup de travail pour bien faire les choses, puis encore plus de travail pour les garder bien. En outre, vous pouvez voir et auditer leurs SLA de sécurité (voir Azure à http://Azure.Microsoft.com/en-us/support/trust-center/ ).
- Évolutivité: pas seulement l'évolutivité brute, mais le coût et l'effort de mise à l'échelle. Azure SQL DB a récemment publié l'énorme édition P11 qui a 7 fois la capacité de calcul du P2 avec lequel vous avez testé. La montée et la descente ne sont pas instantanées mais vraiment faciles et raisonnablement rapides. La meilleure partie est (pour moi de toute façon), elle peut être renvoyée à une édition supérieure lorsque j'exécute des requêtes volumineuses ou des opérations de réindexation, puis redescends pour des charges "normales". C'est difficile à faire avec un serveur SQL Server classique sur du métal nu - louez/achetez une très grosse boîte qui reste inactive 90% du temps ou prenez un temps d'arrêt pour vous déplacer. Un peu plus facile si dans une machine virtuelle; vous pouvez augmenter la mémoire en ligne, mais vous devez toujours faire rebondir l'instance pour augmenter le processeur; votre base de données Azure SQL reste en ligne pendant les opérations de montée/descente.
(Avertissement: je travaille pour Microsoft, mais pas sur Azure ou SQL Server).
"Azure SQL" n'est pas équivalent à "SQL Server" - et je souhaite personnellement que nous proposions une sorte de "SQL Server hébergé" au lieu d'Azure SQL.
En apparence, les deux sont les mêmes: ce sont tous deux des systèmes de bases de données relationnelles avec la puissance de T-SQL pour les interroger (enfin, ils utilisent tous deux le même SGBD sous le capot).
Azure SQL est différent en ce que idée est que vous avez deux bases de données: une base de données de développement utilisant un serveur SQL local (idéalement 2012 ou version ultérieure) et une base de données de production sur Azure SQL. Vous (ne devez) jamais modifier directement la base de données Azure SQL, et vous constaterez en effet que SSMS n'offre pas d'outils de conception (Table Designer, View Designer, etc.) pour Azure SQL. Au lieu de cela, vous concevez et travaillez avec votre base de données SQL Server locale et créez des fichiers "DACPAC" (ou des fichiers XML spéciaux "change", qui peuvent être générés par SSDT) qui modifient ensuite votre base de données Azure de telle sorte qu'elle copie votre base de données de développement, une sorte du système de "réplication de conception".
Sinon, comme vous l'avez remarqué, Azure SQL offre une résilience intégrée, des sauvegardes, une administration simplifiée, etc.
En ce qui concerne les performances, est-il possible que vous manquiez des index ou d'autres optimisations? Vous pouvez également remarquer une latence légèrement plus élevée avec Azure SQL par rapport à un serveur SQL local, j'ai vu des temps de ping (d'un Azure VM à un hôte Azure SQL) autour de 5-10 ms, ce qui signifie vous devez concevoir votre application pour qu'elle soit moins bavarde ou pour paralléliser les opérations de récupération de données afin de réduire les temps de chargement des pages (en supposant qu'il s'agit d'une application Web que vous créez).
SQL DB a une disponibilité intégrée (qui peut avoir un impact sur les performances), une capacité de restauration ponctuelle et des fonctionnalités DR. Vous avez la possibilité d'augmenter/réduire votre base de données en fonction de votre utilisation pour réduire le coût. Vous pouvez améliorer les performances de votre requête à l'aide de la requête globale (données de partition). SQl DB gère les mises à niveau automatiques et les correctifs et améliore considérablement la facilité de gestion. Vous devrez peut-être payer une petite prime pour cela. La mise en cache au niveau de l'application/la répartition uniforme de la charge, la rétrogradation à froid, etc. peuvent aider à améliorer les performances de votre base de données et à optimiser le coût.