Esporta (0) Stampa
Espandi tutto
Questo argomento non è stato ancora valutato - Valuta questo argomento

Archiviazione tabelle di Windows Azure e database SQL di Windows Azure: Confronto e contrapposizioni

Aggiornamento: gennaio 2014

Autori: Valery Mizonov e Seth Manheim

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

In questo argomento vengono confrontati due tipi di archiviazione strutturata supportati da Windows Azure: l'archiviazione tabelle di Windows Azure e il database SQL di Windows Azure, quest'ultimo precedentemente noto come "SQL Azure". L'obiettivo di questo articolo è fornire un confronto delle rispettive tecnologie in modo da poter comprendere le relative analogie e differenze. Grazie a questa analisi è possibile prendere una decisione più oculata in merito alla tecnologia che meglio soddisfa le proprie esigenze.

Introduzione

Per le opzioni di persistenza e archiviazione dati, Windows Azure offre due possibili tecnologie basate su cloud: il database SQL di Windows Azure e l'archiviazione tabelle di Windows Azure.

Il database SQL di Windows Azure è un servizio del database relazionale tramite cui vengono estese al cloud le funzionalità principali di SQL Server. Utilizzando Database SQL è possibile eseguire il provisioning delle soluzioni del database relazionale e distribuirle nel cloud. Tra i vantaggi, analoghi a quelli disponibili nell'ambiente SQL Server tradizionale, sono inclusi: infrastruttura gestita, disponibilità elevata, scalabilità, modello di sviluppo comune e strumenti e framework di accesso ai dati. Inoltre, in Database SQL vengono fornite funzionalità per la migrazione, l'esportazione e la sincronizzazione continua di database di SQL Server locali con i database SQL di Windows Azure (tramite la sincronizzazione dati SQL).

L'archiviazione tabelle di Windows Azure è un archivio chiave-valore NoSQL certificato ISO 27001 a tolleranza di errore. L'archiviazione tabelle di Windows Azure può essere utile per applicazioni tramite cui devono essere archiviate grandi quantità di dati non relazionali e per le quali è necessaria una struttura aggiuntiva per i dati in questione. Tramite le tabelle viene fornito l'accesso basato su chiave a dati non schematizzati a un costo contenuto per applicazioni con modelli di accesso ai dati semplificati. Anche se tramite l'archiviazione tabelle di Windows Azure vengono archiviati dati strutturati senza schemi, non è tuttavia possibile rappresentare le relazioni tra i dati.

Nonostante alcune differenze sostanziali, il database SQL di Windows Azure e l'archiviazione tabelle di Windows Azure sono entrambi servizi gestiti estremamente disponibili con un contratto di servizio mensile del 99,9%.

Confronto tra l'archiviazione tabelle e il database SQL

Analogamente a Database SQL, tramite l'archiviazione tabelle di Windows Azure vengono archiviati i dati strutturati. La differenza principale tra Database SQL e l'archiviazione tabelle di Windows Azure è che Database SQL è un sistema di gestione di database relazionali basato sul motore di SQL Server e compilato su procedure e principi relazionali standard. Pertanto, offre funzionalità di gestione dei dati relazionali tramite query Transact-SQL, transazioni ACID e stored procedure eseguite sul lato server.

L'archiviazione tabelle di Windows Azure è un archivio chiave-valore flessibile tramite cui è possibile compilare facilmente applicazioni cloud, senza dover bloccare il modello dati dell'applicazione in un set particolare di schemi. Non è un archivio dati relazionali, né offre le stesse funzioni di gestione dei dati relazionali di Database SQL, quali join e stored procedure. L'archiviazione tabelle di Windows Azure fornisce supporto limitato per le query sul lato server ma, nel contempo, offre funzionalità di transazione. Inoltre, righe diverse all'interno della stessa tabella possono presentare strutture diverse nell'archiviazione tabelle di Windows Azure. Grazie a questa proprietà senza schema delle tabelle di Windows Azure è inoltre possibile archiviare e recuperare in modo efficiente dati relazionali semplici.

