Se stai iniziando su un singolo server, molti vantaggi di NoSQL vanno fuori dalla finestra. I maggiori vantaggi del NoSQL più popolare sono l'alta disponibilità con meno tempi di fermo. Eventuali requisiti di coerenza possono portare anche a miglioramenti delle prestazioni. Dipende davvero dalle tue esigenze.
basati su documenti - Se i dati si inserisce bene in una manciata di piccoli secchi di dati, poi un database di documenti oriented. Ad esempio, su un sito di annunci abbiamo utenti, account e elenchi come dati principali. La maggior parte delle operazioni di ricerca e visualizzazione sono contro le sole liste. Con il database precedente dobbiamo eseguire quasi 40 operazioni di join per ottenere i dati per un singolo elenco. Con NoSQL è una singola query. Con NoSQL possiamo anche creare indici su dati annidati, di nuovo con risultati interrogati senza Joins. In questo caso, in realtà stiamo eseguendo il mirroring dei dati da SQL a MongoDB per scopi di ricerca e visualizzazione (ci sono altri motivi), con una strategia di migrazione a lungo termine su cui si sta lavorando ora. ElasticSearch, RethinkDB e altri sono anche ottimi database. RethinkDB richiede un approccio molto conservativo ai dati e l'indicizzazione immediata di ElasticSearch non è seconda a nessuno.
chiave-valore negozio - Caching è un eccellente caso d'uso qui, quando si esegue un mezzo per sito web ad alto volume in cui i dati sono per lo più leggere, una buona strategia di cache da solo può farti 4-5 volte degli utenti gestito da un singolo server.
Columnar - Cassandra in particolare può essere utilizzato per distribuire quantità significative di carico anche per ricerche a valore singolo. Il ridimensionamento di Cassandra è molto lineare rispetto al numero di server in uso. Ottimo per pesanti scenari di lettura e scrittura. Lo trovo meno prezioso per le ricerche dal vivo, ma molto buono quando si dispone di un carico elevato di MOLTO e occorre distribuire. Richiede molta più pianificazione e potrebbe non adattarsi alle tue esigenze. È possibile modificare le impostazioni per soddisfare le esigenze CAP e persino gestire la distribuzione su più data center nella casella.NOTA: la maggior parte delle applicazioni fa enfaticamente NON necessario questo livello di utilizzo. ElasticSearch potrebbe essere più adatto alla maggior parte degli scenari che considererebbero HBase/Hadoop o Cassandra.
Grafico - Non ho familiarità con i database di grafici, quindi non posso commentare qui.
Dato che si commenta in modo specifico su MongoDB rispetto a SQL ... anche se entrambi sono auto-shard. PostgreSQL in particolare ha fatto passi da gigante in termini di utilizzo dei dati non strutturati (tipi JSON/JSONB), per non parlare della potenza che puoi ottenere da qualcosa come PLV8, probabilmente è il più adatto a gestire i tipi di carichi che potresti gettare un negozio di documenti con i vantaggi di NoSQL. Dove capita di cadere è che la replica, il sharding e il failover sono imbullonati su soluzioni non proprio nella scatola.
Per carichi di piccole e medie dimensioni il sharding non è l'approccio migliore. La maggior parte degli scenari vengono letti principalmente in modo da avere un set di repliche in cui sono presenti nodi di lettura aggiuntivi, in genere è meglio quando si dispone di 3-5 server. MongoDB è ottimo in questo scenario, il nodo master è automaticamente selezionato e il failover è piuttosto veloce. L'unica stranezza che ho visto è quando Azure è andato giù verso la fine del 2014, e solo uno dei server è arrivato per primo, gli altri due erano quasi 40 minuti più tardi. Con la replica qualsiasi richiesta di lettura data può essere gestita interamente da un singolo server. Le tue strutture dati diventano più semplici e le tue probabilità di perdita dei dati sono ridotte.
Sempre nel mio esempio precedente, per un sito di annunci di medie dimensioni, la stragrande maggioranza dei dati appartiene a una singola raccolta ... viene cercata e visualizzata da quella raccolta. Con questo caso d'uso un archivio documenti funziona molto meglio dei dati strutturati/normalizzati. Il modo in cui gli oggetti sono memorizzati sono molto più vicini alla loro rappresentazione nell'applicazione. C'è meno di una disconnessione cognitiva e funziona semplicemente.
Il fatto è che le operazioni di JOIN SQL interrompono le prestazioni, soprattutto quando si aggregano i dati attraverso questi join. Per una singola query per un singolo utente va bene, anche con una dozzina di loro. Quando si arriva a decine di join con migliaia di utenti simultanei, inizia a crollare. A questo punto si hanno diverse scelte ...
Caching - caching è sempre un ottimo approccio, e meno spesso le modifiche dei dati, migliore è l'approccio. Questo può essere qualsiasi cosa, da un insieme di istanze di memcache/redis all'utilizzo di qualcosa come MongoDB, RethinkDB o ElasticSearch per contenere i record compositi. La sfida qui riguarda l'aggiornamento o l'invalidazione dei dati memorizzati nella cache.
Migrazione - la migrazione dei dati in un archivio dati che meglio rappresenta le esigenze può essere anche una buona idea. Se è necessario gestire enormi scritture o scenari di lettura molto massicci, nessun database SQL può tenere il passo. Potresti MAI gestire Facebook o Twitter su SQL.
una via di mezzo - Come avete bisogno di scala dipende da cosa si sta facendo e dove i vostri punti deboli sono da quale sarà la soluzione migliore per una data situazione. Molti sviluppatori e amministratori temono che i dati vengano scomposti in più punti, ma questa è spesso la migliore risposta. I tuoi dati analitici devono davvero essere nella stessa posizione dei dati operativi principali? Per questo motivo i tuoi accessi devono essere strettamente accoppiati? Stai facendo molte domande correlate? Dipende davvero.
opinioni personali Ahead
per me, mi piace la rete di sicurezza che fornisce SQL. Avere come archivio centrale per i dati principali è la mia prima scelta. Tendo a trattare gli RDBMS come memoria stupida, non mi piace essere legato a una determinata piattaforma. Sento che molte persone cercano di sovra-normalizzare i propri dati. Spesso aggiungo un campo XML o JSON a una tabella in modo da poter memorizzare ulteriori parti di dati senza sovraccaricare lo schema, in particolare se è improbabile che venga mai interrogato ... Avrò quindi proprietà nei miei oggetti nel codice dell'applicazione che conservare in quei campi. Un buon esempio potrebbe essere un pagamento ... se attualmente stai usando un sistema, o più sistemi (uno per CC insieme a Paypal, Google, Amazon, ecc.), I dettagli della transazione non influenzano davvero i tuoi record, perché creare 5+ tabelle per memorizzare questi dati dettagliati.
Quando i dati sono un adattamento naturale per un negozio di documenti, dico di andare ... se la maggior parte delle query riguarda qualcosa che si adatta meglio a un singolo record o raccolta, denormalizza. Avere questo come specchio per i tuoi dati primari è grandioso.
Per i dati pesanti per la scrittura, si desidera disporre di più sistemi in esecuzione ... Dipende in gran parte dalle esigenze dell'utente ... È necessaria una prestazione rapida con hot-query? Vai con ElasticSearch. Avete bisogno di una scala orizzontale massiccia assoluta, HBase o Cassandra.
La chiave da portare via qui non è aver paura di mischiarla ... non c'è davvero una taglia unica adatta a tutti. Per inciso, ritengo che se PostgreSQL offre una buona soluzione in scatola (per la versione open-source) anche solo per la replica e il failover automatico, si trovano in una posizione molto migliore rispetto alla maggior parte a quel punto.
Non mi sono davvero interessato, ma sento che dovrei menzionare che ci sono un certo numero di soluzioni SaaS e altri provider che offrono sistemi ibridi SQL. È possibile sviluppare a livello locale MySQL/MariaDB e distribuire su un sistema con SQL su un cluster di archiviazione distribuito. Continuo a ritenere che HBase o ElasticSearch siano migliori per la registrazione e i dati analitici, ma anche le soluzioni SQL sulle migliori sono convincenti.
Altro: http://www.mongodb.com/nosql-explained
Ciao. Sono davvero preoccupato per il tipo di avvio che sarebbe così veloce che non avrebbero nemmeno il tempo di eseguire un comando sqlplus ... – Sebas
@Sebas: c'è molto altro da fare solo per eseguire una ALTER TABLE. Vorrei poter cambiare molte delle mie app semplicemente modificando il codice dell'app che salva un record. Non fraintendermi, sono proprio l'opposto di un fan dei mongo. Personalmente penso che un modello di sviluppo come le migrazioni di Rails possa portare molta agilità su un RDBMS. Ma devo riconoscere che lo schema-free * fa * un'esperienza di sviluppo più veloce e meno frizione. –
Non sto discutendo contro l'idea che sviluppi. Io non sono d'accordo sui principali "attriti", "dispendiosi" che rimproveri alle persone contro i regolari rdbms. Io proprio non lo capisco. È super veloce e non limita affatto ... A meno che tu non stia usando una specie di framework java complesso ma poi, saresti un perfetto idiota ... Mi hai fatto ridere con il tuo commento però :) – Sebas