Casi d'uso per NoSQL [chiuso]

Di recente NoSQL ha ricevuto molta attenzione nel nostro settore. Sono davvero interessato a ciò che la gente pensa sui migliori casi d'uso per il suo utilizzo rispetto all'archiviazione di database relazionali. Cosa dovrebbe indurre uno sviluppatore a pensare che determinati set di dati siano più adatti a una soluzione NoSQL. Sono particolarmente interessato a MongoDB e CouchDB in quanto sembrano ottenere la massima copertura per quanto riguarda lo sviluppo di PHP e questo è il mio obiettivo.

Promettiti solo che non proverai mai a mappare un modello di dati relazionali su un database NoSQL come MongoDB o CouchDB ... Questo è l'errore più comune che gli sviluppatori fanno quando valutano la tecnologia emergente.

Questo approccio è analogo a prendere un'auto e provare a usarla per tirare il carrello lungo la strada come un cavallo.

È una reazione naturale dovuta naturalmente all'esperienza di tutti, ma il vero valore nell'uso di un database di documenti è la possibilità di semplificare il modello di dati e ridurre al minimo la sofferenza come sviluppatore. La tua base di codice si ridurrà, i tuoi bug saranno meno e più facili da trovare, le prestazioni saranno fantastiche e la scala sarà molto più semplice.

Come fondatore di Joomla sono di parte :-) ma proveniente dallo spazio CMS, qualcosa come MongoDB è un proiettile d'argento poiché i contenuti vengono mappati in modo molto naturale ai sistemi di documentazione.

Un altro ottimo caso per MongoDB è l'analisi in tempo reale, in quanto MongoDB ha prestazioni e dimensioni molto forti, in particolare per quanto riguarda la concorrenza. Esistono casi studio sul sito Web MongoDB.org che dimostrano tali attributi.

Concordo con l'idea che ogni database abbia i propri obiettivi e casi d'uso; prendere di conseguenza lo scopo di ciascun database per la valutazione.

Alcuni ottimi casi d'uso - comunque per MongoDB - sono menzionati sul sito MongoDB. Gli esempi forniti sono analisi in tempo reale, registrazione e ricerca full-text. Questi articoli meritano tutti una lettura http://www.mongodb.com/use-cases

C'è anche un ottimo articolo su quale database NoSQL è più adatto a quale tipo di progetto: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Suggerirei questo articolo di Rick Cattell sugli archivi di dati vari (aka NoSQL), le loro differenze e alcuni dei loro casi d'uso: http://www.cattell.net/datastores/index.html

Quello che mi piace di NoSQL non ha nulla a che fare con le prestazioni e tutto con l'usabilità. Gli archivi documenti sono più facili da utilizzare quando le tue unità di dati atomici sono simili a documenti, perché è banale serializzare da e verso gli oggetti. È solo più divertente e questo è un fattore importante per i progetti personali o collaterali.

Sto usando NoSQL DB da un po 'di tempo, e questo è il mio contributo all'argomento:

Un ottimo caso d'uso per un database NoSQL è un'applicazione per la generazione di statistiche e / o report , in particolare quando i dati vengono forniti da una fonte di terze parti.

In una situazione del genere, un database NoSQL può essere un'ottima scelta

Consideriamo, ad esempio, MongoDB :

Una volta che hai i tuoi dati in JSON, (potrebbe provenire da un'API di terze parti o essere esportato da un'applicazione sql) in MongoDB è piuttosto semplice importare e aggiornare i dati JSON nel database; ad esempio utilizzando l' mongoimportutilità della riga di comando

A questo punto è molto semplice creare query dinamiche con filtri e raggruppamenti, che ben si adattano a questo tipo di applicazione.

Ad esempio, utilizzando Aggregation Framework :

$pipeline = [];

//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ]  ]  ];

//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
    $pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];    

//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];

return $collection->aggretate( $pipeline );

Vorrei sottolineare la facilità con cui possiamo aggiungere / rimuovere dinamicamente i filtri utilizzando strutture di dati php ed evitando noiose concatenazioni di stringhe per costruire le nostre query. Con questo approccio aggiungere / rimuovere filtri dinamicamente è facile come aggiungere / rimuovere elementi da un array

