Il presente articolo è stato tradotto automaticamente.

Concetti sui dati

Cosa sono i database di documenti?

Julie Lerman

 

Vi sono buone probabilità che almeno si è sentito parlare del termine di NoSQL a questo punto. Gli articoli sono stati scritti anche su di esso qui in MSDN Magazine. Molte persone che altamente rispettare sono piuttosto entusiasti e coltivati su database relazionali, voleva avere una migliore comprensione dello spazio. Ho fatto piuttosto un po' di ricerca e pestering degli amici a capo testa intorno ad esso e qui condividerete con ciò che ho appreso informazioni su un sottoinsieme dei database NoSQL chiamato "document database". Sottoinsieme di un altro è un database di coppia chiave-valore. Archiviazione di tabella Windows Azure, parlato nel mio articolo di luglio 2010 coordinate (msdn.microsoft.com/magazine/ff796231), è un esempio di una coppia chiave-valore archivio NoSQL.

È necessario indirizzare innanzitutto la definizione di NoSQL. È diventato un bit di un termine molto diffusa ed eventualmente utilizzate in modo eccessivo. Il termine viene utilizzato fino a comprendere i meccanismi di archiviazione dei dati che non sono relazionale e pertanto non richiedono l'utilizzo di SQL di accesso ai dati. Nel suo post di blog, "Indirizzamento di suggerimenti di NoSQL" (bit.ly/rkphh0), esperto di CouchDB e autore Ivan Holt, afferma che egli ha sentito persone "ridefinizione NoSQL come 'non solo SQL.'" Il punto è che questo non è un anti-SQL circolazione con qualsiasi mezzo. Mi piace questa prospettiva, poiché sono un sostenitore utilizzando lo strumento appropriato per il processo.

La maggior parte dei database che rientrano gli obiettivi comuni di condivisione non relazionali ombrello di velocità e scalabilità. Dal modello di archiviazione relazionale e lasciando gli schemi dietro, questi database sono liberi di limitazioni di mettere al momento della loro uno schema strettamente associato e la necessità dell'applicazione per unire i dati in tabelle.

