Exporter (0) Imprimer
Développer tout

Stockage de table Azure et base de données SQL Windows Azure - comparaison et différences

Mis à jour: octobre 2014

Auteur : Valery Mizonov et Seth Manheim

Réviseurs : Brad Calder, Jai Haridas, Paolo Salvatori, Silvano Coriani, Prem Mehra, Rick Negrin, Stuart Ozer, Michael Thomassy, Ewan Fairweather

Cette rubrique compare deux types de stockages structurés pris en charge par  : le stockage de tables et base de données SQL Microsoft Azure, ce dernier était auparavant nommé « SQL Azure ». L'objectif de cet article est de fournir une comparaison des technologies respectives pour pouvoir comprendre les ressemblances et les différences existantes entre elles. Cette analyse peut vous aider à prendre une décision en toute connaissance de cause concernant la technologie la plus adaptée à vos besoins.

Lors de l'examen des options de stockage des données et de persistance, fournit deux technologies informatiques : base de données SQL Microsoft Azure et le stockage de tables .

base de données SQL Microsoft Azure est un service de base de données relationnelle qui étend les principales fonctionnalités SQL Server au cloud. Grâce à base de données SQL Azure, vous pouvez mettre en service et déployer des solutions de base de données relationnelle dans le cloud. Les avantages incluent l'infrastructure managée, la haute disponibilité, l'évolutivité, un modèle de développement familier et les infrastructures et outils d'accès aux données qui sont semblables à ceux disponibles dans l'environnement SQL Server traditionnel. base de données SQL Azure offre des fonctionnalités qui permettent la migration, l'exportation, ainsi que la synchronisation continue des bases de données SQL Server sur site avec les bases de données SQL Azure (via Synchronisation des données SQL).

Le stockage de table est un magasin de valeurs clés NoSQL certifié ISO 27001 à tolérance de panne. Le stockage de table s'avère utile pour les applications qui doivent stocker de grandes quantités de données non relationnelles, et nécessitent une structure supplémentaire pour ces données. Les tables offrent l'accès basé sur une clé aux données non schématisées et ce, à un coût bas pour les applications disposant de modèles d'accès aux données simplifiés. Bien que le stockage de table stocke des données structurées sans schémas, il ne fournit aucune méthode pour représenter les relations entre les données.

Malgré des différences notables, base de données SQL Microsoft Azure et le stockage de table sont tous les deux des services managés hautement disponibles avec un contrat de niveau de service mensuel de 99,9 %.

Similaire à base de données SQL Azure, le stockage de table stocke des données structurées. La principale différence entre base de données SQL Azure et le stockage de table réside dans le fait que base de données SQL Azure est un système de gestion de base de données relationnelle basé sur le moteur SQL Server et établi sur les principes et pratiques relationnels standards. Ainsi, il fournit des fonctions de gestion des données relationnelles via des requêtes Transact-SQL, des transactions ACID et des procédures stockées exécutées du côté serveur.

Le stockage de table est un magasin de clés/valeurs flexible qui vous permet de générer facilement des applications dans le cloud, sans avoir à verrouiller le modèle de données d'application dans un jeu de schémas spécifique. Il ne s'agit pas d'une banque de données relationnelle et il ne fournit pas les mêmes fonctions de gestion des données relationnelles que base de données SQL Azure (telles que les jointures et les procédures stockées). Le stockage de table fournit une prise en charge limitée des requêtes côté serveur, mais offre des fonctions transactionnelles. En outre, les différentes lignes d'une même table peuvent avoir des structures différentes dans le stockage de table . Cette propriété sans schéma des tables vous permet également de stocker et d'extraire efficacement des données relationnelles simples.

Si votre application stocke et récupère des jeux de données volumineux qui ne nécessitent pas de riches fonctions relationnelles, le stockage de table peut être un meilleur choix. Si votre application nécessite le traitement des données sur des jeux de données schématisées et est relationnelle par nature, base de données SQL Azure peut être plus adapté à vos besoins. Il existe plusieurs autres facteurs à prendre en considération avant de choisir entre base de données SQL Azure et le stockage de table . Certaines de ces considérations sont répertoriées dans la section suivante.

