Quand devrais-je utiliser Sql Azure et quand devrais-je utiliser table Storage?

Question

Quand devrais-je utiliser Sql Azure et quand devrais-je utiliser table Storage? Je pensais, utiliser le stockage de table pour les scénarios de traitement des transactions, par exemple les comptes de crédit, et utiliser Sql Azure lorsque les données ne seront pas utilisées à des fins transactionnelles, par exemple la création de rapports. Qu'est-ce que tu penses?

Answer 1

c'est une excellente question et l'un des plus difficile et plus difficile à renverser les décisions de cette solution, les architectes ont à faire lors de la conception pour Azure.

Il y a plusieurs dimensions à prendre en compte: Sur le côté négatif, SQL Azure est relativement cher pour gigaoctet de stockage, n'est pas super bien et il est limité à 150gigs/base de données, cependant, et ceci est très important, il n'y a pas de frais de transaction par rapport à SQL azure et vos développeurs savent déjà comment code contre elle.

ATS est un animal différent tous ensemble. Capeable de megascalability, il n'est vraiment pas cher pour stocker, mais se coûteux pour accéder fréquemment. Il exige aussi de la quantité importante de la puissance du PROCESSEUR de votre nœuds à manipuler. Il baiscally les forces de vos nœuds de calcul, de devenir des mini-db serveurs ainsi que la délégation de toutes les activité relationnelle est tourné vers eux.

Donc, à mon avis, les données les plus fréquemment utilisées qui n'a pas besoin énorme d'évolutivité et n'est pas super grande taille devrait être destinée à SQL Azure, sinon Azure Services de Table.

Votre exemple, les données de transactions de transactions financières est un endroit parfait pour les ATS, tandis que les méta-informations (profils de compte, des noms, des adresses, etc.) Est parfait pour SQL azure.

Hth

Answer 2

Igor et Mark a donné beaucoup de réponses. Permettez-moi d'ajouter juste un peu plus...

Avec Base de données SQL (anciennement nommée de SQL Azure), vous pouvez désormais disposer de bases de données jusqu'à 500 go. Pour aller au-delà de cela, vous auriez besoin de la partition de vos données. Note: a l'Origine, j'ai suggéré éclats avec SQL Fédérations, mais cette fonctionnalité a depuis été retiré.

ATS offre des transactions au niveau de la partition (entité du groupe de transactions). Voir cet article MSDN pour plus d'informations. Ce n'est pas aussi robuste que SQL Azure transactions, mais il ne permet pas pour les opérations par lots en une seule transaction.

MODIFIER Ça fait plus d'un an, depuis que cette question a été posée (et réponse). Un point de comparaison était sur les prix. Alors que SQL Azure est encore plus cher que l'ATS, le coût de SQL Azure a diminué considérablement au cours de la dernière année. Les bases de données ont maintenant des niveaux de prix, à partir de $4,99 pour 100 MO, l'augmentation de 225 $pour 150 GO (une grosse baisse de $9.99 / GB prix de l'année dernière. Plein de détails sur les prix sont ici.

MODIFIER Août 2014 un an plus tard, une autre mise à jour. Alors que le web/business niveaux continuent d'exister, ils sont pris fin (et SQL Fédérations n'est plus disponible). La nouvelle Base, Standard et Premium niveaux sont maintenant disponibles (voir ici pour les détails).

Answer 3

Certaines de ces réponses ne semblent pas complète, donc je vais ajouter mes 2 cents.

Azure Table est Bon points:

• Le point fort est sa capacité à stocker beaucoup de peu de données; Azure table est basée sur Azure Blob, mais est orienté vers les petites données
• Beaucoup moins cher que d'Azure SQL Server
• À tout moment vous connaissez la partition de la clé et la clé de la ligne, l'accès aux données est très rapide.
• Entity transactions sont possibles si vous placez deux des "schémas" de la même clé de partition.
• Lorsque la taille totale de la ligne est inférieure à 980K (SQL Ligne)
• Où chaque propriété est inférieure à 64 ko (Colonne SQL)
• Il peut agir comme un homme pauvre SQL.

Azure table du mauvais points:

