2012-01-11 10 views
8

Voglio solo capire meglio, in quello che ho imparato da anni è una soluzione basata su documenti è lenta e richiede un sacco di I/O. Per esempio in un progetto PHP, si dice generalmente che è molto meglio usare una cache di memoria come Redis, Memecache o APC perché sono basate sulla memoria invece di memorizzare i dati nella cache in un FILE reale.In che modo un DB basato su documenti è così veloce?

Ora tutti questi DB NoSQL sono arrivati ​​e ho letto di come sono molto più veloci di MySQl e altri e sono basati su documenti. Qualcuno può aiutarmi a capire questa teoria? Se ogni record è un documento (FILE), allora come è buono sulle prestazioni? Recentemente ho letto di un ragazzo che stava usando Redis in un progetto e ha detto che è passato a MongoDB e sta ottenendo risultati migliori, poi ha fatto con Redis (mi rendo conto che sto confrontando una cache con un DB, ma questa non è la vera domanda, io vuoi sapere in che modo una soluzione basata su documenti è più veloce di soluzioni non basate su documenti?)

risposta

4

Basato su documento non significa necessariamente che sono memorizzati interamente su file system. Alcune parti possono ancora essere conservate in memoria come un indice.

Documento basato solo significa che il database memorizza i dati in pacchetti (come fogli di carta in cui ogni foglio è un set di dati e si può scrivere liberamente su di esso) invece di una struttura molto specifica come una tabella.

http://en.wikipedia.org/wiki/Document-oriented_database

Ah, e perché essi possono essere più veloce di Redis:
Diciamo che è necessario per memorizzare alcune informazioni non lineare in un set (vale a dire non tutti i set di dati sembra lo stesso e hai diversi tipi di dati in un set. Su Redis è possibile memorizzare solo coppie chiave-valore quindi è necessario collegarle di nuovo a un set nel proprio codice/implementazione. Su un database NoSQL questo viene gestito dal database in un (probabilmente) molto più ottimizzato :)

+0

Redis non memorizza solo coppie chiave/valore, può archiviare molti più tipi di dati (vedere: http://redis.io/topics/data-types) – Carpetsmoker

0

La prima cosa è: non è possibile confrontare i DB NoSQL con i DB in memoria . I DB NoSQL sono utili per i dati che non si adattano alla memoria.

Ora, per quanto riguarda i DB NoSQL, non sono solo semplici file, hanno indici che forniscono un rapido accesso agli offset nei file ed è qui che la velocità è veramente.

+4

'I DB NoSQL sono utili per i dati che non adattarsi alla memoria ». Questo è assolutamente sbagliato. Perché dici questo? – jgauffin

+0

Ok, mi correggo, * il più delle volte * sono usati per strutture che supereranno le dimensioni che possono stare nella memoria. Possono essere utilizzati anche come memoria in-memory e possono fornire prestazioni migliori rispetto alle tabelle relazionali in memoria poiché sono più semplici da implementare. Detto questo, alcune volte è possibile ottenere prestazioni ancora migliori implementando strutture dati nel proprio programma. – thedrs

+1

'la maggior parte delle volte è ancora sbagliato. Sono semplicemente un'alternativa a RDBMS, ma schemi e con una soluzione migliore per le radici aggregate. – jgauffin

2

Il NoSQL parlare può essere soggetto a fraintendimenti, come alcuni dei concetti useranno nomi, che hanno un significato diverso da quello tradizionale:

  • File basato non (necessariamente) significa che il Datastore scriverà ogni record su un file - è inteso per dire che i record nel datastore non dovranno conformarsi a uno schema predefinito di campi se un determinato tipo di dati. Pensa al "file" come qualcosa come XML, JSON o amici.
  • Le prestazioni vincenti dei (più) datastore NoSQL hanno un prezzo: le promesse ACID in genere ben comprese sono scambiate contro un modello di consistenza più flessibile.
  • La potenza dei database SQL relazionali deriva in gran parte dal fatto che, al pari di ogni query, è possibile scrivere su uno schema esistente. Questo non è sempre vero con i datastore NoSQL: nella versione più estrema l'accesso a un record è possibile solo tramite un ID record.
  • La maggior parte NoSQL datastore scalerà molto meglio di un database tipico relazionale - sono la risposta alla domanda "Che cosa dobbiamo sacrificare da un DB relazionale ben compreso" per superare i limiti di scala"
0

per avere un'idea, si consideri questo:

  • con MongoDB si sarebbe progettare lo schema in un modo che un singolo documento contiene tutto il necessario per il rendering di una pagina
  • con MySQL (o qualsiasi altro RDBMS) voi. 'd normalizzare i dati e dividerli su più tabelle pagina, dovresti fare molte query SQL.

Anche se una query mongo potrebbe essere più lenta di una query mysql, il confronto di una query da 1 mongo a 100 query MySQL sarà molto più veloce.

0

L'ingrediente magico non è necessariamente un database "più veloce", è un database che consente la progettazione e l'implementazione di sistemi "più veloci". Ecco perché i database NoSQL sono considerati un punto di svolta.

Per diversi decenni i database relazionali erano l'unico gioco in città. Molti sistemi basati su SQL pagano una doppia imposta sulle prestazioni: una volta per l'intero set di funzionalità ACID (di cui probabilmente non hanno bisogno in ogni caso), e poi di nuovo trasferire i propri dati di dominio in un modello di tabella relazionale.

Inoltre, una caratteristica comune della maggior parte dei database NoSQL è che sono più semplice a causa del loro essere più specializzati rispetto all'approccio "caso generale" di un database SQL. Ciò significa meno logica/codice che deve essere eseguito su ogni operazione, strutture dati più semplici (che possono richiedere meno IO) e in generale - meno costi generali, prestazioni migliori.

Problemi correlati