Se tramite l'applicazione in uso vengono archiviati e recuperati grandi set di dati per i quali non sono necessarie funzionalità relazionali avanzate, probabilmente l'archiviazione tabelle di Windows Azure è la scelta migliore. Se per l'applicazione è necessaria l'elaborazione dati su set di dati schematizzati e l'applicazione in questione è relazionale, è possibile che Database SQL rappresenti la soluzione che meglio soddisfa le proprie esigenze. Vi sono molti altri fattori da considerare prima di scegliere tra Database SQL e l'archiviazione tabelle di Windows Azure. Alcune di queste considerazioni sono elencate nella sezione successiva.

Considerazioni sulla selezione della tecnologia

Quando si stabilisce la tecnologia di archiviazione dei dati che soddisfa lo scopo di una determinata soluzione, è consigliabile che gli architetti e gli sviluppatori di soluzioni tengano in considerazione le indicazioni riportate di seguito.

In qualità di architetto o sviluppatore di soluzioni, si consideri l'utilizzo dell'archiviazione tabelle di Windows Azure quando:

  • Tramite l'applicazione in uso devono essere archiviati volumi di dati significativamente grandi, espressi in più terabyte, mantenendo comunque contenuti i costi.

  • Tramite l'applicazione in uso vengono archiviati e recuperati grandi set di dati privi di relazioni complesse per le quali sono richiesti join sul lato server, indici secondari o logica complessa sul lato server.

  • Per l'applicazione in uso è necessario uno schema dati flessibile per l'archiviazione di oggetti non uniformi la cui struttura non è nota in fase di progettazione.

  • L'azienda richiede funzionalità di ripristino di emergenza in aree geografiche al fine di soddisfare determinate esigenze di conformità. Le tabelle di Windows Azure vengono replicate geograficamente tra due data center distanti centinaia di chilometri nello stesso continente. Questa replica offre durabilità aggiuntiva dei dati in caso di emergenza.

  • È necessario archiviare più di 150 GB di dati senza dover implementare la logica di partizionamento o partizionamento orizzontale.

  • È necessario ottenere un livello elevato di scalabilità senza dover eseguire manualmente il partizionamento orizzontale del set di dati in uso.

In qualità di architetto o sviluppatore di soluzioni, si consideri l'utilizzo del database SQL di Windows Azure quando:

  • Per l'applicazione in uso è necessaria l'elaborazione dati su set di dati schematici, altamente strutturati con relazioni.

  • I dati sono relazionali e per essi sono richiesti i principi fondamentali del modello di programmazione dei dati relazionali per applicare l'integrità utilizzando regole di univocità dei dati, vincoli referenziali e chiavi primarie o esterne.

  • È possibile che i volumi di dati non superino i 150 GB per singola unità di set di dati posizionati insieme, che spesso si traduce in un singolo database. Tuttavia, è possibile partizionare i dati in più set per superare il limite dichiarato. Si noti che questo limite è soggetto a modifiche in futuro.

  • Nell'applicazione esistente incentrata sui dati viene già utilizzato SQL Server ed è necessario l'accesso basato su cloud ai dati strutturati tramite framework di accesso ai dati esistenti. Contemporaneamente, per l'applicazione è necessaria una portabilità continua tra le istanze locali e Windows Azure.

  • Nell'applicazione in uso si prevede l'utilizzo di stored procedure T-SQL per eseguire calcoli nel livello dati, riducendo in questo modo i round trip tra l'applicazione e l'archivio dati.

  • Per l'applicazione è richiesto il supporto per dati spaziali, tipi di dati dettagliati e modelli di accesso ai dati sofisticati tramite la semantica di query coerente in cui sono inclusi join, aggregazioni e predicati complessi.

  • Tramite l'applicazione devono essere forniti report di visualizzazione e per Business Intelligence (BI) su modelli dati utilizzando strumenti di report predefiniti.