Lorsqu'ils déterminent la technologie de stockage des données adaptée à une solution donnée, les architectes et les développeurs de la solution doivent prendre en compte les recommandations suivantes.

En tant qu'architecte/développeur de solutions, vous pouvez utiliser le stockage de table dans les cas suivants :

  • Votre application doit stocker de grands volumes de données (exprimés en plusieurs téraoctets) tout en conservant de faibles coûts.

  • Votre application stocke et récupère de grands jeux de données et n'a pas de relations complexes qui requièrent des jointures côté serveur, des index secondaires ou une logique complexe côté serveur.

  • Votre application nécessite un schéma de données flexible pour stocker des objets NUMA (non-uniform memory access), et sa structure peut ne pas être connue au moment de la conception.

  • Votre entreprise nécessite des fonctionnalités de récupération d'urgence entre les différents emplacements géographiques pour répondre à certains besoins de conformité. Les tables sont répliquées géographiquement entre deux centres de données situés à des centaines de kilomètres l'un de l'autre sur le même continent. La réplication offre une durabilité des données supplémentaire dans le cas d'un sinistre important.

  • Vous devez stocker plus de 150 Go de données sans avoir à implémenter la logique de partitionnement.

  • Vous devez obtenir un niveau élevé d'échelle sans avoir à partitionner manuellement votre dataset.

En tant qu'architecte/développeur de solutions, vous devez envisager d'utiliser base de données SQL Microsoft Azure dans les conditions suivantes :

  • Votre application nécessite le traitement des données sur des jeux de données très structurés et schématiques avec des relations.

  • Vos données sont relationnelles par nature et nécessitent les principes clés du modèle de programmation de données relationnelles pour appliquer l'intégrité à l'aide de règles d'unicité des données, de contraintes référentielles et de clés primaires ou étrangères.

  • Les volumes de données ne peuvent pas dépasser 150 Go par unité de jeux de données colocalisés, ce qui se traduit souvent en une seule base de données. Toutefois, vous pouvez partitionner vos données dans plusieurs jeux pour aller au delà de la limite indiquée. Notez que cette limite pourra faire l'objet de modifications.

  • Votre application existante centrée sur les données utilise déjà SQL Server et vous avez besoin d'un accès informatique aux données structurées en utilisant les infrastructures d'accès aux données existantes. En même temps, votre application nécessite la portabilité transparente entre le site et .

  • Votre application prévoit de tirer parti des procédures stockées T-SQL pour effectuer des calculs dans la couche Données, ce qui réduit les boucles entre l'application et le stockage des données.

  • Votre application nécessite la prise en charge des données spatiales, des types de données enrichis et des modèles élaborés d'accès aux données par le biais de la sémantique cohérente de requête qui inclut les jointures, l'agrégation et les prédicats complexes.

  • Votre application doit fournir des rapports de visualisation et de Business Intelligence (BI) sur les modèles de données à l'aide des outils de création de rapports prêts à l'emploi.

noteRemarque
De nombreuses applications peuvent tirer parti des deux technologies. Par conséquent, il est recommandé d'envisager d'utiliser une combinaison de ces options.

Les tables dans les sections suivantes fournissent un regroupement logique des fonctionnalités et vous permettent de comparer, d'un seul coup d'œil, les fonctions disponibles dans le stockage de table et dans base de données SQL Microsoft Azure.

Cette rubrique compare certaines des fonctions de stockage de base fournies par le stockage de table et par base de données SQL Azure.

 

Critères de comparaison Stockage de table base de données SQL Azure

Relations des données

Non

Le stockage de table ne permet pas de représenter les relations entre les données. Vous pouvez obtenir des relations simples à l'aide des propriétés sans schéma des tables et structurer les données au format requis.

Oui

Comme dans SQL Server, base de données SQL Azure permet de définir des relations entre les données stockées dans différentes tables à l'aide de clés étrangères.

Traitement côté serveur

Non

Prend en charge les opérations de base, telles que insert, update, delete et select, mais ne prend pas en charge les jointures, les clés étrangères, les procédures stockées, les déclencheurs ou autres traitements du côté moteur de stockage.