Un altro grande vantaggio deriva dal fatto che una soluzione come questa è probabilmente più veloce rispetto all'utilizzo di un database relazionale , in cui dobbiamo fare join con tabelle diverse per ottenere tutti i dati di cui abbiamo bisogno

Inoltre, questo caso d'uso è ottimale perché evita tutti i limiti principali di un database NoSQL:

• Mancanza di transazioni: l'applicazione non esegue scritture ma solo letture, quindi non abbiamo bisogno di transazioni

• Mancanza di join tra le tabelle: non abbiamo bisogno di join, poiché possiamo usare la ridondanza per archiviare i nostri dati denormalizzati nelle raccolte. Dato che leggiamo solo i dati, non dobbiamo preoccuparci di sincronizzare i dati denormalizzati tra gli aggiornamenti.

In questo modo possiamo concentrarci sulla memorizzazione dei dati con ridondanza in un modo che si adatta bene alle nostre query , che si concentrerà su singole raccolte.

Sto solo scrivendo questo perché se avessi letto qualcosa del genere qualche volta fa, mi sarebbe stato risparmiato un po 'di tempo per fare ricerche

Spero che sia utile a qualcuno

Consiglio vivamente questo discorso di Martin Fowler:

https://www.youtube.com/watch?v=qI_g07C_Q5I

RIASSUNTO: Martin offre una rapida introduzione ai database NoSQL: da dove provengono, la natura dei modelli di dati che usano e il diverso modo in cui devi pensare alla coerenza. Da ciò delinea che tipo di circostanze dovresti considerare di usarle, perché non renderanno obsoleti i database relazionali e le importanti conseguenze della persistenza dei poliglotti.

Disegna una bella immagine di ciò che è NoSQL, delle diverse categorie e delle cose che tutti devono capire quando provengono dal mondo dei database relazionali. Saluti.

Per prima cosa devi capire la teoria della PAC (coerenza, disponibilità e partizionamento, in cui devi raccogliere due di tre) e il nostro caso d'uso aziendale. MongoDB soddisfa Coerenza e Partizionamento e Couch DB soddisfa Disponibilità e Partizionamento.

I video Edureka su YouTube riguardanti NoSQL sono alcuni dei migliori tutorial video.

https://www.youtube.com/watch?v=gJFG04Sy6NY

https://www.youtube.com/watch?v=KSq6tMMXZ8s

https://www.youtube.com/watch?v=3z1KFA2qcSo

Buone presentazioni sono disponibili su slideshare.net

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when?qid=3bb9f7f6-a53d-41b1-8403-cd6f181d0ca7&v=qf1&b=&from_search=1

http://www.slideshare.net/EdurekaIN/no-sql-d database-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (Questa presentazione supporta video tutorial su YouTube)

Per alcuni casi d'uso necessari, in particolare per le query analitiche è possibile eseguire query SQL su MongoDB con questo wrapper di Postgres.

Poiché ora sul mercato ci sono molti più database NoSQL che mai, suggerisco di dare un'occhiata al Quadrante magico di Gartner se stai cercando un database che sarà anche ottimo per le applicazioni aziendali basate su supporto, espandibilità, gestione e costo.

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

Vorrei suggerire Couchbase a chiunque non l'abbia ancora provato, ma non in base alla versione mostrata nel rapporto (2.5.1) perché ci sono quasi 2 revisioni dietro a dove si trova CB Server oggi, vicino alla versione 4.0 in 2H15 .

http://www.couchbase.com/coming-in-couchbase-server-4-0

L'altra parte di Couchbase come fornitore / prodotto è che si tratta di un tipo di DB multiuso. Può fungere da puro archivio K / V, Document Oriented Database con ridimensionamento multidimensionale, Memcached, cache-side con persistenza e supporta SQL conforme ANSI 92 con join automatici, replica in cluster DR con la semplice pressione di un pulsante e ha persino un componente mobile incorporato nell'ecosistema.

Se non altro, vale la pena dare un'occhiata agli ultimi benchmark:

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html