noteNota
In molte applicazioni Windows Azure sono disponibili entrambe le tecnologie. Pertanto, si consiglia di considerare l'utilizzo di una combinazione di queste opzioni.

Confronto tra archiviazione tabelle di Windows Azure e Database SQL

Nelle tabelle delle sezioni riportate di seguito viene fornito un raggruppamento logico delle funzionalità e la possibilità di un confronto immediato delle funzionalità disponibili sia in archiviazione tabelle di Windows Azure sia nel database SQL di Windows Azure.

Funzionalità fondamentali

In questa sezione vengono confrontate alcune delle funzionalità di archiviazione fondamentali fornite dall'archiviazione tabelle di Windows Azure e da Database SQL.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Relazioni tra i dati

No

L'archiviazione tabelle di Windows Azure non offre una modalità per rappresentare le relazioni tra i dati. È possibile ottenere relazioni semplici utilizzando le proprietà senza schema di tabelle e strutturando i dati nel formato richiesto.

Analogamente a SQL Server, tramite Database SQL è possibile definire relazioni tra i dati archiviati in tabelle diverse tramite chiavi esterne.

Elaborazione sul lato server

No

Supporta operazioni di base quali insert, update, delete e select, ma non supporta join, chiavi esterne, stored procedure, trigger né elaborazioni sul lato del motore di archiviazione.

Fornisce le funzionalità standard di SQL Server quali stored procedure, viste, più indici, join e aggregazioni.

Supporto per le transazioni

Limitato

Supporta transazioni per entità nella stessa tabella e nella stessa partizione. Sono supportate fino a 100 operazioni in una transazione. Supporta la concorrenza ottimistica. Per ulteriori informazioni, vedere la pagina relativa alle transazioni del gruppo di entità.

Supporta transazioni ACID tipiche all'interno dello stesso database. Le transazioni non sono supportate nei database. Database SQL supporta inoltre la concorrenza ottimistica.

Replica geografica

Per impostazione predefinita, una tabella viene replicata in altre aree secondarie. Questa replica fornisce un livello elevato di funzionalità di ripristino di emergenza.

No

Al momento della stesura di questo documento, un'istanza di Database SQL non viene replicata in altre aree secondarie. Questo comportamento potrebbe essere modificato in futuro.

Schema della tabella

Libero

Ogni entità (riga) può disporre di proprietà diverse. Ad esempio, nella stessa tabella è possibile archiviare informazioni sull'ordine in una riga e informazioni sul cliente in un'altra riga.

Gestito

Schema fisso per l'intera tabella una volta definito ma modificabile in qualsiasi momento. A tutte le righe devono essere applicate le regole dello schema. Si consideri l'utilizzo delle colonne di tipo sparse o il tipo XML per una flessibilità aggiuntiva.

Somiglianza agli archivi dati esistenti utilizzati in locale

No

Archiviazione basata su cloud attualmente senza alternative locali.

Simile a SQL Server con delle limitazioni. Per ulteriori informazioni, vedere Linee guida e limitazioni generali.

Scalabilità orizzontale

Automatica

Partizionata in base alla proprietà PartitionKey. Una tabella può essere archiviata in partizioni diverse in dispositivi di archiviazione differenti. Tramite questa struttura i client possono accedere ai dati in parallelo.

Manuale

Partizionata orizzontalmente in un gruppo gestito di istanze di database tramite federazioni SQL o un approccio personalizzato del partizionamento orizzontale.

Tipi di dati

Semplice

Per ulteriori informazioni su tipi di dati supportati, vedere la tabella nella sezione "Informazioni aggiuntive".

Semplice, complesso e definito dall'utente

Database SQL supporta un set di tipi di dati avanzato, tra cui i tipi personalizzati definiti dall'utente.