Oui

Fournit des fonctionnalités SQL Server standards, telles que les procédures stockées, les vues, plusieurs index, les jointures et l'agrégation.

Prise en charge des transactions

Limité

Prend en charge les transactions pour les entités de la même table et de la même partition. Au plus 100 opérations sont prises en charge dans une transaction. Prend en charge l'accès concurrentiel optimiste. Pour plus d'informations, consultez Transactions de groupe d'entités.

Oui

Prend en charge les transactions ACID courantes dans la même base de données. Les transactions ne sont pas prises en charge entre les bases de données. La base de données SQL Azure prend aussi en charge l'accès concurrentiel optimiste.

Réplication géographique

Oui

Par défaut, une table est répliquée vers d'autres régions. Cette réplication fournit un niveau élevé de fonctionnalités de récupération d'urgence.

Non

À la date de rédaction de ce document, une instance base de données SQL Azure n'est pas répliquée vers d'autres régions. Ce comportement peut changer.

Schéma de table

Souple

Chaque entité (lignes) peut posséder des propriétés différentes. Par exemple, dans la même table vous pouvez stocker des informations de commande dans une ligne et des informations sur le client dans une autre ligne.

Géré

Schéma fixe pour la totalité de la table défini une seule fois, mais il peut être modifié à tout moment. Toutes les lignes doivent respecter les règles incluses dans le schéma. Envisagez d'utiliser le type XML ou les colonnes éparses pour plus de souplesse.

Similarité avec les magasins de données existants utilisés sur site

Non

Stockage informatique sans solution sur site pour le moment.

Oui

Semblable à SQL Server avec certaines limites. Pour plus d'informations, consultez Instructions générales et limitations.

Montée en puissance parallèle

Automatique

Partitionnement selon la propriété PartitionKey. Une table peut être stockée dans différentes partitions sur des périphériques de stockage différents. Cette structure permet aux clients d'accéder aux données en parallèle.

Manuel

Partitionnement dans un groupe d'instances de bases de données managées à l'aide des fédérations SQL ou d'une méthode de partitionnement personnalisé.

Types de données

Simple

Pour plus d'informations sur les types de données pris en charge, voir la table dans la section « Informations supplémentaires ».

Simple, complexe et défini par l'utilisateur

base de données SQL Azure prend en charge un ensemble complet de types de données, y compris les types définis par l'utilisateur personnalisés.

  • Lorsque vous créez une table , vous n'avez pas à définir les colonnes. La table n'est pas structurée et n'a pas de schéma de conception. Les noms de colonnes font partie des entités (lignes) qui sont stockées dans la table, et peuvent être différents pour les différentes entités d'une table. Une table peut même être composée de deux entités avec le même nom de propriété, mais différents types pour la valeur de la propriété. Toutefois, les noms des propriétés doivent être uniques au sein d'une entité.

  • Le stockage de table ne prend pas en charge les fonctionnalités relationnelles, telles que les jointures et les agrégations dans les requêtes ou transactions pour coordonner des modifications sur plusieurs tables. Les entités qui sont stockées dans des tables avec la même clé de partition sont servies ensemble dans le magasin. Vous pouvez extraire ces entités efficacement et les modifier dans une requête unique à l'aide de transactions de groupe d'entités.

  • Il existe des limitations à connaître lorsque vous utilisez des transactions de groupe d'entités. Ces restrictions incluent une taille de lot maximale de 4 Mo et toutes les entités du lot doivent partager la même valeur de clé de partition. Pour plus d'informations, consultez cet article.

  • Le type de stockage de table fournit un index cluster et les résultats sont toujours triés par PartitionKey et RowKey, dans l'ordre croissant. Les valeurs PartitionKey et RowKey identifient de manière unique une ligne dans une table. Si vous essayez de créer deux lignes avec le même PartitionKey et RowKey, une exception est générée.

  • Cet article fournit un arbre de décision pour le choix entre base de données SQL Azure et SQL Server sur site. Vous pouvez également appliquer ces critères de décision à base de données SQL Azure et au stockage de table .

  • Les critères de débit appliqués aux deux technologies sont une équation complexe à plusieurs variables. Ces facteurs incluent les types de requêtes et leur complexité, les modèles d'accès aux données, la taille des jeux de résultats, la proximité de l'infrastructure de stockage et les latences réseau. Il est toujours recommandé de réaliser vos propres tests de performance pour mesurer de manière fiable les indicateurs appropriés tout en prenant en compte les détails d'une classe spécifique d'applications. Pour plus d'informations sur les meilleures pratiques pour les tables Azure, voir ce billet de blog.

  • Le tableau suivant répertorie les types de données pris en charge pour les valeurs dans les tables . Pour obtenir la liste complète des types de données pris en charge par base de données SQL Azure, voir Data Types (Azure SQL Database).

     

    Type de propriété Détails

    Binary

    Tableau d'octets d'une taille maximale de 64 Ko.

    Bool

    Valeur booléenne.

    DateTime

    Une valeur 64 bits exprimée en heure UTC. La plage de valeurs prises en charge est comprise entre 1/1/1601 et 31/12/9999.

    Double

    Valeur en virgule flottante 64 bits.

    GUID

    Identificateur global unique (GUID) 128 bits.

    Int

    Entier 32 bits.

    Int64

    Entier 64 bits.

    Chaîne

    Valeur encodée UTF-16. Les valeurs de chaîne peuvent avoir une taille maximale de 64 Ko.

