NoSQL - NoSQL

"Archiviazione strutturata" reindirizza qui. Per la tecnologia Microsoft nota anche come archiviazione strutturata, vedere Archiviazione strutturata COM .

Un NoSQL (originariamente riferito a "non- SQL " o "non-relazionale") banca dati fornisce un meccanismo per lo stoccaggio e il recupero di dati che viene modellata in mezzi diversi i rapporti tabulari utilizzati nei database relazionali . Tali database esistono dalla fine degli anni '60, ma il nome "NoSQL" è stato coniato solo all'inizio del 21° secolo, innescato dalle esigenze delle aziende Web 2.0 . I database NoSQL sono sempre più utilizzati nei big data e nelle applicazioni web in tempo reale . I sistemi NoSQL sono talvolta chiamati anche "Non solo SQL" per sottolineare che possono supportare linguaggi di query simili a SQL o stare accanto a database SQL in architetture poliglotta-persistenti .

Le motivazioni per questo approccio includono semplicità di progettazione , ridimensionamento "orizzontale" più semplice a cluster di macchine (che è un problema per i database relazionali), controllo più preciso sulla disponibilità e limitazione della mancata corrispondenza dell'impedenza relazionale tra oggetti . Le strutture dati utilizzate dai database NoSQL (es . coppia chiave-valore , colonna larga , grafico o documento ) sono diverse da quelle utilizzate di default nei database relazionali, rendendo alcune operazioni più veloci in NoSQL. La particolare idoneità di un dato database NoSQL dipende dal problema che deve risolvere. A volte le strutture dati utilizzate dai database NoSQL sono viste anche come "più flessibili" rispetto alle tabelle di database relazionali.

Molti archivi NoSQL compromettono la coerenza (nel senso del teorema CAP ) a favore della disponibilità, della tolleranza delle partizioni e della velocità. Gli ostacoli alla maggiore adozione degli archivi NoSQL includono l'uso di linguaggi di query di basso livello (invece di SQL, ad esempio), la mancanza di capacità di eseguire join ad hoc tra tabelle, la mancanza di interfacce standardizzate e enormi investimenti precedenti in database relazionali esistenti . La maggior parte dei negozi NoSQL non ha vere transazioni ACID , anche se alcuni database li hanno resi centrali nei loro progetti.

Invece, la maggior parte dei database NoSQL offre un concetto di " consistenza finale ", in cui le modifiche al database vengono propagate a tutti i nodi "alla fine" (in genere entro millisecondi), quindi le query per i dati potrebbero non restituire immediatamente i dati aggiornati o potrebbero risultare nella lettura di dati che sono non accurato, un problema noto come letture non aggiornate. Inoltre, alcuni sistemi NoSQL possono presentare scritture perse e altre forme di perdita di dati . Alcuni sistemi NoSQL forniscono concetti come la registrazione write-ahead per evitare la perdita di dati. Per l'elaborazione delle transazioni distribuite su più database, la coerenza dei dati è una sfida ancora più grande, difficile sia per i database NoSQL che per i database relazionali. I database relazionali "non consentono ai vincoli di integrità referenziale di estendersi ai database". Pochi sistemi mantengono sia le transazioni ACID che gli standard X/Open XA per l'elaborazione delle transazioni distribuite. I database relazionali interattivi condividono tecniche di analisi del relè conformazionale come caratteristica comune. Le limitazioni all'interno dell'ambiente dell'interfaccia vengono superate utilizzando i protocolli di virtualizzazione semantica, in modo tale che i servizi NoSQL siano accessibili alla maggior parte dei sistemi operativi.

Storia

Il termine NoSQL è stato utilizzato da Carlo Strozzi nel 1998 per denominare il suo leggero database relazionale open source Strozzi NoSQL che non esponeva l' interfaccia SQL ( Structured Query Language ) standard, ma era ancora relazionale. Il suo RDBMS NoSQL è distinto dal concetto generale di database NoSQL intorno al 2009. Strozzi suggerisce che, poiché l'attuale movimento NoSQL "si discosta del tutto dal modello relazionale, avrebbe dovuto essere chiamato più appropriatamente 'NoREL'", riferendosi a "non relazionale".

Johan Oskarsson, allora sviluppatore di Last.fm , ha reintrodotto il termine NoSQL all'inizio del 2009 quando ha organizzato un evento per discutere di " database non relazionali distribuiti open source ". Il nome ha tentato di etichettare l'emergere di un numero crescente di datastore non relazionali e distribuiti, inclusi cloni open source di Bigtable / MapReduce di Google e DynamoDB di Amazon .

