L'uso dei database NoSQL non è pratico per i set di dati di grandi dimensioni in cui è necessario eseguire una ricerca per contenuto?

Anche se sono d'accordo con la tua premessa che NoSQL non è una panacea per tutti i problemi del database, penso che tu abbia frainteso un punto chiave.

In NoSQL database you have only one criterion you can search for effectively - the key.

Questo chiaramente non è vero.

Ad esempio MongoDB supporta gli indici. (dal link )

Indexes support the efficient execution of queries in MongoDB. Without indexes, MongoDB must perform a collection scan, i.e. scan every document in a collection, to select those documents that match the query statement. If an appropriate index exists for a query, MongoDB can use the index to limit the number of documents it must inspect.

Indexes are special data structures [1] that store a small portion of the collection’s data set in an easy to traverse form. The index stores the value of a specific field or set of fields, ordered by the value of the field. The ordering of the index entries supports efficient equality matches and range-based query operations. In addition, MongoDB can return sorted results by using the ordering in the index.

Come fa couchbase (dal link )

Couchbase views enable indexing and querying of data.

A view creates an index on the data according to the defined format and structure. The view consists of specific fields and information extracted from the objects in Couchbase.

In effetti qualsiasi cosa che si definisce un database NoSQL piuttosto che un archivio di valori-chiave dovrebbe davvero supportare qualche tipo di schema di indicizzazione.

In effetti, è spesso la flessibilità di questi schemi di indice che rende lustro NoSQL. A mio parere, il linguaggio utilizzato per definire gli indici NoSQL è spesso più espressivo o naturale di SQL e, dato che abitualmente vivono al di fuori della tabella, non è necessario modificare gli schemi di tabella per supportarli. (Per non dire che non si possono fare cose simili in SQL, ma a me sembra che ci sia molto più coinvolgimento del cerchio).

In generale, se il tuo flusso di lavoro è perfetto per le query sui database relazionali, troverai i database relazionali come l'approccio più efficiente. È un tipo 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 le attività di programmazione relazionale di mio potrebbero essere state fatte usando NoSQL con quasi lo stesso livello di efficienza, se non di più. Tuttavia, questa è una dichiarazione molto soggettiva basata su un'esperienza ristretta.

Ho la sensazione che gran parte della vendita dell'approccio NoSQL derivi dall'assunzione di grandi database. Più grande è il database, più devi ottimizzare il tuo flusso di lavoro per supportare i set di dati più grandi. NoSQL sembra essere più bravo a sostenere questo sforzo di toelettatura. Quindi, più grande è il database, più importanti sono le funzionalità di NoSQL.

Per utilizzare l'esempio, l'interrogazione SQL per paese è tanto lenta quanto la scansione NoSQL di tutti gli utenti, a meno che tu non abbia detto esplicitamente a SQL di indicizzare la tabella users 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 la mantiene.

La differenza? I motori SQL avevano il concetto di indicizzare la tabella incorporata. Ciò significa che devi fare meno lavoro (tutto quello che dovevi fare era aggiungere un indice alla tabella). Tuttavia, significa anche che hai meno controllo. Per la maggior parte dei casi, tale perdita di controllo è accettabile, in cambio del motore SQL che esegue il lavoro per conto dell'utente. Tuttavia, in enormi dataset, è possibile che si desideri un modello di coerenza diverso rispetto al tipico modello ACID SQL. Si consiglia di utilizzare il modello BASE che supporta la coerenza finale. Questo potrebbe essere molto difficile in SQL, perché il motore SQL sta facendo il lavoro per te, quindi deve essere fatto dalle regole del motore SQL. In NoSQL, questi layer sono in genere esposti, permettendoti di hackerarli.

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

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

