L'uso dei database NoSQL non è pratico per grandi set di dati in cui è necessario cercare per contenuto?

Ho imparato a conoscere i database NoSQL da una settimana.

Comprendo davvero i vantaggi dei database NoSQL e dei molti casi d'uso per cui sono perfetti.

Ma spesso le persone scrivono i loro articoli come se NoSQL potesse sostituire i database relazionali. E c'è il punto in cui non riesco a capire:

I database NoSQL sono (spesso) archivi di valori-chiave.

Ovviamente è possibile archiviare tutto in un archivio di valori-chiave (codificando i dati in JSON, XML, qualunque cosa), ma il problema che vedo è che è necessario ottenere una quantità di dati che corrisponda a un criterio specifico, in molti casi d'uso. In un database NoSQL hai solo un criterio che puoi cercare in modo efficace: la chiave. I database relazionali sono ottimizzati per cercare efficacemente qualsiasi valore nella riga di dati.

Quindi i database NoSQL non sono davvero una scelta per i dati persistenti che devono essere cercati dal loro contenuto. O ho frainteso qualcosa?

Un esempio:

È necessario archiviare i dati utente per un negozio online.

In un database relazionale memorizzi ogni utente come una riga nella userstabella, con un ID, il nome, il suo paese, ecc.

In un database NoSQL è necessario memorizzare ogni utente con il suo ID come chiave e tutti i suoi dati (codificati in JSON, ecc.) Come valore.

Quindi, se hai bisogno di ottenere tutti gli utenti da un paese specifico (per qualche motivo i ragazzi del marketing devono sapere qualcosa su di loro), è facile farlo nel database relazionale, ma non molto efficace nel database NoSQL, perché devi ottenere ogni utente, analizzare tutti i dati e filtrare.

Non dico che è impossibile , ma diventa molto più complicato e credo che non sia efficace se si desidera cercare nei dati delle voci NoSQL.

È possibile creare una chiave per ogni Paese che memorizza le chiavi di ogni utente che vive in questo Paese e ottenere gli utenti di un Paese specifico ottenendo tutte le chiavi che sono depositate nella chiave di questo Paese. Ma penso che questa tecnica renda un set di dati complesso ancora più complesso: è più difficile da implementare e non efficace come interrogare un database SQL. Quindi penso che non sia un modo che useresti in produzione. O è?

Non sono davvero sicuro di aver frainteso qualcosa o di aver trascurato alcuni concetti o best practice per gestire tali casi d'uso. Forse potresti correggere le mie dichiarazioni e rispondere alle mie domande.

Mentre sono d'accordo con la tua premessa che NoSQL non è una panacea per tutti i guai del database, penso che tu fraintenda un punto chiave.

Nel database NoSQL hai solo un criterio che puoi cercare in modo efficace: la chiave.

Questo chiaramente non è vero.