Tipi ed esempi

Esistono vari modi per classificare i database NoSQL, con diverse categorie e sottocategorie, alcune delle quali si sovrappongono. Quella che segue è una classificazione di base per modello di dati, con esempi:

Una classificazione più dettagliata è la seguente, basata su quella di Stephen Yen:

Tipo Esempi notevoli di questo tipo
Cache di valori-chiave Apache Ignite , Couchbase , Coherence , eXtreme Scale , Hazelcast , Infinispan , Memcached , Redis , Velocity
Negozio di valori-chiave Azure Cosmos DB , ArangoDB , Aerospike , Couchbase , Redis
Archivio chiave-valore (eventualmente coerente) Azure Cosmos DB , database Oracle NoSQL , Dynamo , Riak , Voldemort
Negozio chiave-valore (ordinato) FoundationDB , InfinityDB , LMDB , MemcacheDB
Negozio di tuple Fiume Apache , GigaSpaces
Database degli oggetti Oggettività/DB , Perst , ZopeDB
Archivio documenti Azure Cosmos DB , ArangoDB , BaseX , Clusterpoint , Couchbase , CouchDB , DocumentDB , eXist-db , IBM Domino , MarkLogic , MongoDB , Qizx , RethinkDB , Elasticsearch
Negozio di colonne larghe Azure Cosmos DB , Amazon DynamoDB , Bigtable , Cassandra , Google Cloud Datastore , HBase , Hypertable , ScyllaDB
Database multimodello nativo ArangoDB , Azure Cosmos DB , OrientDB , MarkLogic

I database di correlazione sono indipendenti dal modello e, invece dell'archiviazione basata su righe o colonne, utilizzano l'archiviazione basata sul valore.

Negozio di valori-chiave

Articolo principale: database di valori-chiave

Gli archivi chiave-valore (KV) utilizzano l' array associativo (chiamato anche mappa o dizionario) come modello di dati fondamentale. In questo modello, i dati sono rappresentati come una raccolta di coppie chiave-valore, in modo tale che ogni possibile chiave appaia al massimo una volta nella raccolta.

Il modello chiave-valore è uno dei modelli di dati non banali più semplici e spesso vengono implementati modelli di dati più ricchi come estensione di esso. Il modello chiave-valore può essere esteso a un modello ordinato in modo discreto che mantiene le chiavi in ordine lessicografico . Questa estensione è potente dal punto di vista computazionale, in quanto può recuperare in modo efficiente intervalli di chiavi selettivi .

Gli archivi chiave-valore possono utilizzare modelli di coerenza che vanno dalla coerenza finale alla serializzabilità . Alcuni database supportano l'ordinamento delle chiavi. Esistono varie implementazioni hardware e alcuni utenti archiviano i dati in memoria (RAM), mentre altri su unità a stato solido (SSD) o dischi rotanti (noti anche come unità disco rigido (HDD)).

Archivio documenti

Articoli principali: database orientato ai documenti e database XML

Il concetto centrale di un archivio di documenti è quello di "documento". Sebbene i dettagli di questa definizione differiscano tra i database orientati ai documenti, tutti presuppongono che i documenti incapsulano e codifichino dati (o informazioni) in alcuni formati o codifiche standard. Le codifiche in uso includono XML, YAML e JSON e forme binarie come BSON . I documenti vengono indirizzati nel database tramite una chiave univoca che rappresenta quel documento. Un'altra caratteristica distintiva di un database orientato ai documenti è un'API o un linguaggio di query per recuperare i documenti in base al loro contenuto.

Diverse implementazioni offrono diversi modi di organizzare e/o raggruppare i documenti:

  • Collezioni
  • tag
  • Metadati non visibili
  • Gerarchie di directory

Rispetto ai database relazionali, le raccolte possono essere considerate analoghe a tabelle e documenti analoghi a record. Ma sono diversi: ogni record di una tabella ha la stessa sequenza di campi, mentre i documenti di una raccolta possono avere campi completamente diversi.

Grafico

Articolo principale: database grafico

I database grafici sono progettati per dati le cui relazioni sono ben rappresentate come un grafo costituito da elementi collegati da un numero finito di relazioni. Esempi di dati includono relazioni sociali, collegamenti di trasporto pubblico, mappe stradali, topologie di rete, ecc.

