Il presente articolo è stato tradotto automaticamente.

Concetti sui dati

Una panoramica di Microsoft Azure DocumentDB

Julie Lerman

Scaricare l'esempio di codice(VB)

Nel novembre del 2011, ho scritto una colonna denominata "cosa diamine sono i database documento?" (MSDN.Microsoft.com/magazine/hh547103) in cui discusso alcuni dei più noti database documento: MongoDB, CouchDB e RavenDB. Tutti e tre questi database NoSQL stanno ancora andando forte. A quel tempo, Microsoft non dispone di un database di documenti sul mercato, anche se ha avuto Microsoft Azure tabella Storage, un database NoSQL basato su coppie chiave-valore. Tuttavia, in agosto 2014, è stato annunciato Microsoft Azure DocumentDB, che, come suggerisce il nome, è un servizio di database documento NoSQL disponibile su Azure.

In questa colonna, io ti fornisce una panoramica di Azure DocumentDB che spero sarà intrigo voi abbastanza per indagare ulteriormente sul proprio. Il servizio è disponibile su Azure ed era già in uso prima ancora della sua elevazione 8 aprile da un'anteprima di una risorsa disponibile in generale. Per esempio, c'è la storia di una società denominata SGS che implementato DocumentDB come parte di una soluzione al cliente grande bit.ly/1GMnBd9. Uno degli sviluppatori su quel progetto mi ha mandato un tweet su questo e ha detto che il cliente è davvero felice con lui finora.

Che cosa è un Database di documenti?

Mio precedente articolo incentrato sulla rispondendo a questa domanda, ma io discutere brevemente qui e consigliabile che leggere quell'altra colonna. Un database documento memorizza i dati come documenti, per lo più come singoli documenti JSON. (MongoDB ha una piccola torsione, perché esso squishes suoi documenti JSON in un formato binario chiamato BSON). Questa archiviazione offre prestazioni molto più veloce quando si lavora con una quantità enorme di dati perché non è necessario saltare tutto il database di tirare insieme di dati correlati. Dati correlati possono essere combinati in un unico documento JSON. Un'altra caratteristica fondamentale di un database di documenti e altri database NoSQL è che sono meno dello schema. A differenza di un database relazionale in cui tabelle bisogno schemi predefiniti al fine di archiviare e recuperare i dati, un database documento permette ogni documento definire un proprio schema. Così il database è costituito da collezioni di documenti. Figura 1 illustrato un semplice esempio di ciò che potrebbe sembrare un singolo documento JSON. Si noti che specifica un nome di proprietà insieme il valore e che contiene dati correlati.

Figura 1 documento JSON semplice

{
  "RecipeName": "Insane Ganache",
  "DerivedFrom": "Café Pasqual’s Cookbook",
  "Comments":"Insanely rich. Estimate min 20 servings",
  "Ingredients":[
    {
      "Name":"Semi-Sweet Chocolate",
      "Amount":"1.5 lbs",
      "Note":"Use a bar, not bits. Ghiradelli FTW"
    },
    {
      "Name":"Heavy cream",
      "Amount":"2 cups"
    },
    {
      "Name":"Unsalted butter",
      "Amount":"2 tbs"
    }
],
  "Directions": "Combine chocolate, cream and butter in the top ..."
}

Non solo è questo dati in formato JSON e autodescrittivi, ma contiene dati correlati (ingredienti). Un'altra caratteristica comune ad alcuni di questi database documento è che sono tutti accessibili tramite chiamate HTTP. Vedrete più su questo più tardi, e ancora una volta, la colonna precedente va in dettaglio su queste e altre caratteristiche che sono comuni a questi database.

Struttura di azzurre DocumentDB

Figura 1 Mostra l'aspetto un tipico documento memorizzato in un database di documenti. DocumentDB azzurre si compone di più di questi documenti, tuttavia. Documenti sono considerati un resourcein DocumentDB Azure e possono essere raggruppati in collezioni, che sono anche le risorse in DocumentDB. È possibile creare, aggiornare, eliminare e interrogare raccolte utilizzando chiamate HTTP, così come è possibile con i documenti. Infatti, DocumentDB è interamente costituito da diversi tipi di risorse. Collezioni sono raggruppate in un unico database di DocumentDB. Si possono avere più database in un account DocumentDB e si può avere più account.

