Casi d’uso per NoSQL

NoSQL ha ricevuto molta attenzione nel nostro settore di recente. Sono davvero interessato a quali sono i pensieri delle persone sui casi d’uso migliori per il loro uso rispetto all’archiviazione di database relazionale. Cosa dovrebbe spingere 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 avere la massima copertura per quanto riguarda lo sviluppo di PHP e questo è il mio objective.

Ti prometti solo che non tenterai mai di mappare un modello di dati relazionali a un database NoSQL come MongoDB o CouchDB … Questo è l’errore più comune che gli sviluppatori commettono quando valuta la tecnologia emergente.

Questo approccio è analogo a prendere un’auto e cercare di usarla per tirare il tuo carrello lungo la strada come un cavallo.

È una reazione naturale dovuta all’esperienza di tutti, naturalmente, ma il vero valore nell’utilizzo di un database di documenti è la possibilità di semplificare la tua datamodel e minimizzare la tua sofferenza come sviluppatore. Il tuo codebase si restringerà, i tuoi bug saranno meno numerosi e più facili da trovare, le prestazioni saranno fantastiche e la scala sarà molto più semplice.

Essendo un fondatore di Joomla, sono prevenuto 🙂 ma provenendo dallo spazio CMS, qualcosa come MongoDB è un proiettile d’argento dato che il contenuto mappa in modo molto naturale per documentare i sistemi.

Un altro ottimo caso per MongoDB è l’analisi in tempo reale, poiché MongoDB ha prestazioni e scalabilità molto elevate, in particolare per quanto riguarda la concorrenza. Esistono casi di studio sul sito MongoDB.org che dimostrano tali attributi.

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

Alcuni grandi casi d’uso – per MongoDB comunque – sono menzionati sul sito MongoDB. Gli esempi forniti sono analisi in tempo reale, registrazione e ricerca full-text. Questi articoli valgono tutti la pena di leggere http://www.mongodb.com/use-cases

C’è anche una bella recensione 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 sui vari data store (noti anche come 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 ciò che riguarda l’usabilità. Gli archivi di documenti sono più semplici da utilizzare quando le unità di dati atomici sono simili ai documenti, perché è banale serializzare da e verso gli oggetti. È solo più divertente, e questo è un fattore importante per progetti personali o collaterali.

Ho usato NoSQL DB per un po ‘ora, 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 , specialmente quando i dati sono 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 importante per importare e aggiornare i dati JSON nel database; per esempio usando l’utility mongoimport riga di mongoimport

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

Ad esempio, utilizzando il framework di aggregazione :

 $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 filtri dynamicmente utilizzando le strutture di dati php ed evitare la noiosa concatenazione di stringhe per build le nostre query. Con questo approccio aggiungere / rimuovere filtri dynamicmente è facile come aggiungere / rimuovere elementi da un array

Un altro grande vantaggio deriva dal fatto che una soluzione come questa è probabilmente più veloce dell’utilizzo di un database relazionale , in cui dobbiamo creare 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 utilizzare la ridondanza per archiviare i dati denormalizzati nelle raccolte. Poiché leggiamo solo dati, non dobbiamo preoccuparci di sincronizzare i dati denormalizzati tra gli aggiornamenti.

In questo modo possiamo concentrarci sull’archiviazione dei dati con ridondanza in un modo che si adatta bene alle nostre query , che si concentreranno sulle singole raccolte.

Sto solo scrivendo questo perché avevo letto qualcosa del genere qualche tempo fa, mi sarebbe stato risparmiato un po ‘di tempo per fare delle ricerche

Spero che possa essere utile a qualcuno

Consiglio vivamente questo discorso di Martin Fowler:

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

ABSTRACT: Martin fornisce una rapida introduzione ai database NoSQL: da dove provengono, alla natura dei modelli di dati che usano e al modo diverso in cui devi pensare alla coerenza. Da ciò illustra quali tipi di circostanze dovresti considerare di utilizzarli, perché non renderanno obsoleti i database relazionali e l’importante conseguenza della persistenza dei poliglotti.

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

Per prima cosa devi capire la teoria della PAC (Consistenza, disponibilità e partizionamento, dove devi prendere due su tre) e il nostro caso d’uso aziendale. MongoDB soddisfa la coerenza e il partizionamento e il Couch DB soddisfa la disponibilità e il partizionamento.

I video di Edureka su YouTube relativi a 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-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (Questa presentazione supporta il tutorial video su youtube)

Per alcuni casi d’uso di cui hai bisogno, specialmente per le query analitiche, puoi eseguire query SQL su MongoDB con questo wrapper di Postgres.

Poiché ora sul mercato ci sono molti più database NoSQL che mai, ti suggerisco di dare un’occhiata al Gartner Magic Quadrant se stai cercando un database che sia anche ideale 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 sia ancora provato, ma non basato sulla versione mostrata nel rapporto (2.5.1) perché sono quasi 2 le revisioni dietro a dove CB Server è oggi, in prossimità del rilascio di 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ò agire come un puro archivio K / V, database Document Oriented con ridimensionamento multidimensionale, Memcached, cache-aside con persistenza e supporta SQL conforms ANSI 92 con join automatici, replica in cluster DR con la semplice pressione di un pulsante e ha anche un componente mobile integrato nell’ecosistema.

Se non altro, vale la pena di verificare gli ultimi benchmark:

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