Ad esempio MongoDB supporta gli indici. (da https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Gli indici supportano l'esecuzione efficiente di query in MongoDB. Senza indici, MongoDB deve eseguire una scansione della raccolta, ovvero scansionare ogni documento in una raccolta, per selezionare quei documenti che corrispondono all'istruzione della query. Se esiste un indice appropriato per una query, MongoDB può utilizzare l'indice per limitare il numero di documenti che deve ispezionare.

Gli indici sono strutture di dati speciali [1] che memorizzano una piccola parte del set di dati della raccolta in una forma facile da attraversare. L'indice memorizza il valore di un campo o set di campi specifici, ordinati in base al valore del campo. L'ordinamento delle voci di indice supporta corrispondenze di uguaglianza efficienti e operazioni di query basate sull'intervallo. Inoltre, MongoDB può restituire risultati ordinati utilizzando l'ordinamento nell'indice.

Come fa couchbase (da http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Le viste Couchbase consentono l'indicizzazione e l'interrogazione dei dati.

Una vista crea un indice sui dati in base al formato e alla struttura definiti. La vista è composta da campi specifici e informazioni estratte dagli oggetti in Couchbase.

In effetti, tutto ciò che si definisce un database NoSQL piuttosto che un archivio di valori-chiave dovrebbe davvero supportare un qualche tipo di schema di indicizzazione.

In effetti, è spesso la flessibilità di questi schemi di indice che fa brillare NoSQL. A mio avviso, il linguaggio utilizzato per definire gli indici NoSQL è spesso più espressivo o naturale di SQL e, poiché di solito vivono al di fuori della tabella, non è necessario modificare gli schemi della tabella per supportarli. (Per non dire che non puoi fare cose simili in SQL, ma per me sembra che ci sia molto più salto del cerchio in questione).

In generale, se il flusso di lavoro è una corrispondenza perfetta per le query sui database relazionali, i database relazionali rappresentano l'approccio più efficiente. È un tipo di tautologico, ma è vero.

L'affermazione che molti sostenitori di NoSQL farebbero è che molti flussi di lavoro sono stati effettivamente massaggiati in una forma relazionale e sarebbero stati più efficaci prima di tale massaggio. La validità di questa affermazione è complicata da accertare. Chiaramente ci sono lavori che sono molto ben descritti dalle query SQL. Posso dire dalla mia esperienza che i miei particolari compiti di programmazione relazionale avrebbero potuto essere eseguiti usando NoSQL con quasi lo stesso livello di efficienza, se non di più. Tuttavia, questa è un'affermazione molto soggettiva basata su un'esperienza ristretta.

Ho la sensazione che gran parte della vendita dell'approccio NoSQL provenga dall'ipotesi di database di grandi dimensioni. Più è grande il database, più è necessario governare il flusso di lavoro per supportare set di dati più grandi. NoSQL sembra essere migliore nel supportare questo sforzo di toelettatura. Pertanto, più grande è il database, più importanti possono essere le funzionalità di NoSQL.

Per usare l'esempio, nelle query SQL per paese è altrettanto lento quanto la scansione NoSQL di tutti gli utenti, a meno che non sia stato esplicitamente detto a SQL di indicizzare la userstabella per paese. NoSQL può fare lo stesso, dove si crea una raccolta di valori-chiave ordinata che è l'indice (proprio come fa SQL sotto il cofano) e lo mantiene.

La differenza? I motori SQL avevano il concetto di indicizzare la tabella integrata. Ciò significa che devi fare meno lavoro (tutto ciò che dovevi fare era aggiungere un indice alla tabella). Tuttavia, significa anche che hai meno controllo. Nella maggior parte dei casi, tale perdita di controllo è accettabile, in cambio del motore SQL che fa il lavoro per te. Tuttavia, in enormi set di dati, potrebbe essere necessario un modello di coerenza diverso rispetto al tipico modello ACID SQL. È possibile che si desideri utilizzare il modello BASE che supporta l'eventuale coerenza. Questo potrebbe essere molto difficile in SQL, perché il motore SQL sta facendo il lavoro per te, quindi deve essere fatto secondo le regole del motore SQL. In NoSQL, questi livelli sono in genere esposti, permettendoti di hackerarli.

NoSQL è un termine piuttosto vago, poiché sostanzialmente copre tutti i sistemi di database che non sono relazionali.

Quello che descrivi è un archivio di valori-chiave , che è una specie di database in cui un blob di dati è archiviato sotto una chiave e può essere rapidamente cercato se conosci la chiave. Questi database sono incredibilmente veloci se conosci la chiave esatta, ma come dici tu stesso, se devi cercare o filtrare su più proprietà sui dati, sarà lento e ingombrante.

Nessuno nella loro mente corretta affermerebbe che gli archivi di valori-chiave possono sostituire i database relazionali in generale. Tuttavia, potrebbero esserci casi d'uso particolari in cui l'archivio valori-chiave è adatto. Gli archivi di valori-chiave vengono spesso utilizzati per la memorizzazione nella cache, poiché in genere si memorizzano nella cache elementi per ID, ma non è necessario eseguire query ad hoc sulle cache. Ad esempio, il sito Stackoverflow stesso utilizza Redis (un valore-chiave db) ampiamente , ma solo per la cache di output. I dati canonici sottostanti sono ancora persistenti in un database relazionale.

Quindi la risposta è abbastanza ovvia: usa un archivio di valori-chiave se hai solo bisogno di archiviare e cercare usando una sola chiave. Altrimenti usa un diverso tipo di database. E in caso di dubbi, utilizzare un database relazionale, poiché questo è il tipo di database più versatile, mentre i database NoSQL sono spesso ottimizzati verso casi d'uso molto particolari.

Le tue affermazioni sui database relazionali sono tutte vere, fino al punto in cui hai così tanti dati che non puoi più inserirne una copia su un singolo server. Quindi inizi a imbatterti in tutti i tipi di problemi interessanti. Come dividere le tabelle in modo che la maggior parte delle query possano essere eseguite su un singolo server? Quante copie dei dati fai? Come gestite le incoerenze tra tali copie? Come conservate i dati di un utente in un data center relativamente vicino a lui o lei geograficamente?

Questi obiettivi sono spesso in conflitto tra loro. Molti utenti di Twitter seguono persone da tutto il mondo. Il database di Twitter dovrebbe essere geograficamente ottimizzato per leggere tweet o scrivere tweet?

Si scopre quando si affronta quel tipo di scala, si inizia a inventare soluzioni, aggiungere ridondanze e imporre restrizioni che assomigliano molto a un database NoSQL. Se riesci ad adattare tutti i tuoi dati in un'unica casella, otterrai solo le restrizioni e non avrai bisogno dei vantaggi.

I database NoSQL hanno ben poco a che fare con " No SQL".

Si tratta di ammettere che non è possibile avere un database su larga scala che sia sempre coerente e supporti transazioni complesse e abbia una durata.

In un normale database relazionale tutti gli indici vengono automaticamente aggiornati nell'ambito di una transazione, quindi possono essere utilizzati per qualsiasi query.

In un database NoSQL il programmatore è responsabile del mantenimento di molti indici e si presume che gli indici saranno sempre obsoleti.

Per esempio:

• Un indice di persone per codice fiscale può contenere alcune persone che non completano mai il processo di registrazione fiscale.
• Pertanto il codice che utilizza l'indice deve essere in grado di far fronte a una registrazione incompleta per le tasse
• Un'altra opzione è quella di avere momenti in cui una persona che è registrata per le tasse non è nell'indice. (Quindi il tuo progetto deve far fronte a non avere dati coerenti e decidere come i dati non saranno coerenti.)

Come un vero esempio, Amazon preferirebbe mostrarmi la descrizione non aggiornata di un libro piuttosto che ritardare la visualizzazione della pagina Web aspettando 106 computer per confermare che il blocco corretto è stato rimosso.

Perciò.....

Se un singolo database relazionale normale può contenere tutti i tuoi dati ed elaborare ogni transazione abbastanza rapidamente da impedire al blocco di svolgere un lavoro utile al tuo sistema, un database relazionale è l'opzione migliore.

Ma non appena si deve iniziare a pensare di utilizzare più di un database relazionale o di suddividere le transazioni per evitare errori di blocco, si procede sulla strada del dover affrontare il tipo di problemi che si verificano quando si utilizzano database "NoSQL".

Poiché i database "NoSQL" non nascondono questi problemi, possono diventare l'opzione migliore quando si scala un sistema. Ma ricorda che Stackoverflow utilizza ancora un database relazionale per archiviare tutti i suoi dati, con un uso limitato di NoSQL nel livello di memorizzazione nella cache - quindi devi essere MOLTO grande prima di essere costretto a usare NoSQL per archiviare i tuoi dati.

I database relazionali sono ottimizzati per cercare efficacemente qualsiasi valore nel datarow.

Non confondere la possibilità di cercare "qualsiasi" valore in una riga con "ogni" valore in una riga. Il modo più efficace per farlo richiede uno o più indici. Potresti avere degli indici che includano tutti i campi, ma poi hai solo ostacolato la possibilità di apportare modifiche che richiedono una modifica dell'indice (inserimenti, aggiornamenti, eliminazioni). Tu (o il tuo DBA) dovete comprendere i dati, l'uso, i colli di bottiglia ecc.

Ci sono già molte risposte, ma volevo solo aggiungere il mio riassunto.

Chiaramente il concetto NoSQL copre una varietà di approcci diversi nell'organizzazione dei dati su disco, in memoria e nell'esposizione tramite un linguaggio di query (alcuni sono persino simili a SQL!). Dal mio punto di vista la forza deriva da questa varietà di sistemi in modo da poter scegliere lo strumento migliore per il lavoro. Ma spero che tu possa soddisfare una dozzina di esigenze diverse con solo poche soluzioni diverse, non vorresti gestire una dozzina di sistemi diversi.

I database relazionali possono portarti molto lontano e sono una tecnologia collaudata, ma proprio come il database potresti voler scegliere il linguaggio di programmazione in base alle esigenze di ogni progetto (ma tenendo conto anche dell'esperienza del team).

Sto usando couchdb da due anni. Viene utilizzato principalmente per la gestione e la configurazione dei contenuti.

Per le relazioni gerarchiche sono molto più facili da gestire quando è possibile visualizzarle. Per la maggior parte dei dati di lettura, è più semplice modificare JSON che scrivere un'istruzione UPDATE in molti casi. In realtà, non è necessario che un programmatore modifichi JSON. E SQL ti dà righe e colonne, che devi quindi mappare in una sorta di struttura ad oggetti.

Ottieni anche un aumento delle prestazioni perché non stai unendo 10-20 tabelle per query complesse. Le viste Couchdb sono molto veloci perché i javascript su cui si basano non vengono eseguiti al momento della query.

La maggior parte dei programmatori capisce Javascript, e la maggior parte dei programmatori ha problemi con SQL di tanto in tanto.

In Couchdb, una vista può essere considerata come un estratto di un documento JSON. La struttura dei dati della vista dipende da te (non sei vincolato dalla gerarchia originale).

Non userei Couchdb per dati altamente transazionali, ma per dati semi-statici con una struttura di tipo esplosione di parti, è MOLTO più facile da lavorare rispetto a SQL.

Si noti, tuttavia, che non esiste una "normalizzazione" chiara che può essere applicata (sebbene evitare la duplicazione dei dati sia un obiettivo meritevole) e che esiste una strategia di aggiornamento essenzialmente e "ottimistica" simile al blocco ottimistico.