Informazioni aggiuntive

  • Quando si crea una tabella di Windows Azure, non è necessario definire alcuna colonna. La tabella stessa non è strutturata e non dispone di uno schema in fase di progettazione. I nomi delle colonne fanno parte delle entità (righe) archiviate nella tabella e possono essere differenti per entità diverse all'interno di una singola tabella. In una tabella Windows Azure possono anche essere incluse due entità con lo stesso nome di proprietà, ma tipi diversi per il valore della proprietà. Tuttavia, i nomi di proprietà devono essere univoci in una singola entità.

  • L'archiviazione tabelle di Windows Azure non supporta funzionalità relazionali, ad esempio join e aggregazioni in query o transazioni per coordinare le modifiche tra più tabelle. Le entità archiviate nelle tabelle di Windows Azure con la stessa chiave di partizione vengono eseguite insieme nell'archivio. È possibile recuperare queste entità in modo efficiente e modificarle in una singola richiesta utilizzando le transazioni del gruppo di entità.

  • Vi sono alcune limitazioni da considerare quando si utilizzano le transazioni del gruppo di entità Tra queste limitazioni sono incluse dimensioni di batch massime di 4 MB e la necessità di condivisione dello stesso valore della chiave di partizione da parte di tutte le entità nel batch. Per ulteriori informazioni, vedere questo articolo.

  • Il tipo di archiviazione tabelle di Windows Azure fornisce un indice cluster. Inoltre, i risultati sono ordinati sempre in base ai valori PartitionKey e RowKey, in ordine crescente. Tramite i valori PartitionKey e RowKey è possibile identificare in modo univoco una riga in una tabella. Se si tenta di creare due righe con gli stessi valori PartitionKey e RowKey, viene generata un'eccezione.

  • In questo articolo viene fornito un albero delle decisioni per scegliere tra Database SQL e SQL Server locale. Inoltre, è possibile applicare questi criteri decisionali a Database SQL e all'archiviazione tabelle di Windows Azure.

  • I criteri di velocità effettiva applicati a entrambe le tecnologie sono un'equazione complessa con molte variabili. Tra questi fattori sono inclusi i tipi di query e la relativa complessità, i modelli di accesso ai dati, le dimensioni dei set di risultati, la prossimità all'infrastruttura di archiviazione e le latenze di rete. È sempre consigliabile eseguire test di prestazioni personalizzati per misurare meglio e in modo più affidabile i relativi indicatori tenendo conto di singole specifiche di una determinata classe di applicazioni. Per ulteriori informazioni su procedure consigliate per le tabelle di Windows Azure, vedere questo post di blog.

  • Nella tabella seguente sono elencati i tipi di dati supportati per i valori delle proprietà nelle tabelle di Windows Azure. Per un elenco dei tipi di dati supportati da Database SQL, vedere Data Types (Windows Azure SQL Database).

     

    Tipo di proprietà Dettagli

    Binary

    Matrice di byte di dimensioni massime pari a 64 KB.

    Bool

    Valore booleano.

    DateTime

    Valore a 64 bit espresso come ora UTC. L'intervallo di valori supportato è compreso tra 1/1/1601 e 31/12/9999.

    Double

    Valore a virgola mobile a 64 bit.

    GUID

    Identificatore univoco globale a 128 bit.

    Int

    Integer a 32 bit.

    Int64

    Integer a 64 bit.

    String

    Valore con codifica UTF-16. Le dimensioni massime dei valori stringa possono essere pari a 64 KB.

Funzionalità avanzate

In questa sezione vengono confrontate le funzionalità avanzate fornite dall'archiviazione tabelle di Windows Azure e da Database SQL.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Accesso possibile da applicazioni locali o applicazioni ospitate in piattaforme non Windows Azure

Modello di coerenza

Complesso

Complesso

Supporto client per Windows Communication Foundation (WCF) Data Services

Supporto client REST