I molti database di documento disponibili, mi concentrerò su due dei più diffusi, ovvero MongoDB (mongodb.org) e CouchDB (couchdb.apache.org), ovvero come RavenDB (ravendb.net), che è stato scritto per Microsoft.NET Framework ed è in forte crescita in popolarità (vedere l'articolo "Embedding RavenDB in una pagina ASP.NET MVC applicazione 3,"in questo numero). Sarà comunque ad alto livello, anche se è possibile apprendere molti ulteriori dettagli sui singoli database e cosa li rende univoco uno da altro visitando i siti Web.

Con l'eccezione di alcuni mancheranno (che è possibile sottolineare in questo articolo), questi database forniscono i dati più comunemente mediante HTTP, i dati vengono archiviati come documenti JavaScript Object Notation (JSON) e le API in più lingue. Le problematiche generali sono semplicità, velocità e scalabilità. Altrettanto importante è che tutti e tre i progetti open source.

Nella mia ricerca, un esperto di MongoDB ho sentito dire che la preoccupazione principale del prodotto è delle prestazioni. Per semplicità e l'affidabilità ("vogliamo essere l'accordo Honda dei database"), a cui punta un esperto di CouchDB. E Ayende Rahien, creatore del RavenDB, ha dichiarato che ravendb si intende per "fast scritture, Letture veloce e pace world." Ciascuno di questi database documento ha ancora più da offrire rispetto a ciò che suggeriscono morsicature questi suoni.

In alternativa, non una sostituzione, per i database relazionali

Database NoSQL e il documento è fornire un'alternativa per i database relazionali, non una sostituzione. Ognuno ha il suo posto, e semplicemente forniscono si con più opzioni tra cui scegliere. Ma come scegliere? Un indicatore importante è il teorema di coerenza, disponibilità e tolleranza di partizione (CAP). Afferma che quando si lavora in sistemi distribuiti, è possibile avere solo due delle tre garanzie (C, i a o P), in modo da avere per il prelievo di ciò che è importante. In caso di più importanti della coerenza, è necessario accedere con un database relazionale.

Un esempio comune di dove la coerenza è la garanzia più importante è un'applicazione bancaria, o forse uno che viene eseguito un impianto nucleare. In questi scenari, è fondamentale che ogni singolo blocco di dati è contabilizzata in ogni momento. Se un utente apporta una revoca, veramente necessario conoscere cosa ne pensate quando si stanno analizzando il saldo del proprio conto. Pertanto, è necessario un database relazionale con un elevato livello di controllo delle transazioni. Un termine sentirà che spesso è "coerenza finale" o come espresso nel RavenDB del sito: "meglio obsoleti rispetto a non in linea". In altri domini, l'eventuale coerenza è sufficiente. È OK se si stanno recuperando di dati non sono fino al millisecondo accurate.

Quindi, ad esempio, è più importante che una versione dei dati è disponibile, anziché in attesa di tutte le transazioni mancanti. Il problema è relativo di (disponibilità) nel CAP, che si concentra sui tempi di attività del server. Sapendo che sarà sempre disponibile l'accesso al database ha la precedenza ed è un enorme vantaggio per le prestazioni del database (database di documento sono veloci!). Si noterà che P, tolleranza di partizione, è inoltre importante per i database del documento, soprattutto quando si modifica in scala orizzontalmente.

API HTTP rESTful, prevalentemente

Molti dei database di NoSQL sono accessibili in modo RESTful, in modo che si esegue la connessione di database tramite un URI e le query e comandi sono chiamate HTTP. MongoDB è un'eccezione. All'impostazione predefinita consiste nell'utilizzare TCP per le interazioni di database, anche se è disponibile almeno un API di HTTP, nonché. CouchDB e MongoDB forniscono le API specifiche della lingua che consentono di scrivere ed eseguire query e aggiornamenti senza doversi preoccupare di scrivere direttamente le chiamate HTTP. RavenDB ha una.NET API che semplifica l'interazione con il database.

Dati correlati in un singolo Record

Molte persone è erroneamente dedurre che i database relazionali sono i file flat. I documenti memorizzati in un database di documento sono in grado di contenere dati di forma: alberi con i nodi. Ogni record nel database è un documento e può essere un gruppo autonomo di dati. È che descrive self, includendone lo schema probabilmente univoco e non è necessariamente dipendente da qualsiasi altro documento.

Di seguito è riportato un esempio tipico di aspetto un record in un database di documento (verrà rubare un campione dell'esercitazione di MongoDB che rappresenta uno studente):

{
  "name" : "Jim",
  "scores" : [ 75, 99, 87.2 ]
}

Ed Ecco uno dall'articolo introduttivo CouchDB, che descrive un libro:

{
  "Subject": "I like Plankton"  
  "Author": "Rusty"  
  "PostedDate": "5/23/2006"  
  "Tags": ["plankton", "baseball", "decisions"]
  "Body": "I decided today that I don't like baseball.
I like plankton."
}

Si tratta di semplici strutture con i dati delle stringhe, numeri e le matrici. È inoltre possibile incorporare gli oggetti all'interno di oggetti per una struttura di documento più complesso, ad esempio in questo esempio di post di blog:

{
  "BlogPostTitle”: “LINQ Queries and RavenDB”,
  "Date":"\/Date(1266953391687+0200)\/",
  "Content":”Querying RavenDB is very familiar for .NET developers who are already
    using LINQ for other purposes”,
  "Comments":[
             {
             "CommentorName":"Julie",
             "Date":"\/Date(1266952919510+0200)\/",
             "Text":"Thanks for using something I already know how to
               work with!",
             "UserId":"users/203907"             
             },
  ]
}

Chiavi univoche

Tutti i database richiedono una chiave. Se non si fornisce uno, essi creerà uno internamente. Le chiavi sono fondamentali per la capacità dei database per indice, ma il proprio dominio può richiedere che è venuta chiavi. Nell'esempio di post di blog precedente, si noti che non vi è un riferimento a "utenti/203907". Si tratta di come RavenDB si avvale di valori di chiave e consente di definire le relazioni tra documenti.

Archiviazione in formato JSON

Ciò che questi tutti i record di esempio hanno in comune è che si sta utilizzando JSON per memorizzare i propri dati. CouchDB e RavenDB (e molti altri) in realtà memorizzare i dati in JSON. MongoDB utilizza una torsione in JSON chiamato JSON binario (BSON), è in grado di eseguire la serializzazione binaria. BSON è la rappresentazione interna dei dati, in modo da punto di vista della programmazione, si consiglia di non notare alcuna differenza.

La semplicità di JSON rende più semplice di trasporre le strutture di oggetto di quasi tutte le lingue in JSON. Di conseguenza, è possibile definire gli oggetti dell'applicazione e memorizzarli direttamente nel database. Ciò evita agli sviluppatori la necessità di utilizzare un'utilità di mapping relazionale a oggetti (ORM) costantemente la conversione tra lo schema del database e lo schema dell'oggetto di classe.

I motori di ricerca full-text, ovvero, Lucene (lucene.apache.org), ad esempio, è ciò che RavenDB si basa su, ovvero fornire ad alte prestazioni di ricerca su questi dati basati su testo.

Si noti la data nell'esempio di post di blog. JSON non dispone di un tipo di data, ma ogni database fornisce un modo per interpretare i tipi di data da indipendentemente dal linguaggio che si sta la codifica. Se si estrae l'elenco di tipi di dati e le convenzioni per l'API di BSON MongoDB (bit.ly/o87Gnx), si noterà che viene aggiunto un tipo di data, insieme ad alcune altre, mettono in evidenza ciò che è disponibile in JSON.

Archiviazione e recupero di dati correlati in una singola unità può avere grandi prestazioni e i vantaggi di scalabilità. Database non devono andare trolling intorno a trovare i dati che comunemente sono correlati, perché è tutto.

Insiemi di tipi

Quando si interagisce con il database, come l'applicazione sapere che un elemento è uno studente, un altro è un libro e un altro è un post del blog? I database utilizzano un concetto degli insiemi. Qualsiasi documento, indipendentemente dal relativo schema, che è associato a un insieme specifico, ad esempio, un insieme di studenti, ovvero possono essere recuperati quando vengono richiesti i dati da tale insieme. Inoltre, non è raro che di utilizzare un campo per indicare il tipo. In tal modo le ricerche molto più semplice, ma è per l'applicazione per imporre che cosa deve e non deve passare in un insieme.

Minore di schema di Database

"student" descritto contiene versioni precedenti di un proprio schema. Ogni record è responsabile di un proprio schema, anche quelli contenuti in un unico database o di un insieme. E un record di studente non necessariamente corrispondono a un altro record di studente. Naturalmente, il software necessario gestire eventuali differenze. È semplicemente impossibile sfruttare questa flessibilità per migliorare l'efficienza. Ad esempio, per cui archiviare i valori null? Quando una proprietà, ad esempio "classe most_repeated," non contiene alcun valore, è Impossibile eseguire le operazioni seguenti:

"name" : "Jim",
"scores" : [ 75, 99, 87.2 ]
"name" : "Julie",
"scores" : [ 50, 40, 65 ],
"most_repeated_class" : "Time Management 101"

Sì, Virginia, supporto delle transazioni

Ogni database fornisce un certo livello di supporto delle transazioni, ovvero alcune ulteriori rispetto ad altri, ma non è altrettanto ricca di ciò che può essere ottenuto in un database relazionale. Verrà rinviare alla relativa documentazione e consentono di follow-up con proprie ricerche aggiuntive.

I database del documento e lo sviluppo basato su dominio

Uno dei concetti principali dello sviluppo basato su dominio relativo al dominio utilizzando le radici di aggregazione di modellazione. Quando si pianificano le classi di dominio (che possono diventare documenti nel database), cercare dati più spesso indipendente (ad esempio, un ordine con le relative voci di riga) e lo stato attivo su tale come una struttura di dati individuali. In un sistema di ordinazione, probabilmente sarà dispongono anche di clienti e prodotti. Ma è possibile accedere a un ordine senza le informazioni del cliente e un prodotto può essere utilizzato senza la necessità di accesso per gli ordini in cui viene utilizzato. Ciò significa che, anche se è possibile trovare molte opportunità di disporre di strutture di dati indipendente (ad esempio, l'ordine con le relative voci di riga), non escludere la necessità o la possibilità di unire i dati tramite le chiavi esterne in determinati scenari.

Ogni database fornisce indicazioni su vari modelli disponibili e quelle che gli utenti hanno la massima efficacia con. Ad esempio, documentazione MongoDB parla di una serie di predecessori di matrice, il che consente di velocizzare l'accesso ai dati correlati durante l'unione di documenti.

Dubbi sull'esplorazione di relazioni sono associati al fatto che in un database relazionale, i dati ripetuti è un sin. I database sono normalizzati a tale scopo. Quando si lavora nel database di NoSQL, in particolare quelli che vengono distribuiti, la denormalizzazione dei dati è utile e accettabili.

L'esecuzione di query e l'aggiornamento

Ogni database viene fornito con le API per l'esecuzione di query e l'aggiornamento. Mentre potrebbero non essere parte dell'API di principale, vengono forniti una serie di API delle lingue tramite i componenti aggiuntivi. Come un.Entrata di NET Framework in tutto il mondo di database del documento, RavenDB utilizza LINQ per l'esecuzione di query, ovvero un vantaggio interessante per.Sviluppatori NET.

Altre query dipendono dalle viste predefinite e un modello denominato mappa/ridurre. La parte di mappa di questo processo utilizza le viste e la responsabilità della mappa presenta differenze tra i database. La mappa consente inoltre il database distribuire l'elaborazione tra più processori delle query. Accetta di ridurre il risultato della query mappa (o query, se è stata distribuita) e aggregati i dati in risultati da restituire al client.

Ridurre/Map è uno schema e i vari database dispongono di proprie implementazioni. Rob Ashton fornisce un confronto interessante di come RavenDB e CouchDB eseguire mappa/ridurre a bit.ly/94OCME.

Mentre CouchDB richiede che si esegue una query tramite visualizzazione mappa/ridurre predefiniti, MongoDB (anche utilizzando visualizzazioni e ridurre/mappa) fornisce inoltre la possibilità di eseguire query ad hoc. RavenDB consente di indici già definiti per l'esecuzione di query, ma anche supportare query ad hoc e creerà gli indici automaticamente in base alla query effettivo in fase di esecuzione. Maggior parte dei casi, tuttavia, quando abbandonando lo schemi noti e la natura relazionale dei database di SQL, la possibilità di eseguire query ad hoc è una delle funzionalità che si perde. Dalla presenza di uno stretto controllo tramite l'esecuzione di query, i database di documento sono in grado di promettere loro prestazioni veloci.

Una rivoluzione di Database

Esistono in modo maggior parte dei database relazionali disponibili sotto l'ombrello di NoSQL. E ora che lo sportello è aperto, è ispirazione altri in futuro come gli amministratori di esaminare che cosa è disponibile e sognano il modo in cui potrebbe migliorare su di esso. Credo che RavenDB è un ottimo esempio e si può guardare come Rahien si sta evolvendo il database come egli continua a da sogno su come rendere meglio o diventa ispirato da parte degli utenti.

Credo che sia infettiva di misteriosi intrighi su questi database. Senza dubbio Spero di dettagli ulteriori e approfondite. Ma anche le tre che ho esaminato sono così interessante che è difficile per questo Libra di scegliere tra di essi, perché al momento, sto su come risolvere un problema di curiosità e non un problema aziendale reale e i database relazionali sono costituiti da più adatta per i progetti personali correnti.

Julie Lerman è un Microsoft MVP.NET mentore e consulente che vive tra le colline di relatrice. È possibile trovare le sue presentazioni relative all'accesso ai dati e altri argomenti su Microsoft .NET in occasioni di conferenze che si tengono in tutto il mondo. Un blog she al thedatafarm.com/blog ed è l'autore del libro "Programming Entity Framework" (o ' Reilly Media, 2010) apprezzato. Seguire her movimenti in twitter.com/julielerman.

Grazie per i seguenti esperti tecnici per la revisione di questo articolo: Ted Neward e Savas Parastatidis