Nessuno sano di mente affermerebbe che gli archivi di valori-chiave possono sostituire i database relazionali in generale. Tuttavia, ci possono essere casi d'uso particolari in cui l'archivio dei valori-chiave è una buona scelta. Gli archivi di valori-chiave vengono spesso utilizzati per la memorizzazione nella cache, poiché in genere si memorizzano gli elementi nella cache in base all'ID, ma non è necessario eseguire query ad-hoc sulle cache. Ad esempio, il sito Stackoverflow stesso utilizza Redis (un valore-chiave db) estensivamente , 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 memorizzare e cercare usando una singola chiave. Altrimenti usa un diverso tipo di database. E se sei in dubbio, usa un database relazionale, poiché questo è il tipo più versatile di database, mentre i database NoSQL sono spesso ottimizzati per 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ù adattarne una copia su un singolo server. Quindi inizi a correre in tutti i tipi di problemi interessanti. Come dividi le tue tabelle in modo che la maggior parte delle tue query possano essere eseguite su un singolo server? Quante copie dei dati fai? Come gestisci le incongruenze tra queste copie? Come mantenere i dati di un utente in un data center relativamente vicino a lui o a lei geograficamente?

Questi obiettivi spesso sono 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 che quando si ha a che fare con questo tipo di scala, si inizia a inventare soluzioni, aggiungere ridondanze e imporre restrizioni che assomigliano molto a un database NoSQL. Se puoi adattare tutti i tuoi dati su una scatola, ottieni solo le restrizioni e non hai bisogno dei benefici.

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

Si tratta di ammettere che non è possibile avere un database in scala che sia sempre coerente e supporti le 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 scaduti.

Ad esempio:

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

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

Quindi .....

Se un singolo database relazionale normale è in grado di contenere tutti i tuoi dati ed elaborare ogni transazione abbastanza rapidamente che il blocco non impedisce al tuo sistema di svolgere un lavoro utile, un database relazionale è l'opzione migliore.

Ma non appena devi iniziare a pensare all'utilizzo di più di un database relazionale, o dividere le transazioni per evitare errori di blocco, stai andando giù per la strada di dover affrontare il tipo di problemi che si ottengono quando si utilizza "NoSQL "Database.

Poiché i database "NoSQL" non nascondono questi problemi, possono diventare l'opzione migliore quando si aumenta il livello di 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 caching - quindi devi essere MOLTO grande prima di dover usare NoSQL per archiviare i tuoi dati.

Relational Databases are optimized to search for any value in the datarow effectively.

Non confondere la capacità 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 indici che includono tutti i campi, ma poi hai solo ostacolato la possibilità di apportare modifiche che richiedono la modifica dell'indice (inserimenti, aggiornamenti, eliminazioni). Tu (o il tuo DBA) devi comprendere i dati, l'utilizzo, i colli di bottiglia ecc.

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

Chiaramente il concetto NoSQL copre una varietà di approcci diversi nell'organizzazione dei dati su disco, in memoria e nell'esposizione attraverso un linguaggio di query (alcuni sono persino simili a quelli di 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 se tutto va bene è possibile coprire una dozzina di esigenze diverse con solo poche soluzioni diverse, non si vorrebbe gestire una dozzina di sistemi diversi.

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

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

Per le relazioni gerarchiche è molto più facile gestirle quando è possibile visualizzarle. Per la maggior parte dei dati letti, è più facile modificare JSON piuttosto che scrivere un'istruzione UPDATE in molti casi. Non accetta un programmatore, in realtà, per modificare JSON. E SQL ti fornisce righe e colonne, che dovrai poi mappare in una sorta di struttura a oggetti.

Ottieni anche un aumento delle prestazioni perché non stai unendo 10-20 tavoli a query complesse. Le visualizzazioni di Couchdb sono molto veloci perché la javascript su cui si basano non viene eseguita al momento della query.

La maggior parte dei programmatori comprende Javascript e la maggior parte dei programmatori ha a che fare con SQL occasionalmente.

In Couchdb, una vista può essere pensata come un riassunto di un documento JSON. Il modo in cui i dati della vista sono strutturati dipende da te (non sei vincolato dalla gerarchia originale).

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

Nota che non esiste una chiara "normalizzazione" che può essere applicata (anche se evitare la duplicazione dei dati è un obiettivo degno), e c'è una strategia di aggiornamento essenzialmente e "ottimistica" simile al blocco ottimistico.