Il presente articolo è stato tradotto automaticamente.

.style0 { background-color:#E2F4FD;padding:5px; } .style1 { vertical-align:bottom; } .style2 { vertical-align:top; } .style3 { vertical-align:top; } .style4 { vertical-align:top; } .style5 { vertical-align:top; } .style6 { vertical-align:bottom; } .style7 { vertical-align:top; } .style8 { vertical-align:top; } .style9 { vertical-align:top; } .style10 { vertical-align:top; } .style11 { vertical-align:bottom; } .style12 { vertical-align:top; } .style13 { vertical-align:top; } .style14 { vertical-align:top; } .style15 { vertical-align:top; }

Windows Azure Insider

Dati NoSQL Data nel cloud con Windows Azure Tables

Bruno Terkaly
Ricardo Villalobos

Scarica il codice di esempio

Bruno Terkaly and Ricardo VillalobosIl prezzo della memorizzazione dei dati su disco è diminuito così drasticamente che sembra fantascienza, aprendo le porte per le aziende memorizzare enormi quantità di dati.Ma essendo in grado di immagazzinare grandi quantità di dati economicamente risolve solo metà del problema.I dati sono diventato così grande e complessa che gli strumenti di gestione di database tradizionali e le applicazioni di elaborazione dati sono notevolmente insufficiente.Con così tanti dei dati su disco, sono sorti nuovi problemi, quali ingerendo i dati, eseguire ricerche, condivisione dei dati, analizzarla e, in ultima analisi, visualizzazione e.

La potenza del cloud computing ha intensificato per colmare questo bisogno.La possibilità di eseguire soluzioni software massicciamente parallelo — in esecuzione su decine, centinaia o addirittura migliaia di server — è il proiettile d'argento che consente alle organizzazioni di gestire tutti i dati memorizzati.

Microsoft ha realizzato questo importante trend diversi anni fa.Windows Azure Storage (WAS) è stato lanciato nel novembre 2008 e notevolmente migliorato la capacità delle imprese di ottenere il valore da enormi quantità di dati archiviati.

Le parole di Brad Calder, un distinto ingegnere presso Microsoft e il pastore che ha guidato la costruzione del sistema era, "Windows Azure Storage è un sistema di archiviazione cloud che fornisce ai clienti la possibilità di memorizzare apparentemente illimitata quantità di dati per qualsiasi durata di tempo che è altamente disponibile e durevole.Quando si utilizza Windows Azure Storage, hanno accesso ai tuoi dati da qualsiasi luogo e in qualsiasi momento e pagare solo per quello che si utilizza e conservare."

ERA viene utilizzato all'interno di Microsoft per applicazioni quali social networking di ricerca; servono dei video, musica e contenuti di gioco; e la gestione di cartelle cliniche.Viene anche utilizzato dal motore di ricerca Bing per fornire contenuto quasi immediato pubblicamente consultabile da tutti i messaggi di Facebook o Twitter o gli aggiornamenti di stato.Con circa 350 TB di dati, l'ambito dei dati di Facebook e Twitter è notevole.Quando l'ingestione di questi dati, velocità effettiva delle transazioni raggiunge picchi di circa 40.000 transazioni al secondo e totali tra 2 a 3 miliardi di transazioni al giorno.

Questo mese esploreremo una sfaccettatura di WAS — Windows Azure tabelle — sia come funziona e come gli sviluppatori possono ottenere rapidamente operativi.

Il paesaggio

Lo scienziato moderno dati si trova ad affrontare molte scelte quando si seleziona una piattaforma dati, ciascuna con la propria forza e di debolezza.Per esempio, molte soluzioni di grandi quantità di dati si basano sul concetto di NoSQL, che significa che non viene utilizzato un modello di relational database management system (RDBMS) — ci sono nessun tabelle e senza istruzioni SQL.Invece, le strutture di dati sono in genere una massiccia raccolta di coppie chiave/valore o array associativi.Le scelte popolari sono oggi MongoDB, Cassandra, HBase, CouchDB, Neo4j e tabelle di Windows Azure.Questo articolo si concentrerà sulle tabelle di Windows Azure.

Nonostante le differenze principali, database SQL e di NoSQL hanno una cosa in comune: Queste tecnologie sono offerti come servizio nel cloud, liberando gli sviluppatori da dover manualmente fornitura e de-provision server dati.Ad esempio, Windows Azure tabelle viene offerto come un servizio e uno sviluppatore non ha mai pensare in termini di server fisici separati.

In mese questo, iniziamo con una breve discussione di alcune delle caratteristiche e funzionalità di Windows Azure tabelle.Successivamente, forniremo qualche codice per dimostrare come possa lavorare con Windows Azure tabelle in termini di inserimento e l'interrogazione dei dati.E, infine, daremo un'occhiata ad alcuni degli obiettivi del progetto e i dettagli di implementazione di alto livello di WAS.

Alcune nozioni di base

Una delle caratteristiche di Windows Azure tabelle è che l'archiviazione è offerto attraverso tre regioni geograficamente distribuiti, tra cui Stati Uniti, Europa e Asia.Ogni datacenter Microsoft risponde con l'organizzazione internazionale per le standardizzazioni (ISO) 27001, SSAE 16 ISAE 3402, clausole modello UE e business Health Insurance Portability and Accountability Act (HIPAA) associare standard di accordo (BAA).Un'altra caratteristica importante è geo-ridondante di archiviazione, che consente di replicare i dati in un altro centro dati all'interno della stessa regione, aggiungendo ancora un altro livello di disaster recovery.

Capacità e prestazioni WAS correlate ai conti di deposito.Un conto di deposito individuale comprende 200 TB di storage.Windows Azure tabelle sono state ottimizzate per fornire le prestazioni delle query incredibilmente veloce sotto carichi di scrittura.Potete leggere di più a bit.ly/cMAWsZ.

Figura 1 illustrato gli obiettivi di scalabilità per un account di archiviazione singolo creato dopo il 7 giugno 2012.

Figura 1 obiettivi di scalabilità per un Account di archiviazione singolo

Conti deposito individuale
Capacità Fino a 200 TB
Transazioni Fino a 20.000 BLOB/entità/messaggi al secondo
Larghezza di banda per un Account di archiviazione ridondante Geo
Ingress Fino a 5 Gbps
Egress Fino a 10 Gbps
Larghezza di banda per un Account di archiviazione locale ridondante
Ingress Fino a 10 Gbps
Egress Fino a 15Gbps

ERA google analytics sono inoltre disponibili, permettendo agli sviluppatori di analizzare le richieste di archiviazione, analizzare le tendenze di utilizzo e ottimizzare i modelli di accesso ai dati in un account di archiviazione.Saperne di più bit.ly/XGLtGt.

Essere consapevoli del fatto che il sistema era include altre astrazioni, come BLOB e code.Qui ci concentreremo su Windows Azure tabelle, che vengono utilizzati per archiviare dati non-relazionali strutturati e semistrutturati.Il modo più succinto per esprimere il valore di Windows Azure tabelle è che sostengono le ricerche di chiave-valore NoSQL in scala e sotto carichi di scrittura.Dal punto di vista di uno sviluppatore Windows Azure tabelle sono per la memorizzazione di grandi collezioni di oggetti non uniforme o per servire le pagine di un sito Web ad alto traffico.

Windows Azure tabelle possono essere raggiunti da quasi ovunque.L'intero sistema è abilitato per REST Representational State Transfer, il che significa che qualsiasi client capace di HTTP può comunicare con il sistema WAS.Ovvi clienti includono iOS, Android, Windows 8 e diverse distribuzioni di Linux.L'API REST supporta inserti, upserts, aggiornamenti ed eliminazioni e seleziona o query.

Quando si lavora con Windows Azure tabelle, una chiave il punto di partenza è capire come controllare lo schema di partizionamento dei dati.Per qualsiasi dato Windows Azure tabella, l'architetto di dati deve definire (davanti) un PartitionKey e un RowKey.Questa è forse la decisione più importante che farai quando si utilizza Windows Azure tabelle.PartionKeys e RowKeys determinano come i dati sono partizionati automaticamente il servizio di archiviazione e il modo che eseguirà la query.È consigliabile che si capisce come i dati sarà possibile eseguire una query prima di finalizzare le tue decisioni su PartitionKey e RowKey.Più tardi, potrai approfondire la meccanica di consistenza transazionale e il loro rapporto a PartitionKeys.Per ora, camminiamo attraverso un semplice esempio di come le partizioni di sistema WAS tabella dati.

Un rapido Tutorial

Immaginate che si desidera memorizzare e recuperare messaggi e-mail da vari­domini di unità organizzative, come la seguente: bterkaly@Microsoft.com, ricardo.villalobos@microsoft.com, brunoterkaly@hotmail.com e ricardovillalobos@hotmail.com.In questi indirizzi di posta elettronica, i nomi di dominio sono microsoft.com e hotmail.com, mentre i nomi di posta elettronica sono bterkaly e ricardo.villalobos.Tipica query di ricerca prima dal nome di dominio, quindi dal nome di posta elettronica.

In questo semplice esempio, la scelta di PartitionKey e RowKey sono abbastanza semplici.Noi ti mappa il nome di dominio per il PartitionKey e il nome di posta elettronica per il RowKey.

Il codice in Figura 2 dovrebbe rendere le cose un po' più chiare.Esso illustra quattro semplici funzionalità:

  • Definizione di un'entità (EmailAddressEntity)
  • Definizione della tabella verrà archiviate le entità (Email­AddressTable)
  • Inserimento di entità nella tabella (insert EmailAddress­entità in EmailAddressTable)
  • Una query sulla tabella per la ricerca di un'entità specifica (Cerca bterkaly@microsoft.com)

Figura 2 l'entità EmailAddressEntity

// Our entity derives from TableEntity public class EmailAddressEntity : TableEntity {   // Basic information that makes up our entity   public string EMailAddress { get; set; }   public string PhoneNumber { get; set; }   // A necessary default constructor   public EmailAddressEntity()   {   }   // A two-parameter constructor   public EmailAddressEntity(string email, string phone)   {     EMailAddress = email;     PhoneNumber = phone;     SetKeys(email, phone);   }   // A method that initializes the partition key and row key   public void SetKeys(string email, string phone)   {     int startIndex = email.IndexOf("@");     // Extract the mailname from the e-mail address     string mailname = email.Substring(0, startIndex);     // Extract the domain from the e-mail address     string domain = email.Substring(startIndex + 1);     // Perform the mandatory assignments to the partition key and row key     PartitionKey = domain;     RowKey = mailname;     PhoneNumber = phone;   } }

In primo luogo, si definisce la struttura di entità stessa, EmailAddressEntity, come mostrato Figura 2. La tabella effettiva (un contenitore per le entità) verrà definita più tardi, quando noi inserire EmailAddressEntity nella tabella. Un'entità può essere pensata come un singolo oggetto; è la più piccola unità di dati che possono essere archiviati in una tabella di Windows Azure. Come accennato in precedenza, un'entità è un insieme di coppie nome-valore tipizzate, spesso definito come proprietà. Le tabelle sono insiemi di entità, e ogni entità appartiene a un tavolo come una riga in una tabella di database relazionale. Ma tabelle di archiviazione Windows Azure tabella non hanno uno schema fisso. Non è richiesto che tutte le entità in una tabella di essere strutturalmente identiche, come nel caso di una tabella di database relazionale.

Ci sono quattro principali pezzi di informazione in Figura 2. I primi due, indirizzo email e numero di telefono, sono semplicemente due stringhe che vogliamo conservare. Gli altri due sono le proprietà PartitionKey e RowKey, che abbiamo discusso in precedenza. Una terza proprietà necessaria di tutte le entità è il Timestamp, che è utilizzato internamente dal sistema per facilitare la concorrenza ottimistica.

La colonna Timestamp differisce dalle colonne PartitionKey e RowKey perché viene compilata automaticamente dal sistema di WAS. Al contrario, gli sviluppatori sono tenuti a inserire la proprietà PartitionKey e RowKey.

Per riassumere, l'importanza della PartitionKey e RowKey è principalmente circa le prestazioni delle query e consistenza transazionale. Abbiamo spiegato in precedenza le prestazioni delle query e dipende in gran parte il modo che i dati sono diviso tra i nodi di archiviazione. Ma PartitionKeys consentono inoltre di apportare modifiche alle entità multiple come parte dell'operazione stessa, permettendo agli sviluppatori di rollback di modifiche dovrebbe fallire ogni singola operazione. Il requisito è che le entità sono parte dello stesso gruppo di entità, che in realtà significa che entità condividono lo stesso PartitionKey. Le transazioni sono supportate all'interno di un singolo PartitionKey.

Il codice in Figura 3 illustra un'istanza di un'entità di tipo EmailAddressEntity (da Figura 2) e poi inserire tale entità in EmailAddressTable. Si noti che stiamo usando l'emulatore di archiviazione locale. Questo ci permette di eseguire e testare il nostro codice e dati localmente senza il collegamento di un datacenter.

Figura 3 inserendo un EmailAddressEntity

try {   // Use the local storage emulator   var storageAccount = CloudStorageAccount.DevelopmentStorageAccount;   // Create a cloud table client object   CloudTableClient tableClient = storageAccount.CreateCloudTableClient();   // Create an e-mail address table object   CloudTable emailAddressTable =     tableClient.GetTableReference("EmailAddressTable");   // Create the table if it does not exist   // Only insert a new record once for this demo   if (emailAddressTable.CreateIfNotExists() == true)   {     // Create a new EmailAddressEntity entity     EmailAddressEntity emailaddress = new       EmailAddressEntity("bterkaly@microsoft.com", "555-555-5555");     // Create an operation to add the new e-mail and phone number to     // the emailAddressTable     TableOperation insertEmail = TableOperation.Insert(emailaddress);     // Submit the operation to the table service     emailAddressTable.Execute(insertEmail);   } } catch (Exception ex) {   // Put the message in the Web page title (for testing purposes)   // Real error messages should go to a proper log file   this.Title = ex.Message.ToString();   throw; }

È possibile visualizzare i dati nel riquadro Esplora Server in Visual Studio 2012, come mostrato Figura 4, che rende il processo di scrittura e di test del codice molto più facile. È anche possibile allegare Esplora Server a un'istanza reale del vostro Windows Azure tabelle in un datacenter.

Server Explorer
Figura 4 Server Explorer

Il codice in Figura 5 illustra come eseguire una query dei dati.

Figura 5 query Windows Azure tabelle

// Use the local storage emulator var storageAccount = CloudStorageAccount.DevelopmentStorageAccount; try {   // Create the table client   CloudTableClient tableClient = storageAccount.CreateCloudTableClient();   CloudTable emailAddressTable =     tableClient.GetTableReference("EmailAddressTable");   // Retrieve the entity with partition key of "microsoft.com"    // and row key of "bterkaly"   TableOperation retrieveBrunoEmail =     TableOperation.Retrieve<EmailAddressEntity>(     "microsoft.com", "bterkaly");   // Retrieve entity   EmailAddressEntity specificEntity =     (EmailAddressEntity)emailAddressTable.Execute(retrieveBrunoEmail).Result;   TableResult result =     emailAddressTable.Execute(TableOperation.Retrieve<EmailAddressEntity>(     "microsoft.com", "bterkaly"));   // Pull the data out that you searched for   // Do something with emailAddress and phoneNumber   string emailAddress = specificEntity.EMailAddress;   string phoneNumber = specificEntity.PhoneNumber; } catch (Exception ex) {   // Put the message in the Web page title (for testing purposes)   // Real error messages should go to a proper log file   this.Title = ex.Message.ToString();   throw; }

Il codice esegue una semplice query utilizzando PartitionKey e RowKey. Si noti che è possibile costruire query abbastanza complesse utilizzando questi filtri, perché si possono unire insieme in maniera ad hoc. Costruiamo un oggetto query utilizzando il filtro combinato. Il passo finale è semplicemente eseguire la query e fare tutto ciò che è necessario con il EmailAddressEntity. I WAS libreria Client semplifica notevolmente le operazioni di creazione/lettura/aggiornamento/eliminazione (CRUD) così come le query necessarie.

Cosa c'è dentro

Abbiamo pensato che potrebbe essere utile dare un'occhiata un po' più in profondità l'architettura interna del sistema è stato mostrato Figura 6. Gran parte della narrazione seguente è basato sul libro di Brad Calder a cui fa riferimento in questo articolo.

Windows Azure Storage Internals
Figura 6 Windows Azure Storage Internals

ERA è composta da una serie di francobolli di archiviazione relativo datacenter otto. Un timbro di archiviazione è un cluster di circa 10-20 rack di nodi di archiviazione. Ogni rack si siede in un dominio separato guasto. Ogni rack è dotato di alimentazione e reti ridondanti. Ogni timbro di archiviazione contiene circa 30PBs di storage raw.

Per mantenere bassi i costi, è importante tenere questi francobolli di archiviazione in esecuzione sopra l'utilizzo il 70 per cento, che viene misurata in termini di capacità, transazioni e larghezza di banda. Andando sopra il 90 per cento è considerato troppo alto, però, come lascia poco headroom in caso di mancanza di rack, quando il sistema ha bisogno di fare di più con meno.

Servizio di posizione di archiviazione

Lo sviluppatore non ha alcun controllo diretto sulla memorizzazione posizione servizio (SLS). A livello di account, non solo fa la SLS mappa conto degli spazi dei nomi attraverso tutti i francobolli, è anche responsabile per il ripristino di emergenza, allocazione di archiviazione conto e bilanciamento del carico. La SLS semplifica notevolmente la capacità di aggiungere nuovo storage in un datacenter. Può allocare nuovi account di archiviazione per i francobolli nuovi per i clienti così come caricare saldo account di archiviazione esistente da vecchi francobolli nuovi francobolli. Tutte queste operazioni con la SLS sono fatti automaticamente.

Diamo un'occhiata a little closer a tre strati che compongono un timbro di archiviazione — stream, partizione e front end (FE) — a partire dal basso.

Lo strato di flusso fornisce un'interfaccia interna che dello strato di partizione viene utilizzato per leggere e scrivere file di grandi dimensioni ed è responsabile della funzionalità di replica di nucleo. Lo strato di flusso gestisce anche apertura, chiusura, eliminazione, ridenominazione, lettura, aggiungendo a e concatenazione di questi file di grandi dimensioni. Esso non riguarda se stesso con la semantica degli oggetti che sono nel flusso di dati.

Il livello di partizione fornisce il modello di dati per i diversi tipi di oggetti memorizzati (tabelle, BLOB, Code); la logica e la semantica per elaborare i diversi tipi di oggetti; uno spazio dei nomi ampiamente scalabile per gli oggetti; Load balancing per accedere agli oggetti attraverso i server di partizione disponibile; ordinazione di transazione e forte coerenza per l'accesso agli oggetti; e la geo-replica di oggetti dati dalla primaria alla secondaria regione.

Il livello di partizione incapsula anche una struttura di dati interna importante chiamata un oggetto Table. Ci sono diverse versioni della tabella oggetto, compresa la tabella di entità, che memorizza tutte le righe di entità per tutti gli account in bollo. Esso è utilizzato per esporre pubblicamente astrazione dei dati di Windows Azure tabella. La tabella dell'oggetto interagisce anche con il livello di partizione per garantire la coerenza dei dati di ordinazione le transazioni con BLOB, racconti e code.

Lo strato di FE è composto da un insieme di server apolide che accettano le richieste in arrivo. Al ricevimento di una richiesta, un FE cerca AccountName, autentica e autorizza la richiesta poi indirizza la richiesta al server appropriato partizione in tramezze (basato sul PartitionName). Per migliorare le prestazioni, il FE mantiene e memorizza nella cache una mappa delle partizioni, affinché routing al server appropriato partizione è accelerato su dati cui si accede frequentemente.

Conclusioni

In questo articolo, abbiamo fornito alcune linee guida di alto livello, utilizzabili come pure alcuni dettagli architettonici su come è progettato il sistema è stato, e in particolare come Windows Azure tabelle possono aiutare a gestire i dati. Vorremmo ringraziare Brad Calder per alcune delle sue intuizioni condivise "Windows Azure Storage: Un altamente disponibile servizio di Cloud Storage con Strong coerenza,"un documento recentemente pubblicato per la 23a ACM Symposium su principi di sistemi operativi (SOSP). È possibile scaricare la sua carta a bit.ly/tMIPus.

Windows Azure Storage Client Library 2.0

Torna a fine ottobre 2012, Microsoft ha rilasciato una nuova libreria client-side storage — Windows Azure Storage (WAS) Client Library 2.0 — che migliora drasticamente usabilità, estensibilità e le prestazioni quando si interagisce con Windows Azure tabelle. È possibile installare i WAS Client Library 2.0 con NuGet da bit.ly/YFeHuw. Questo può essere fatto all'interno di Visual Studio 2012. Per un dettagliato sguardo ad alcune delle grandi novità, visita bit.ly/VQSaUv.

La nuova libreria include alcuni nuovi approcci che migliorano la funzionalità per quanto riguarda le prestazioni, estensibilità e usabilità. Una caratteristica piacevole si evita la seccatura di doversi preoccupare di serializzazione e deserializzazione logica quando si lavora con C# oggetti POCO (Plain Old). Un'altra caratteristica interessante è la EntityResolver, che consente di eseguire le proiezioni sul lato client, è possibile creare oggetti al volo in base alle informazioni che ti interessa. In breve, è possibile convertire direttamente dai dati di entità tabella per un tipo di oggetto client senza un tipo di classe di entità tabella separata che deserializza singolarmente ogni proprietà. Un altro potente tecnologia è l'interfaccia IQueryable, che ti dà un modo espressivo per definire le query LINQ complesse.

Bruno Terkaly è un developer evangelist Microsoft. La sua profonda competenza deriva da anni di esperienza nel campo, scrivendo codice utilizzando una moltitudine di piattaforme, linguaggi, framework, SDK, librerie e API. Trascorre il tempo scrittura di codice, blogging e dare presentazioni dal vivo sulla creazione di applicazioni basate su cloud, in particolare utilizzando la piattaforma Windows Azure. Terkaly è anche autore di due applicazioni Windows Store, insegnare a bambini auto colori e bambini insegnare Musica. Si può leggere il suo blog a blogs.msdn.com/brunoterkaly.

Ricardo Villalobos è un architetto software con oltre 15 anni di esperienza nella progettazione e nella creazione di applicazioni per aziende nel settore SCM (Supply Chain Management). Possesso di certificazioni tecniche diverse, come pure un Master in business administration presso l'Università di Dallas, lavora come un architetto cloud nel gruppo di incubazione CSV di Windows Azure per Microsoft.

Terkaly e Villalobos congiuntamente presentare conferenze a grande industria. Incoraggiare i lettori a contatto con loro per la disponibilità. Terkaly può essere raggiunto a bterkaly@microsoft.com e Villalobos può essere raggiunto a Ricardo.Villalobos@microsoft.com.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Brad Calder (Microsoft) e Jai Haridas (Microsoft)