Supporta l'acceso basato su REST predefinito.

Supporta l'accesso basato su REST aggiungendo un livello OData in un database SQL.

Protezione firewall (accesso intervallo IP limitato)

No

Viene utilizzato il firewall di Windows Azure configurabile dal portale o tramite gli strumenti della riga di comando.

Comportamento della limitazione delle transizioni

Per ulteriori informazioni, vedere questo post di blog.

Per ulteriori informazioni, vedere questo articolo.

Tolleranza di errore

Per fornire un livello elevato di tolleranza di errore, i dati archiviati vengono replicati tre volte in aree secondarie e replicati per altre 3 volte in un'altra area secondaria a più di 644 chilometri di distanza.

Nel data center scelto vengono mantenute tre copie di un'istanza di Database SQL.

Registrazione e metrica

Per ulteriori informazioni, vedere questo post di blog.

No

Log delle transazioni

No

Le dimensioni del log delle transazioni vengono limitate a 10 GB con un limite di 1 GB in una singola transazione.

Informazioni aggiuntive

  • È possibile limitare l'accesso a un'istanza di Database SQL a livello di rete tramite la funzionalità predefinita del firewall. Inoltre, è possibile configurare le regole di accesso del firewall tramite il portale Windows Azure. Per i client mediante i quali è possibile connettersi tramite HTTP/HTTPS a un endpoint dell'account di archiviazione di Windows Azure è invece possibile ottenere l'accesso alle tabelle di Windows Azure.

  • Tramite l'archiviazione tabelle di Windows Azure vengono garantite transazioni ACID per tutte le transazioni di inserimento, aggiornamento ed eliminazione per una singola entità in una tabella e per le transazioni del gruppo di entità. L'isolamento snapshot viene fornito per ogni singola richiesta di query al servizio. Tramite una query viene mantenuta una vista coerente della partizione dall'ora di inizio della query e per tutta la transazione. Gli sviluppatori di applicazioni sono responsabili della gestione della coerenza tra più tabelle.

  • Le tabelle di Windows Azure supportano la registrazione, consentendo la visualizzazione di tutte le richieste eseguite nel servizio. Inoltre, la registrazione fornisce la metrica di aggregazione delle richieste nel servizio.

  • Il database SQL di Windows Azure non offre attualmente la registrazione e la metrica. Tuttavia, dispone di un subset di DMV per la diagnosi di problemi di prestazioni di query, il monitoraggio delle connessioni al database, la visualizzazione delle transazioni attive e il controllo dei piani di query.

  • Dal momento che il database SQL di Windows Azure viene compilato nel motore di SQL Server, alcuni concetti, ad esempio i log TempDB e delle transazioni, sono ancora pertinenti. Per impedire un aumento imprevisto delle dimensioni dei file di log delle transazioni, tramite Database SQL viene imposto un limite di 10 GB alle dimensioni del log. Questi log delle transazioni, a cui non è possibile accedere direttamente, vengono gestiti dall'infrastruttura di Database SQL. Nell'archiviazione tabelle di Windows Azure non è disponibile alcun elemento equivalente al log delle transazioni. Le funzionalità di registrazione e metrica supportate dall'archiviazione tabelle di Windows Azure differiscono dalla registrazione delle transazioni, dal momento che tramite questa funzionalità è possibile tenere traccia delle richieste al servizio e non dei dati effettivi modificati.

  • Per impedire l'utilizzo eccessivo di risorse in un ambiente multi-tenant, nell'archiviazione tabelle di Windows Azure e in Database SQL viene utilizzato un meccanismo mediante il quale vengono controllati i valori di soglia del sistema. Questo meccanismo è noto come limitazione e il relativo comportamento varia tra i due servizi. Ad esempio, in Database SQL vengono utilizzate due strategie di limitazione: limitazione software e limitazione hardware. Questi meccanismi di limitazione sono illustrati in dettaglio in questo articolo.

