Tableaux Azure ou SQL Azure?

Question

Je suis au stade de la planification d'une application Web qui sera hébergé dans Azure avec ASP.NET pour le site Web et Silverlight dans le site pour une expérience utilisateur riche. Dois-je utiliser les tableaux Azure ou SQL Azure pour stocker mes données d'application?

Answer 1

Azure Table de stockage semble être moins coûteux que SQL Azure. Il est également plus hautement évolutive que SQL Azure.

SQL Azure est plus facile de travailler avec si vous avez fait beaucoup de travail de base de données relationnelle. Si vous migrez une application qui utilisait déjà une base de données SQL, puis de passer à SQL Azure serait le choix évident, mais c'est la seule situation où je le recommande.

La principale limite sur les tableaux Azure est l'absence d'indices secondaires. Cela a été annoncé au PDC '09 et est actuellement sur la liste à venir bientôt, mais il n'y a pas eu d'annonce-délai. (Voir http : //windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes ref = title )

Je l'ai vu l'utilisation proposée d'un système hybride où vous utilisez la table et le stockage blob pour la plus grande partie de vos données, mais utilisez SQL Azure pour les index, la recherche et le filtrage. Cependant, je ne l'ai pas eu la chance d'essayer cette solution encore moi-même.

Une fois que les index secondaires sont ajoutés au stockage de la table, il sera essentiellement un nuage à base NoSQL système et sera beaucoup plus utile que maintenant.

Answer 2

Malgré des noms similaires tables SQL Azure et table de stockage ont très peu en commun.

Voici deux liens qui pourraient vous aider:

• Table de stockage, une 100x facteur de coût
• entités Fat sur le tableau de stockage

En gros, devrait se demander est de la première question Mon application vraiment besoin à l'échelle? Sinon, pour aller SQL Azure.

Answer 3

Pour ceux qui essaient de choisir entre les deux options, assurez-vous d'exigences de déclaration de facteur dans l'équation. rapports SQL Azure et d'autres produits d'information prennent en charge SQL Azure hors de la boîte. Si vous avez besoin de générer des rapports complexes ou souples, vous voudrez probablement éviter le tableau de stockage.

Answer 4

tables Azure sont moins chers, plus simple et échelle mieux que SQL Azure. SQL Azure est un environnement SQL géré, multi-locataire dans la nature, vous devez donc analyser si vos exigences de performance sont propres à SQL Azure. Une version premium de SQL Azure a été annoncée et est en avant-première de cette écriture (voir pour une orientation initiale.

Answer 5

Une autre considération est la latence. Il y avait un site que Microsoft a couru avec microbenchmarks sur le débit et la latence des différentes tailles d'objets avec magasin de table et SQL Azure. Depuis ce site est plus disponible, je vais vous donner une approximation grossière de ce que je me souviens. magasin de table a tendance à avoir un débit beaucoup plus élevé que SQL Azure. SQL Azure a tendance à avoir une latence plus faible (par autant que 1 / 5ème).

Il a déjà été mentionné ce magasin de table est facile à l'échelle. Cependant, SQL Azure peut évoluer aussi bien avec Fédérations . Notez que les fédérations (efficace sharding ) ajoute beaucoup de complexité à votre application. Je suis également pas sûr combien les fédérations affecte la performance, mais je pense qu'il ya certains frais généraux.

Si la continuité des activités est une priorité, considérer que, avec stockage Azure vous obtenez géo-réplication pas cher par défaut. Avec SQL Azure, vous pouvez accomplir quelque chose de similaire, mais avec plus d'efforts avec SQL Sync . Notez que SQL Sync performances également par une surcharge car il nécessite des déclencheurs sur toutes vos tables pour surveiller les changements de données.

Answer 6

Je sais que c'est une question ancienne, mais encore très valable, donc j'ajouter ma réponse à lui.

CoderDennis et d'autres ont souligné quelques-uns des faits - Tables Azure est moins cher, et les tableaux Azure peut être beaucoup plus grande, plus efficace, etc. Si vous êtes 100% sûr que vous en tenir à Azure, rendez-vous avec les tables.

Cependant, cela suppose que vous avez déjà décidé sur Azure. En utilisant les tableaux Azure, vous vous enfermer dans la plate-forme Azure. Cela signifie l'écriture de code très spécifique aux tables Azure qui est non seulement en direction du port sur Amazon, vous devrez réécrire ces zones de votre code. D'autre part, la programmation d'une base de données SQL avec port volonté LINQ sur beaucoup plus facilement à un autre service de cloud.

Cela peut ne pas être un problème si vous avez déjà décidé de votre plate-forme de nuage.

Answer 7

Je suggère à la recherche sur Azure Cache en combinaison avec le tableau Azure. Tableau seul a 200-300ms latences, avec des pointes occasionnelles plus élevées, ce qui peut ralentir les temps de réponse vers le bas / interactivité interface utilisateur. Cache + table semble être une combinaison gagnante pour moi.

Answer 8

Pour votre question, je veux parler de la façon de décider avec la logique SQL choisir le tableau et qui ont besoin d'utiliser le tableau Azure.

Comme nous le savons table SQL est un moteur de base de données relationnelle. mais si vous avez un gros volumes de données dans une table de la table SQL est pas applicable, car requête SQL obtenir les données importantes est lente.

A ce moment, vous pouvez choisir Azure Table, la table de requête Azure est si rapide puis table SQL pour les grandes données, par exemple, dans notre site Web, quelqu'un a souscrit de nombreux articles, nous faisons l'article dans l'alimentation à l'utilisateur, chaque utilisateur a une copie de l'article titre et la description, donc dans le tableau de l'article il y a beaucoup de données, si nous utilisons SQL tableau, chaque exécution de la requête peut-être prendre plus de 30 secondes. Mais dans Azure Table obtenir les utilisateurs article par flux PartitionKey et RowKey est si rapide.

De cet exemple, vous savez peut-être comment choisir entre SQL dans le tableau et le tableau Azure.

Answer 9

Je me demande si nous allons finir avec quelques bibliothèques cloud api de « fournisseur indépendant » en temps utile?

Answer 10

Je pense que vous devez d'abord définir ce que vos entonnoirs d'utilisation des applications sont. Est-ce que votre modèle de données est soumis à des changements fréquents ou il est d'une écurie? Vous devez être en mesure d'effectuer des inserts ultra rapide et lit ne sont pas si compliqué? Avez-vous besoin progressez google comme la recherche? Le stockage BLOBS?

Ce sont les questions (et non seulement) que vous devez demander et vous répondre afin de décider si vous allez plus susceptibles d'utiliser l'approche NoSQL ou SQL dans le stockage de vos données.

S'il vous plaît considérer que les deux approches peuvent coexister facilement et peut être étendue avec le stockage BLOB ainsi.

Answer 11

Les deux tableaux et SQL Azure sont deux beasts.Both différents Azure sont destinés à différents scénarios, un con à azur table est que vous ne pouvez pas passer d'azur à une autre plate-forme, à moins que vous écrivez des fournisseurs dans votre code qui peut gérer ces changements .