Database grafici e loro linguaggio di interrogazione
Nome Le lingue) Appunti
AllegroGraph SPARQL RDF triplo negozio
Amazon Nettuno Gremlin , SPARQL Database grafico
Arango DB AQL, JavaScript , GraphQL Documento DBMS multi-modello , database grafico e archivio chiave-valore
Azure Cosmos DB Gremlin Database grafico
DEX/Sparksee C++ , Java , C# , Python Database grafico
FlockDB Scala Database grafico
IBM DB2 SPARQL Triplo archivio RDF aggiunto in DB2 10
InfiniteGraph Giava Database grafico
MarkLogic Java , JavaScript , SPARQL , XQuery Database di documenti multi-modello e triplo archivio RDF
Neo4j cifrario Database grafico
OpenLink Virtuoso C++ , C# , Java , SPARQL Middleware e motore di database ibrido
Oracolo SPARQL 1.1 RDF triple store aggiunto in 11g
OrienteDB Java , SQL Documento multi-modello e database grafico
GUFO Java , SPARQL 1.1 RDF triplo negozio
Senso del Profium Java , SPARQL RDF triplo negozio
Sqrrl Enterprise Giava Database grafico

Database degli oggetti

Articolo principale: database di oggetti

tabulare

Negozio di tuple

Database del negozio triplo/quadruplo (RDF)

Articoli principali: Triplestore e Named graph

Ospitato

Database multivalore

Database multimodello

Prestazione

Le prestazioni dei database NoSQL vengono generalmente valutate utilizzando la metrica del throughput , che viene misurata come operazioni/secondo. La valutazione delle prestazioni deve prestare attenzione ai benchmark giusti come le configurazioni di produzione, i parametri dei database, il volume di dati previsto e i carichi di lavoro degli utenti simultanei.

Ben Scofield ha valutato diverse categorie di database NoSQL come segue:

Modello di dati Prestazione Scalabilità Flessibilità Complessità Funzionalità
Negozio di valori-chiave alto alto alto nessuno variabile (nessuna)
Negozio a colonne alto alto moderare basso minimo
Negozio orientato ai documenti alto variabile (alto) alto basso variabile (basso)
Database grafico variabile variabile alto alto teoria dei grafi
Database relazionale variabile variabile basso moderare algebra relazionale

I confronti di prestazioni e scalabilità vengono generalmente eseguiti utilizzando il benchmark YCSB .

Gestione dei dati relazionali

Poiché la maggior parte dei database NoSQL non è in grado di eseguire join nelle query, lo schema del database generalmente deve essere progettato in modo diverso. Esistono tre tecniche principali per la gestione dei dati relazionali in un database NoSQL. (Vedi tabella Supporto Join e ACID per database NoSQL che supportano join.)

Query multiple

Invece di recuperare tutti i dati con una query, è comune eseguire diverse query per ottenere i dati desiderati. Le query NoSQL sono spesso più veloci delle query SQL tradizionali, quindi il costo di query aggiuntive potrebbe essere accettabile. Se fosse necessario un numero eccessivo di query, uno degli altri due approcci è più appropriato.

Caching, replica e dati non normalizzati

Invece di archiviare solo chiavi esterne, è comune archiviare valori esterni effettivi insieme ai dati del modello. Ad esempio, ogni commento del blog potrebbe includere il nome utente oltre a un ID utente, fornendo così un facile accesso al nome utente senza richiedere un'altra ricerca. Tuttavia, quando un nome utente cambia, ora dovrà essere modificato in molti punti del database. Quindi questo approccio funziona meglio quando le letture sono molto più comuni delle scritture.

Dati di nidificazione

Con i database di documenti come MongoDB è comune inserire più dati in un numero inferiore di raccolte. Ad esempio, in un'applicazione di blogging, si potrebbe scegliere di memorizzare i commenti all'interno del documento del post del blog in modo che con un singolo recupero si ottengano tutti i commenti. Pertanto, in questo approccio, un singolo documento contiene tutti i dati necessari per un'attività specifica.

ACID e unisciti al supporto

Un database è contrassegnato come supporto delle proprietà ACID (atomicità, consistenza, isolamento, durata) o operazioni di join se la documentazione per il database fa tale affermazione. Tuttavia, ciò non significa necessariamente che la funzionalità sia completamente supportata in modo simile alla maggior parte dei database SQL.

Banca dati ACIDO si unisce
Aerospike sì No
Apache si accende sì sì
Arango DB sì sì
divano sì sì
CouchDB sì sì
Db2 sì sì
InfinityDB sì No
LMDB sì No
MarkLogic sì sì
MongoDB sì sì
OrienteDB sì sì

Guarda anche

Riferimenti

Ulteriori letture

link esterno