Capacità e quote

In questa sezione vengono confrontati l'archiviazione tabelle di Windows Azure e Database SQL relativamente alla capacità e alle quote applicabili. Si noti che tutte le capacità e le quote illustrate in questa sezione sono soggette a modifiche in futuro.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Dimensioni massime righe

1 MB

Con non più di 255 proprietà, tra cui tre proprietà obbligatorie: PartitionKey, RowKey, Timestamp.

2 GB

Possibilità di inserimento di un massimo di 1024 colonne (o 30.000 in caso di utilizzo di colonne di tipo sparse). L'utilizzo delle colonne varchar(max), varbinary(max), xml, text o image offre fino 2 GB di archiviazione all'esterno di righe.

Dimensioni massime dati

100 TB per tabella

Tramite un singolo account di archiviazione (contenente tabelle, BLOB e code) è possibile archiviare fino a 100 TB di dati. Pertanto, le dimensioni massime di una tabella di Windows Azure sono di 100 TB.

150 GB per database

Sebbene sia possibile l'aumento delle dimensioni massime consentite del database in futuro, si consideri l'utilizzo delle federazioni SQL (o partizionamento orizzontale personalizzata) per archiviare set di dati più grandi.

Numero massimo di righe recuperato per query

1,000

Vengono restituite non più di 1.000 righe (entità) in risposta a una singola richiesta. Se in una query sono contenuti più risultati rispetto a questa quantità, viene restituito un token di continuazione per poter continuare l'esecuzione di richieste aggiuntive da parte della query.

Illimitato

Il numero di righe recuperate può essere limitato dai timeout di connessione e dalle query, se non vengono ottimizzati correttamente.

Informazioni aggiuntive

  • Nell'archiviazione tabelle di Windows Azure viene utilizzato un token di continuazione nell'intestazione di risposta per indicare la presenza di risultati aggiuntivi per una query. Questi risultati possono essere recuperati inviando un'altra richiesta con parametri dal token di continuazione. In uno scenario di questo tipo è possibile recuperare elementi oltre il limite di 1.000 entità. La coerenza snapshot viene gestita per ogni richiesta, ma non tramite richieste del token di continuazione per una query.

  • Le dimensioni combinate di tutti i campi (proprietà) in una riga (entità) della tabella di Windows Azure non possono superare 1 MB. In questo limite sono incluse le dimensioni dei nomi di proprietà, nonché i valori delle proprietà o dei relativi tipi in cui sono comprese due proprietà chiave obbligatorie (PartitionKey e RowKey).

  • Database SQL supporta attualmente database di dimensioni massime pari a 5 GB (nell'edizione Web) o pari a 150 GB (nell'edizione aziendale). Per mantenere le relative dimensioni entro il valore di soglia specificato, lo sviluppatore ha la responsabilità di monitorare il database. Le dimensioni massime di Database SQL vengono preconfigurate tramite un'operazione di gestione e non aumentano automaticamente con l'aumentare dei volumi di dati archiviati. Per ulteriori informazioni, vedere ALTER DATABASE (Windows Azure SQL Database) nella documentazione di Database SQL.

  • Il numero di colonne in una tabella di Database SQL regolare è limitato a 1024 (simile a SQL Server locale). In caso di colonne di tipo sparse, una tabella può disporre di un massimo di 30.000 colonne di cui, fino a 1023, possono essere colonne di tipo non sparse. Tuttavia, almeno 28.976 devono essere colonne di tipo sparse. Una colonna di tipo non sparse viene utilizzata per il set di colonne che è obbligatorio se il numero complessivo di colonne è maggiore di 1024.

Gestione e operazioni

In questa sezione vengono confrontate le funzionalità di gestione fornite dall'archiviazione tabelle di Windows Azure e da Database SQL.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Strumenti e protocollo di gestione

REST su HTTP/HTTPS