Cette rubrique compare les fonctionnalités avancées fournies par le stockage de table et base de données SQL Azure.

 

Critères de comparaison Stockage de table base de données SQL Azure

Accessible par les applications sur site ou par les applications hébergées dans des plateformes autres que

Oui

Oui

Modèle de cohérence

Fort

Fort

Prise en charge du client des services de données Windows Communication Foundation (WCF)

Oui

Oui

Prise en charge du client REST

Oui

Prend en charge l'accès REST prêt à l'emploi.

Oui

Prend en charge l'accès REST en ajoutant une couche OData sur une base de données SQL.

Protection par pare-feu (accès à une plage d'adresses IP restreintes)

Non

Oui

Utilise le Pare-feu Azure qui est configurable sur le portail, ou à l'aide des outils en ligne de commande.

Comportement de limitation des transactions

Oui

Pour plus d'informations, consultez cette publication de blog.

Oui

Pour plus d'informations, consultez cet article.

Tolérance de panne

Oui

Pour fournir un niveau élevé de tolérance aux pannes, les données stockées sont répliquées trois fois dans la région, et sont répliquées 3 fois supplémentaires dans une autre région située à plus de 644 kilomètres.

Oui

Trois copies d'une instance base de données SQL Azure sont conservées dans le centre de données choisi.

Enregistrement et mesures

Oui

Pour plus d'informations, consultez ce billet de blog.

Non

Journaux des transactions

Non

Oui

La taille du journal des transactions est limitée à 10 Go avec une limite de 1 Go dans une seule transaction.

  • Vous pouvez limiter l'accès à une instance base de données SQL Azure au niveau du réseau à l'aide de la fonctionnalité de pare-feu intégrée. En outre, vous pouvez configurer les règles d'accès au pare-feu sur le portail . En revanche, tout client qui peut se connecter via HTTP/HTTPS à un point de terminaison de compte de stockage peut obtenir l'accès aux tables .

  • Le stockage de table fournit des garanties de transaction ACID pour toutes les transactions d'insertion/mise à jour/suppression d'une seule entité dans une table et pour les transactions de groupe d'entités. L'isolement d'instantané est fourni pour chaque requête d'interrogation du service. Une requête conserve une vue cohérente de la partition à partir du début de la requête et pendant toute la transaction. Les développeurs d'applications sont tenus d'assurer la cohérence entre les tables.

  • Les tables prennent en charge la journalisation, ce qui vous permet de voir chaque demande qui est effectuée sur le service. La journalisation fournit également des mesures agrégées des requêtes par rapport au service.

  • base de données SQL Microsoft Azure n'offre pas la journalisation et les mesures ; mais il fournit un sous-ensemble de vues de gestion dynamique (DMV) pour diagnostiquer les problèmes de performances des requêtes, vérifier les connexions de base de données, consulter les transactions actives et inspecter les plans de requête.

  • Comme base de données SQL Microsoft Azure repose sur le moteur SQL Server, certains concepts, tels que TempDB et les journaux des transactions, sont toujours appropriés. Pour empêcher les fichiers du journal des transactions de croître de manière inattendue, base de données SQL Azure limite la taille du journal à 10 Go. L'infrastructure base de données SQL Azure gère ces journaux de transactions, auxquels vous ne pouvez pas accéder directement. Le stockage de table ne possède pas d'équivalent dans le journal des transactions. Les fonctionnalités de journalisation et de mesure prises en charge par le stockage de table sont différentes de l'enregistrement des transactions, car il suit les requêtes dans le service, et non pas les données réelles modifiées.

  • Pour éviter l'utilisation excessive des ressources dans un environnement à plusieurs locataires, le stockage de table et base de données SQL Azure utilisent un mécanisme qui contrôle les seuils du système. Ce mécanisme est appelé limitation, et son comportement varie entre les deux services. Par exemple, base de données SQL Azure utilise deux stratégies de limitation : la limitation logicielle et la limitation matérielle. Ces mécanismes de limitation sont décrits en détail dans cet article.

Cette rubrique compare le stockage de table et base de données SQL Azure du point de vue de la capacité et des quotas qui peuvent s'appliquer. Notez que les capacités et quotas affichés ici sont susceptibles d'être modifiés ultérieurement.

 

Critères de comparaison Stockage de table base de données SQL Azure

Taille maximale de ligne

1 Mo

Au plus 255 propriétés, y compris trois propriétés obligatoires : PartitionKey, RowKey, Timestamp.

2 Go

Peut contenir au plus 1 024 colonnes (ou 30 000 si des colonnes éparses sont utilisées). L'utilisation de colonnes de type varchar(max), varbinary(max), xml, text ou image permet jusqu'à 2 Go de stockage hors ligne.

Taille maximale des données

200 To par table

Un seul compte de stockage (contenant des tables, des objets blob et des files d'attente) peut contenir jusqu'à 200 To de données d'objets blob, de files d'attente et de tables s'il a été créé le 8 juin 2012, ou à une date ultérieure ; pour les comptes de stockage créés avant cette date, la capacité totale est de 100 To. Par conséquent, la taille maximale d'une table est de 200 TB.

150 Go par base de données

Lorsque la taille maximale autorisée de base de données peut être augmentée, envisagez d'utiliser les fédérations SQL (ou le partitionnement personnalisé) pour stocker de plus grands jeux de données.

Nombre maximal de lignes récupérées par requête

1,000

Au plus 1 000 lignes (entités) sont retournées en réponse à une seule requête. Si une requête comporte davantage de résultats, un jeton de liaison est retourné pour permettre à la requête de poursuivre avec d'autres demandes.

Illimité

Si le paramétrage n'est pas correct, les délais d'expiration de la connexion et de la requête peuvent limiter le nombre de lignes extraites.

  • Le stockage de table utilise un jeton de liaison dans l'en-tête de réponse pour indiquer qu'il existe des résultats supplémentaires pour une requête. Vous pouvez récupérer ces résultats en exécutant une autre requête qui est paramétrable par le jeton de liaison. Ce scénario vous permet de récupérer des éléments au-delà de la limite de 1 000 entités. La cohérence de l'instantané est conservée pour chaque demande, mais pas entre les demandes de jeton de liaison d'une requête.

  • La taille combinée des champs (propriétés) dans une ligne de table (entité) ne peut pas dépasser 1 Mo. Cette limite comprend la taille des noms de propriétés, ainsi que les valeurs de propriété et leurs types, ce qui inclut les deux propriétés de clé obligatoires (PartitionKey et RowKey).

  • base de données SQL Azure prend actuellement en charge des bases de données de 5 Go (Web Edition) ou de 150 Go (Business Edition). Pour conserver la taille dans le seuil donné, il incombe au développeur de surveiller la base de données. La taille maximale base de données SQL Azure est préconfigurée via une opération de gestion, et n'est pas incrémentée automatiquement lorsque les volumes de données stockées évoluent. Pour plus d'informations, consultez ALTER DATABASE (Azure SQL Database) dans la documentation base de données SQL Azure.

  • Le nombre de colonnes dans une table base de données SQL Azure normale est limité à 1 024 (semblable à SQL Server sur site). Avec les colonnes éparses, une table peut comporter jusqu'à 30 000 colonnes, dont 1 023 non éparses. Toutefois, au moins 28 976 doivent être des colonnes éparses. Une colonne non éparse est utilisée pour le jeu de colonnes qui est obligatoire si le nombre de colonnes est supérieur à 1 024.

Cette rubrique compare les fonctionnalités de gestion fournies par le stockage de table et base de données SQL Azure.

 

Critères de comparaison Stockage de table base de données SQL Azure

Protocole et outils de gestion

REST sur HTTP/HTTPS

Vous pouvez utiliser l'Explorateur de stockage Azure ou un autre outil tiers, tel que Cloud Storage Studio.

ODBC/JDBC

REST sur HTTP/HTTPS

Vous pouvez utiliser le portail de gestion ou SQL Server Management Studio pour gérer une instance base de données SQL Azure.

Accès aux données

Interface du protocole OData

Vous pouvez accéder à des données à l'aide de l'API REST HTTP(S) ou de la bibliothèque cliente .NET pour les services de données WCF qui est incluse dans le Kit de développement (SDK) Azure.

ODBC/JDBC

Vous pouvez utiliser les applications écrites à l'aide de technologies existantes comme ADO.NET et ODBC qui communiquent avec SQL Server pour accéder aux instances base de données SQL Azure avec des modifications minimales du code.

Prise en charge de l'API Java

Oui

Oui

Prise en charge de l'API Node.js

Oui

Oui

Prise en charge de l'API PHP

Oui

Oui

Prise en charge de LINQ

Oui

Oui

Prise en charge de Python

Oui

Non

Expérience hors connexion du développeur

Oui

Fournie par l'émulateur de stockage local inclus dans le Kit de développement logiciel (SDK) .

Non

SQL Express ou d'autres éditions de SQL Server sont des produits distincts et n'offrent pas de simulation complète d'un environnement base de données SQL Microsoft Azure.

  • Bien que base de données SQL Azure puisse être simulé dans une installation locale de SQL Server, cette méthode ne permet pas de répliquer le comportement qui s'applique uniquement au service informatique, tel que la limitation et d'autres limitations applicables.

  • base de données SQL Microsoft Azure offre un environnement de requêtes interactif basé sur le Web. base de données SQL Azure est également accessible depuis des outils de console cliente ad hoc tels que SSMS, ou des outils de requête SGBDR tiers qui prennent en charge ODBC.

  • Les fonctions T-SQL diffèrent entre SQL Server et base de données SQL Azure. Certaines fonctionnalités sont limitées et ne sont pas prises en charge, et d'autres présentent des différences notables (telles que la création de bases de données et les fédérations).

Cette section traite des fonctionnalités d'authentification et d'autorisation prises en charge par le stockage de table et base de données SQL Azure.

 

Critères de comparaison Stockage de table base de données SQL Azure

Authentification

Clé symétrique

Signatures d'accès partagé

La clé HMAC 512 bits est utilisée pour authentifier les utilisateurs.

Authentification SQL

L'authentification SQL standard est utilisée pour authentifier les utilisateurs.

Accès basé sur des rôles

Non

Oui

Prend en charge les rôles de base de données et application SQL standards.

Prise en charge d'Active Directory Azure (anciennement ACS)

Non

Non

Fédération de fournisseur d'identité

Non

Non

  • L'accès basé sur les rôles fourni par base de données SQL Azure offre la souplesse de configuration des modes lecture seule, écriture seule et lecture/écriture. Cette fonction peut fournir un ensemble d'options d'accès aux données, selon les besoins de l'application individuelle.

  • Étant donné que ni l'une ni l'autre des technologies ne prend actuellement en charge l'authentification fédérée basée sur des certificats ou l'authentification Active Directory, vous devez veiller à ce que les informations d'identification de sécurité (par exemple, la clé HMAC ou le nom d'utilisateur et le mot de passe SQL) soient couvertes par les mesures appropriées de protection telles que le chiffrement. Cette protection est particulièrement importante lorsque l'accès à ces informations d'identification est soumis à la conformité informatique.

  • Le stockage de table offre un accès basé sur les URL signé, appelé signature d'accès partagé de table (signature d'accès partagé). La signature d'accès partagé vous permet d'accorder aux clients l'accès basé sur le temps sans afficher la clé secrète du compte de stockage. Pour plus d'informations, voir cette publication de blog.