• SQL est le point faible. Ne vous attendez pas à l'utiliser sur n'importe quelle grande table SQL ou vous allez souffrir de problèmes de performance.
• Limitée SQL est disponible, ne pas attendre que les jointures de tout type, en plus de ce que vous mettre en œuvre dans Linq
• Azure Table SQL n'a pas d'échelle ainsi que sa capacité à stocker une quantité infinie de données
• À tout moment vous n'avez pas à spécifier à la fois une clé de partition et la touche de ligne dans une clause where, s'attendre à une lente analyse de la table à se produire
• Attendre tableau d'analyse de la performance à se dégrader à mesure que vous ajoutez plus de lignes
• Ne vous attendez pas Azue requêtes de Table pour être le plus rapide à mesure que vous ajoutez plus de lignes
• En bout de ligne, si vous utilisez Azure Table d'agir comme SQL ne pas ajouter beaucoup de données. Si vous avez beaucoup de données (giga-octets), il suffit de ne pas plan sur l'obtention de hautes performances des requêtes SQL. Vous allez économiser de l'argent si vous n'avez pas besoin de ces fonctions SQL.

Answer 4

Quand il s'agit de transactions, c'est juste l'inverse: SQL Azure prend en charge les transactions; le tableau de stockage ne fonctionne pas.

SQL Azure est fondamentalement l'exécution de SQL Server à l'intérieur de Windows Azure, donc si vous avez une application existante qui utilise SQL Server, SQL Azure fournit un bon chemin de migration. Cependant, il y a des limites à la façon dont grand d'une base de données sur SQL Azure (actuellement 150 GO), donc il y a des limites à combien il peut l'échelle.

Table de stockage, d'autre part, est extrêmement évolutive, mais nécessite une façon différente de penser. C'est pas une base de données relationnelle. Voir par exemple cet article pour une belle introduction: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Answer 5

La vraie réponse est, "Essayez vraiment dur de ne pas utiliser Azure Table Storage". Chaque fois que vous vous déplacez d'un relationnel à un no-sql DB, vous êtes bien sûr allez avoir à changer la façon dont vous pensez à votre architecture de stockage. Mais les problèmes avec l'ATS aller bien au-delà de juste besoin de "penser différemment". Comme d'autres personnes l'ont souligné, il n'est pas juste un "No-SQL" data-store, il est particulièrement retard de croissance, des personnes handicapées, et de très-faible-vedette instance d'un No-SQL magasin. Ce n'est pas une question de besoin de "penser différemment" à propos de l'ATS; c'est une question de ATS de ne pas vous donner les outils dont vous avez besoin pour faire votre travail - outils autres no-sql banques de données, ne vous donner.

Sur la seule bonne chose à propos de l'ATS est que vous pouvez mettre beaucoup, beaucoup de données très rapidement et avec un minimum de frais de stockage. Cependant, fondamentalement, vous ne pouvez pas espérer obtenir des données de retour à nouveau, sauf si vous êtes assez chanceux pour avoir un cas d'utilisation qui correspond comme par magie sa Partition-Clé/Ligne-Clés modèle de stockage. Si vous ne le faites pas - et je soupçonne que très peu de gens le font - que vous allez faire beaucoup de partition scans, et au traitement des données vous-même.

Au-delà, Azure Table Storage semble être dans une impasse en termes de développement. Si vous regardez la "prise en charge des Index Secondaires" demande sur l'Azur commentaires des forums (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), vous pouvez voir que le soutien de l'Index Secondaires a été promis dès 2011, mais aucun progrès n'a été fait. Ni a une quelconque des progrès accomplis sur les autres supérieure demandes pour le Stockage de Table.

Maintenant, je sais que Scott Guthrie est un mec, donc mon espoir est que toute cette stagnation sur la Table de Stockage à l'avant est une préface à Azure de fixation et de venir avec quelque chose de vraiment cool. C'est mon espoir (même si je n'ai aucune preuve que c'est le cas). Mais pour l'instant, sauf si vous n'avez pas le choix, je recommanderais fortement contre Azure Table Storage. Utilisez Azure SQL; utiliser votre propre instance de MongoDB ou certains autres No-SQL DB; ou utiliser Amazon DynamoDB. Mais ne pas utiliser Azure Table Storage.