È possibile utilizzare Esplora archivi Windows Azure o un altro strumento di terze parti, ad esempio Cloud Storage Studio.

ODBC/JDBC

REST su HTTP/HTTPS

È possibile utilizzare il portale di gestione di Windows Azure o SQL Server Management Studio per gestire un'istanza di Database SQL.

Accesso ai dati

Interfaccia del protocollo OData

È possibile accedere ai dati tramite l'API HTTP(S) REST o la libreria client .NET per WCF Data Services inclusa in Windows Azure SDK.

ODBC/JDBC

È possibile utilizzare le applicazioni scritte con le tecnologie esistenti quali ADO.NET e ODBC tramite cui è possibile comunicare con SQL Server per accedere alle istanze di Database SQL con modifiche minime al codice.

Supporto API Java

Supporto API Node.js

Supporto API PHP

Supporto LINQ

Supporto Python

No

Esperienza sviluppatore offline

Fornita dall'emulatore di archiviazione locale incluso in Windows Azure SDK.

No

SQL Express o altre edizioni di SQL Server sono prodotti diversi e non offrono la simulazione completa di un ambiente del database SQL di Windows Azure.

Informazioni aggiuntive

  • Anche se Database SQL può essere simulato in un'installazione di SQL Server locale, questo approccio non consente di replicare il comportamento che viene applicato solo al servizio basato su cloud, ad esempio la limitazione e le altre limitazioni applicabili.

  • Il database SQL di Windows Azure offre un ambiente di query interattivo basato su Web. Il Database SQL è inoltre accessibile dagli strumenti client ad hoc quale SSMS o gli strumenti di query RDBMS di terze parti che supportano ODBC.

  • Le funzionalità T-SQL sono diverse tra SQL Server e Database SQL. Alcune funzionalità sono limitate e non supportate; inoltre, alcune presentano differenze notevoli, ad esempio la creazione di database e federazioni.

Autenticazione e autorizzazione

In questa sezione vengono illustrate le funzionalità di autenticazione e autorizzazione supportate dall'archiviazione tabelle di Windows Azure e da Database SQL.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Autenticazione

Chiave simmetrica

Firme di accesso condiviso

Per autenticare gli utenti viene utilizzata la chiave HMAC a 512 bit.

Autenticazione SQL

Per autenticare gli utenti viene utilizzata l'autenticazione di SQL standard.

Accesso basato sui ruoli

No

Supporta il database SQL standard e i ruoli applicazione.

Supporto Windows Azure Active Directory (precedentemente ACS)

No

No

Federazione del provider di identità

No

No

Informazioni aggiuntive

  • L'accesso basato sui ruoli supportato da Database SQL offre flessibilità completa per la configurazione delle modalità di sola lettura, di sola scrittura e di lettura e scrittura. Questa funzionalità può fornire un set di opzioni di accesso ai dati avanzato, a seconda delle esigenze della singola applicazione.

  • Dal momento che nessuna tecnologia supporta attualmente l'autenticazione federata, basata sui certificati o di Active Directory, è necessario assicurarsi che le credenziali di sicurezza (ad esempio la chiave HMAC o il nome utente e la password di SQL) siano coperte da misure di protezione appropriate quale la crittografia. Questa protezione è particolarmente importante quando l'accesso a queste credenziali è soggetto alla conformità IT.

  • L'archiviazione tabelle di Windows Azure offre l'accesso basato su URL con firma, noto come SAS di tabella (firma di accesso condiviso). SAS (Shared Access Signature, firma di accesso condiviso) consente all'utente di concedere l'accesso basato sul tempo ai client senza rivelare la chiave privata dell'account di archiviazione. Per ulteriori informazioni, vedere questo post di blog.

Costi

In questa sezione vengono confrontati l'archiviazione tabelle di Windows Azure e Database SQL relativamente ai costi. Tutti i costi indicati in questa sezione sono soggetti a modifica in futuro.

 