Cette rubrique compare le stockage de table et base de données SQL Azure du point de vue des coûts. Les coûts affichés ici sont susceptibles d'être modifiés.

 

Critères de comparaison Stockage de table base de données SQL Azure

Coût de stockage

$0.125

par gigaoctet enregistré par mois selon la moyenne quotidienne.

Pour plus d'informations sur la tarification, voir Présentation de la facturation Azure.

Facturé à un taux progressif selon la taille de la base de données.

Pour plus d'informations sur la tarification, voir Présentation de la facturation Azure.

Coût des transactions

$0.01

par 100 000 transactions de stockage.

$0.00

base de données SQL Azure ne facture pas les transactions.

Opérations facturables

Tous

Outre les coûts de stockage, le coût des transactions est calculé selon le volume de transactions sur des tables.

Aucune

Le coût ne dépend pas du volume de transactions, uniquement de la taille de la base de données.

Coûts de sortie

$0.12 - $0.19

par gigaoctet, en fonction d'une échelle progressive spécifique à la région

$0.12 - $0.19

par gigaoctet, en fonction d'une échelle progressive spécifique à la région

  • Le coût de sortie est basé sur la quantité totale de données qui quitte les centres de données via Internet. La quantité est calculée sur une période donnée de facturation lorsqu'une application effectue des requêtes et reçoit les résultats du service de données respectif.

  • Contrairement à base de données SQL Azure, le stockage de table applique un coût par transaction. Ce modèle de facturation signifie que vous devez inclure la fréquence des transactions de stockage dans les considérations relatives aux coûts.