Tutte queste risorse sono cittadini di prima classe nell'ecosfera. Inoltre, c'è un altro insieme di risorse che accompagnano i vostri documenti. Questi sono denominati in un modo che è familiare agli utenti di database relazionale: Stored procedure, definite dall'utente funzioni (UDF), indici e trigger.

Una ultima risorsa relativi ai documenti è un allegato, che è qualsiasi tipo di file binario che viene allegata al documento JSON. Il binario dell'attacco vive in Azure Blob Storage ma i metadati sono archiviati in DocumentDB, assicurando che è possibile eseguire query per gli allegati su una varietà di proprietà.

Inoltre, DocumentDB ha caratteristiche di sicurezza incorporato e, all'interno di tale ambito, utenti e autorizzazioni sono risorse che è possibile interagire con utilizzando lo stesso mezzo, come se si trattasse di documenti.

Interagendo con DocumentDB

Ci sono diversi modi di lavorare con risorse in Azure DocumentDB, tra cui: SQL, API REST e vari client API tra cui l'API .NET, che consente di utilizzare LINQ per eseguire query sul database. Può imparare molto di più circa i dettagli di una query al bit.ly/1aLm4bC.

Il portale Azure è dove creare e gestire un account DocumentDB. (Vedere la documentazione relativa al bit.ly/1Cq8zE7.) Si può anche gestire la tua DocumentDB nel portale, così come utilizzare Microsoft Document Explorer e Query Explorer per visualizzare e interrogare i documenti. Nella Query Explorer, è possibile utilizzare la sintassi SQL, come ho fatto per la query semplice in Figura 2.

Figura 2 utilizzando la sintassi SQL per eseguire Query su documenti in Esplora Query portale azzurro

È inoltre possibile utilizzare questo SQL nelle applicazioni. Ad esempio, ecco qualche codice da "Costruire un node. js Web Application utilizzando DocumentDB" (bit.ly/1E7j5Wg), dove la query è espressa nella sintassi SQL:

getOrCreateDatabase: function (client, databaseId, callback) {
  var querySpec = {
    query: 'SELECT * FROM root r WHERE r.id=@id',
    parameters: [{
      name: '@id',
      value: databaseId
    }]
  };

In questi primi giorni di DocumentDB, si potrebbe trovare questa sintassi SQL limitata, ma tieni presente che è possibile integrare SQL esistente con funzioni definite dall'utente. Ad esempio, è possibile scrivere la propria funzione CONTAINS per la costruzione di predicati che restituiscono stringhe, ad esempio CONTAINS (r.name, "Cioccolato").

Come molte altre risorse Azure, Azure DocumentDB ha un nativo API REST e possono essere interrogati e aggiornato mediante HTTP. Ogni risorsa ha un URI univoco.  Ecco un esempio di una richiesta HTTP per una particolare autorizzazione DocumentDB:

GET https://contosomarketing.documents.azure.com/dbs/ruJjAA==/users/ruJjAFjqQAA=/permissions/ruJjAFjqQABUp3QAAAAAAA== HTTP/1.1
x-ms-date: Sun, 17 Aug 2014 03:02:32 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3dGfrwRDuhd18ZmKCJHW4OCeNt5Av065QYFJxLaW8qLmg%3d
x-ms-version: 2014-08-21
Accept: application/json
Host: contosomarketing.documents.azure.com

Vai alla bit.ly/1NUIUd9 per informazioni dettagliate sull'utilizzo direttamente con l'API REST. Ma funziona con qualsiasi API REST può essere piuttosto ingombrante. Ci sono un certo numero di API client già disponibile per l'interazione con Azure DocumentDB: .NET, node. js, JavaScript, Java e Python. Scaricare il SDK e leggere la documentazione a bit.ly/1Cq9iVJ.

Sviluppatori .NET apprezzeranno il .NET libreria consente di eseguire una query utilizzando LINQ. Mentre il supporto LINQ metodo sicuramente crescerà nel tempo, le espressioni LINQ attualmente supportate sono: Queryable. Where, Queryable.Select e Queryable.SelectMany.

Prima di eseguire qualsiasi interazione con un DocumentDB, è necessario specificare un account, il database e l'insieme in cui si desidera lavorare. Il seguente, ad esempio, definisce un Microsoft.Azure.Documents.ClientDocument utilizzando l'API .NET:

string endpoint = ConfigurationManager.AppSettings["endpoint"];
string authKey = ConfigurationManager.AppSettings["authKey"];
Uri endpointUri = new Uri(endpoint);
client = new DocumentClient(endpointUri, authKey);

Questo codice di esempio viene da un percorso guidato MVC ASP.NET e DocumentDB ho seguito nella pagina di documentazione Azure (bit.ly/1HS6OEe). Il percorso guidato è abbastanza approfondito, cominciando con i passaggi per creare un account DocumentDB sul portale Azure. Mi raccomando o, in alternativa, una del walk-through che dimostrano DocumentDB con altre lingue, come l'articolo di node. js che ho citato in precedenza. L'applicazione di esempio ha un solo tipo, una classe dell'elemento, mostrato Figura 3.

Figura 3 la classe dell'elemento

public class Item
  {
    [JsonProperty(PropertyName = "id")]
    public string Id { get; set; }
    [JsonProperty(PropertyName = "name")]
    public string Name { get; set; }
    [JsonProperty(PropertyName = "descrip")]
    public string Description { get; set; }
    [JsonProperty(PropertyName = "isComplete")]
    public bool Completed { get; set; }
  }

Si noti che ogni proprietà della classe dell'elemento specifica un JsonProperty PropertyName. Questo non è obbligatorio, ma consente al client di .NET eseguire il mapping tra i dati JSON memorizzati e il mio tipo di voce e mi permette di mia proprietà di classe il nome tuttavia voglio, indipendentemente da come stai chiamarono nel database. Utilizzando il client definito, è possibile quindi esprimere una query LINQ che restituisce un'istanza di un Microsoft.Azure.Documents.Database dato un noto database Id:

var db = Client.CreateDatabaseQuery()
               .Where(d => d.Id == myDatabaseId)
               .AsEnumerable()
               .FirstOrDefault();

Da lì è possibile definire un insieme all'interno del database e infine una query insieme con un'espressione LINQ come la seguente, che restituisce un singolo documento JSON:

return Client.CreateDocumentQuery(Collection.DocumentsLink)
             .Where(d => d.Id == id)
             .AsEnumerable()
             .FirstOrDefault();

I vari oggetti all'interno dell'API .NET anche abilitare le operazioni inserire, aggiornare e cancellare i documenti con il createDocument consente­metodi Async, UpdateDocumentAsync e DeleteDocumentAsync (CUD), che avvolgono le chiamate HTTP nell'API REST. Come le query, ci sono metodi CUD rilevanti per altri tipi di risorse, quali stored procedure e allegati.

Una nuova torsione sul CAP

Uno degli aspetti più interessanti di DocumentDB che lo distingue da altri database documento è che ti consente di sintonizzare la consistenza. Il mio precedente articolo su banche dati documento parlato il teorema di CAP, che dice che dato garanzie di coerenza, disponibilità e tolleranza di partizione (CAP) in un sistema distribuito, solo due dei tre può essere raggiunto. Database relazionali assicurano coerenza al costo di disponibilità (per esempio, in attesa di completare una transazione). Database NoSQL, invece, sono più tolleranti di eventuale coerenza, dove i dati potrebbero non essere 100 per cento attuale, al fine di favorire la disponibilità.

DocumentDB azzurro fornisce un nuovo modo di affrontare il teorema CAP consentendo di ottimizzare il livello di coerenza, offrendo così la possibilità di beneficiare sia disponibilità e tolleranza partizione allo stesso tempo. È possibile scegliere tra quattro livelli di coerenza — obsolescenza forte, delimitato, sessione ed eventuali — che può essere definito per ciascuna operazione, non solo sul database. Piuttosto che di coerenza tutto o niente, è possibile regolare il livello di coerenza per soddisfare le vostre esigenze in tutta le soluzioni. Leggi ulteriori informazioni sulla documentazione DocumentDB Azure pagina a bit.ly/1Cq9p3v.

JavaScript lato server

Molti di voi sono probabilmente familiarità con le stored procedure e funzioni definite dall'utente nel database relazionali e, a differenza di altri database di documenti, DocumentDB Azure comprende questi concetti, anche se essi sono scritti in JavaScript. JavaScript possono interagire in modo nativo con JSON, quindi questo è estremamente efficiente per l'interazione con i documenti JSON e altre risorse. Trasformazioni o traduzioni o mappature non sono necessari. Un altro vantaggio di avere JavaScript lato server sotto forma di stored procedure e trigger UDF è che si ottiene transazioni atomiche attraverso documenti multipli — tutto nell'ambito della transazione sara ' tirato indietro se un processo ha esito negativo. Definizione di stored procedure e funzioni definite dall'utente è molto diverso da quello che potrebbe essere utilizzato per in un database relazionale come SQL Server. Il portale ancora non fornisce tale funzionalità.  Invece, si definisce il codice lato server nel codice lato client. Vi consiglio di guardare la sezione Script Server-Side di Azure DocumentDB codice .NET Esempi presso bit.ly/1FiNK4y.

Ora vi mostrerò come creare e memorizzare una stored procedure, quindi come eseguirlo. Figura 4 viene illustrato un semplice esempio che utilizza codice .NET API per inserire una stored procedure in un DocumentDB.

Figura 4 l'inserimento di una Stored Procedure in un DocumentDB

public static async Task<StoredProcedure> InsertStoredProcedure() {
  var sproc = new StoredProcedure
              {
                Id = "Hello",
                Body = @"
                  function() {
                    var context = getContext();
                    var response = context.getResponse();
                    response.setBody('Stored Procedure says: Hello World');
                  };"
              };
  sproc = await Client.CreateStoredProcedureAsync(setup.Collection.SelfLink, sproc);
  return sproc;
}

Io ho incapsulato tutta la logica in un metodo unico per semplicità. Mio oggetto StoredProcedure è costituito da un corpo e un ID. Il corpo è il JavaScript lato server. È preferibile creare i file JavaScript per ogni procedura e leggere il loro contenuto quando si crea l'oggetto StoredProcedure. Nel codice si presuppone che il StoredProcedure ancora non esiste nel database. Nell'esempio il download, vedrai che io chiamo per un metodo personalizzato che le query del database per garantire la procedura non esiste già prima di inserirlo. Infine, io uso SetupDocDb < T >. Proprietà client (che fornisce l'istanza DocumentClient) per creare la stored procedure, simile a come query per un documento precedente.

Ora che la stored procedure è presente nel database, posso usarlo. Questo è stato un po' difficile per me avvolgere la testa intorno perché sono abituato al modo in cui che funziona SQL Server e questo è diverso. Anche se so che identificazione della procedura è "Hello", con l'API di corrente che non è sufficiente per identificarla quando si chiama ExecuteStoredProcedureAsync. Ogni risorsa ha un SelfLink creato dalla DocumentDB. Un SelfLink è una chiave immutabile quella capacità di resto supportsthe di DocumentDB. Assicura che ogni risorsa ha un indirizzo HTTP non modificabile. Ho bisogno di quel SelfLink per raccontare il database che stored procedure per eseguire. Ciò significa che io prima devo interrogare il database per trovare la stored procedure utilizzando l'Id familiare ("Hello") così riesco a trovare il valore SelfLink. Questo flusso di lavoro è causa di attrito per gli sviluppatori e la squadra DocumentDB sta cambiando come funziona per eliminare qualsiasi esigenza di SelfLinks. Che cambiamento può anche essere fatta al momento questo articolo è andato in stampa. Ma per ora, potrai interrogare per la procedura di come avrei per qualsiasi risorsa di DocumentDB: Io uso il metodo CreateStoredProcedureQuery. Poi, con il SelfLink, posso eseguire la procedura e ottenere i suoi risultati:

public static async Task<string> GetHello() {
  StoredProcedure sproc = Client.CreateStoredProcedureQuery(Collection.SelfLink)
    .Where(s => s.Id == "Hello")
    .AsEnumerable()
    .FirstOrDefault();
  var response =
    (await Client.ExecuteStoredProcedureAsync<dynamic>(sproc.SelfLink)).Response;
  return response.ToString();
}

Creazione di funzioni definite dall'utente è simile. Definire l'UDF come JavaScript in un oggetto UserDefinedFunction e inserire il DocumentDB. Una volta che è presente nel database, è possibile utilizzare tale funzione nelle query. Inizialmente, che era possibile solo utilizzando la sintassi SQL come parametro del metodo CreateDocumentQuery, anche se supportano LINQ è stato aggiunto solo prima del rilascio ufficiale di DocumentDB a inizio aprile 2015. Ecco un esempio di una query SQL utilizzando un UDF personalizzato:

select r.name,udf.HelloUDF() AS descrip from root r where r.isComplete=false

L'UDF semplicemente sputa fuori qualche testo così che non accetta parametri.

Si noti che sto usando i nomi di JsonProperty nella query perché esso verrà elaborato sul server contro i dati JSON. Con LINQ query che vorrei utilizzare i nomi delle proprietà dell'elemento di tipo invece.

Troverete una query simile utilizzata nel download del campione, anche se là mia UDF è denominato HelloUDF.

Prestazioni e scalabilità

Ci sono tanti fattori che entrano in gioco quando si parla di prestazioni e scalabilità. Anche il design di modelli di dati e partizioni può avere un impatto entrambi questi aspetti critici di qualsiasi archivio dati. Mi raccomando di leggere la guida eccellente su modellazione dati in DocumentDB a bit.ly/1Chrjqa. Che l'articolo affronta i pro ei contro del disegno grafico e relazioni e come influenzano le prestazioni e la scalabilità di DocumentDB. L'autore, Ryan CrawCour, chi è il senior program manager del team DocumentDB, spiega quali pattern di beneficiare di prestazioni in scrittura e quale beneficio scrivere le prestazioni. Infatti, ho trovato la guida per essere utile per la progettazione del modello in generale, non solo per DocumentDB Azure.

Come si sceglie di partizionare il vostro database deve essere determinata anche dalla tua lettura e scrittura esigenze. L'articolo sul partizionamento dei dati in DocumentDB a bit.ly/1y5T4FG dà maggiori indicazioni sull'utilizzo di collezioni di DocumentDB per definire le partizioni e come definire insiemi a seconda di quanto è necessario per accedere ai dati.

Un altro vantaggio di partizionamento, è possibile creare (o rimuovere) più raccolte o database come necessario. DocumentDB bilance elasticamente; che è, esso comprenderà automaticamente l'insieme completo delle risorse.

Gli indici sono un altro fattore importante che interessa le prestazioni e DocumentDB consente di impostare politiche di indicizzazione in raccolte. Senza indicizzazione, sarebbe solo in grado di utilizzare i SelfLinks e gli ID delle risorse per eseguire una query, come ho fatto in precedenza. L'impostazione predefinita indicizzazione politica cerca di trovare un equilibrio tra le prestazioni delle query e l'efficienza dello storage, ma è possibile eseguire l'override per ottenere l'equilibrio desiderato. Gli indici sono inoltre costanti, che significa ricerche che sfruttano l'indicizzazione avranno accesso immediato ai dati nuovi. Leggi ulteriori dettagli sull'indicizzazione presso bit.ly/1GMplDm.

Non è libero, ma il costo effettivo

Gestione di prestazioni e scalabilità colpisce più che l'accessibilità dei dati, colpisce anche il costo di fornire tali dati. Nell'ambito della propria offerta azzurre, DocumentDB hanno un prezzo. Ci sono tre punti di prezzo determinati dal quale delle tre unità a livello di prestazioni che si sceglie. Perché Microsoft è costantemente tweaking il costo dei suoi servizi, è più sicuro puntare direttamente alla pagina di dettagli sui prezzi del DocumentDB (bit.ly/1IKUUMo). Come qualsiasi database NoSQL, DocumentDB è volto a fornire memorizzazione dati per enormi quantità di dati e, pertanto, può essere notevolmente più conveniente rispetto a lavorare con dati relazionali nei pertinenti scenari.

Julie Lerman è un Microsoft MVP, mentore e consulente .NET che risiede nel Vermont. È possibile trovare la sua presentazione sull'accesso ai dati e altri argomenti .NET a gruppi di utenti e conferenze in tutto il mondo. Blog di lei a thedatafarm.com ed è l'autore di "programmazione Entity Framework" (2010), nonché un codice prima edizione (2011) e un DbContext edizione (2012), tutti da o ' Reilly Media. Seguirla su Twitter a Twitter.com/julielerman. e vedere i suoi corsi Pluralsight presso Juliel.me/PS-video.

Grazie al seguente Microsoft esperto tecnico per la revisione di questo articolo: Ryan CrawCour
Ryan CrawCour è veterano di database di 20 anni che è iniziato molti anni fa, scrivendo la sua prima stored procedure per SQL Server 4.2. Molti cursori, join e stored procedure più tardi iniziò ad esplorare l'emozionante mondo libero delle soluzioni NoSQL. Ryan sta ora lavorando con il team di prodotto di DocumentDB di Redmond come Program Manager aiutando forma il futuro di questa nuova NoSQL Database-as-a-Service