Criteri di confronto Archiviazione tabelle di Windows Azure Database SQL

Costo di archiviazione

$0.125

per gigabyte archiviato per mese in base alla media giornaliera.

Per i dettagli sui prezzi, vedere la pagina relativa alla panoramica dei prezzi di Windows Azure.

Fatturato secondo una percentuale progressiva basata sulle dimensioni del database.

Per i dettagli sui prezzi, vedere la pagina relativa alla panoramica dei prezzi di Windows Azure.

Costo della transazione

$0.01

per 100.000 transazioni di archiviazione.

$0.00

In Database SQL non vengono addebitati costi per le transazioni.

Operazioni fatturabili

Tutte

Oltre ai costi di archiviazione, il costo della transazione viene calcolato in base al volume di transazioni nelle tabelle.

Nessuna

Il costo non dipende dal volume di transazioni, solo dalle dimensioni del database.

Costi di uscita

$0.12 - $0.19

per gigabyte, in base a una scala progressiva, specifica dell'area

$0.12 - $0.19

per gigabyte, in base a una scala progressiva, specifica dell'area

Informazioni aggiuntive

  • Il costo di uscita è basato sulla quantità totale di dati che escono dai data center di Windows Azure tramite Internet. La quantità viene calcolata in un determinato periodo di fatturazione quando tramite un'applicazione vengono eseguite query e si ricevono risultati dal rispettivo servizio dati.

  • A differenza di Database SQL, per l'archiviazione tabelle di Windows Azure viene imposto un costo per transazione. Questo modello di fatturazione indica che è necessario includere la frequenza di transazioni di archiviazione nelle considerazioni correlate al costo.

Conclusione

La scelta di utilizzare l'archiviazione tabelle di Windows Azure e il database SQL di Windows Azure si basa su vari fattori che possono dipendere soprattutto dalle singole esigenze dell'applicazione in uso, dalla relativa architettura, nonché dai carichi di lavoro e dai modelli di accesso ai dati. In questa sezione vengono riepilogate alcune delle considerazioni principali.

L'archiviazione tabelle di Windows Azure supporta l'archiviazione di grandi quantità di dati in tabelle altamente scalabili nel cloud. In queste tabelle è possibile archiviare terabyte di dati e miliardi di entità. Per raggiungere questo livello di scalabilità, nell'archiviazione tabelle di Windows Azure viene utilizzato un modello di scalabilità orizzontale per distribuire le entità in più nodi di archiviazione. Per supportare una scalabilità notevole di questo tipo con coerenza assoluta, viene utilizzato un modello dati NoSQL. Se viene richiesta la persistenza di una notevole quantità di modelli dati non relazionali o semplificati a un costo ridotto, si consideri l'utilizzo dell'archiviazione tabelle di Windows Azure.

Il database SQL di Windows Azure può essere paragonato al motore di database di SQL Server esteso alla piattaforma cloud, mediante il quale vengono offerti un'esperienza di sviluppatore di SQL Server comune, una semantica di query avanzata, supporto per transazioni ACID con livelli diversi di isolamento e funzionalità di elaborazione dati complesse. Se i dati sono estremamente relazionali ed è necessaria la gestione dati relazionale associata a queste funzionalità, Database SQL può essere la soluzione migliore.

Si noti che una decisione su quando utilizzare una particolare tecnologia non è sempre binaria ed è probabile che non sempre si sia in grado di scegliere una singola tecnologia. È possibile valutare se una combinazione bilanciata delle due tecnologie soddisfa meglio i requisiti della soluzione in suo, considerando di applicarle entrambe nelle rispettive aree per risolvere la classe specifica di problemi.

Acquisendo una comprensione più profonda delle due tecnologie, è possibile prendere una decisione più oculata circa la tecnologia di archiviazione dati da utilizzare in Windows Azure e il momento in cui adottarla.

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

AGGIUNGI
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft. Tutti i diritti riservati.