Prendre la décision d'utiliser le stockage de table ou base de données SQL Microsoft Azure dépend de plusieurs facteurs. Ces facteurs peuvent dépendre largement des différents besoins de votre application, de son architecture, ainsi que des charges de travail et des modèles d'accès aux données. Cette section résume certains des éléments clés.

Le stockage de table prend en charge le stockage de grandes quantités de données dans des tables évolutives dans le cloud. Ces tables peuvent stocker des téraoctets de données et des milliards d'entités. Pour atteindre ce niveau d'évolutivité, le stockage de table utilise un modèle avec montée en puissance parallèle pour répartir les entités sur plusieurs nœuds de stockage. Il utilise un modèle de données NoSQL pour prendre en charge une échelle massive à forte cohérence. Si vous avez besoin de la persistance d'une masse de modèles de données non relationnelles ou simplifiés à un coût réduit, envisagez d'utiliser le stockage de table .

Vous pouvez envisager base de données SQL Microsoft Azure comme moteur de base de données SQL Server étendu à la plateforme du cloud, en proposant une expérience de développement SQL Server familière, la sémantique de requête complète, la prise en charge des transactions ACID avec différents niveaux d'isolation, ainsi que des fonctionnalités de traitement des données complexes. Si vos données sont très relationnelles et vous avez besoin de la gestion des données relationnelles couplée à ces fonctions, base de données SQL Azure peut être le meilleur choix.

Notez qu'une décision sur le moment où une technologie particulière doit être utilisée n'est pas toujours binaire, et vous ne pouvez pas toujours être en mesure de choisir une seule technologie. Vous pouvez déterminer si une combinaison équilibrée des deux technologies répond aux besoins de votre solution et envisager de les appliquer dans des zones respectives pour résoudre la classe de problèmes spécifique que vous résolvez.

En ayant une meilleure compréhension des deux technologies, vous pouvez prendre une décision en toute connaissance de cause en ce qui concerne la technologie de stockage des données à utiliser sur et à quel moment.

Voir aussi

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft