Sono database orientati ai documenti destinate a sostituire i database relazionali?

StackOverflow https://stackoverflow.com/questions/2866086

Domanda

Di recente ho lavorato un po 'con MongoDB e devo dire che mi piace molto. Tuttavia si tratta di un tipo completamente diverso di database di poi mi sono abituato. Ho notato che è sicuramente migliore per alcuni tipi di dati, tuttavia per i database pesantemente normalizzati potrebbe non essere la scelta migliore.

Mi sembra, tuttavia, che si può prendere completamente il posto di praticamente qualsiasi database relazionale si può avere e nella maggior parte dei casi un rendimento migliore, che è sconvolgente. Questo mi porta a fare alcune domande:

  1. sono database orientati ai documenti in fase di sviluppo per essere la prossima generazione di basi di dati e fondamentalmente sostituire completamente database relazionali?
  2. E 'possibile che i progetti sarebbero meglio utilizzare sia un database document-oriented e un lato database relazionale a fianco di vari dati che è più adatto per uno o l'altro?
  3. Se i database orientati ai documenti non sono destinate a sostituire database relazionali, poi qualcuno ha un esempio di una struttura di database che sarebbe assolutamente meglio in un database relazionale (o viceversa)?
È stato utile?

Soluzione

  

sono database orientati ai documenti sono stati sviluppati per essere la prossima generazione di basi di dati e fondamentalmente sostituire completamente database relazionali?

No. i database orientati ai documenti (come MongoDB) sono molto bravi al tipo di attività che di solito vediamo in siti web moderni (veloce look-up di oggetti singoli o piccoli gruppi di oggetti).

Ma fanno alcuni grandi compromessi con i sistemi relazionali. Senza le cose come la conformità ACID non sta andando ad essere in grado di sostituire alcuni RDBMS. E se si guarda a sistemi come MongoDB, la mancanza di conformità ACID è un grande motivo è così veloce.

  

E 'possibile che i progetti sarebbero meglio utilizzare sia un database document-oriented e un lato database relazionale a fianco di vari dati che è più adatto per uno o l'altro?

Sì. In realtà, io sto correndo un grande sito di produzione che utilizza sia. Il sistema è stato avviato in MySQL, ma abbiamo migrato parte di esso verso MongoDB, b / c abbiamo bisogno di un negozio di valore-chiave e MySQL semplicemente non è molto bravo a trovare un elemento in base a 150m record.

  

Se i database orientati ai documenti non sono destinate a sostituire database relazionali, poi qualcuno ha un esempio di una struttura di database che sarebbe assolutamente meglio in un database relazionale (o viceversa)?

database orientati ai documenti sono la memorizzazione dei dati grandi che può essere facilmente contenuti in "valore-chiave" e semplice, lineare relazioni "padre-figlio". Semplici esempi qui ci sono cose come blog e wiki.

Tuttavia, relazionale database hanno ancora una gamba forte su cose come la segnalazione, che tende ad essere "basata set-".

Onestamente, posso vedere un mondo in cui la maggior parte dei dati vengono "trattati" dal database di Document-oriented, ma dove la segnalazione è fatto in un database relazionale che viene aggiornato dalla Mappa-ridurre posti di lavoro.

Altri suggerimenti

Questa è davvero una questione di idoneità allo scopo.

Se si vuole essere in grado di unire alcuni tavoli insieme e restituire un insieme filtrato di risultati, è possibile farlo solo con un database relazionale. Se si desidera prestazioni mind-bending e hanno incredibili volumi di dati, che è quando la colonna-famiglia o database orientati ai documenti entrano in loro propri.

Questo è un classico trade-off. I database relazionali offrono una suite completa di funzionalità, che viene fornito con un costo delle prestazioni. Se non si poteva entrare, indice, scansione o eseguire tutto un altro elenco di caratteristiche, si rimuove la necessità di avere qualsiasi vista su tutti i dati, che vi dà le prestazioni e la distribuzione è necessario macinare i dati gravi.

Inoltre, vi consiglio di seguire i blog di Ayende Rahien su questo argomento.

http://ayende.com/blog/

@Sohnee è a posto. Potrei aggiungere che i database relazionali

  • sono eccellenti per il recupero delle informazioni in combinazioni inaspettate - anche se che a volte porta alla cattiva idea di estesi rapporti di essere eseguito su sistemi di produzione time-sensitive, piuttosto che su un data warehouse separati
    • .
  • sono una tecnologia matura, dove si può facilmente trovare il personale e ben collaudate soluzioni a qualsiasi numero di problemi (compresi i limiti del modello relazionale, così come l'implementazione imperfetta che è SQL).

Chiedetevi che cosa si vuole fare, e ciò che qualità sono importanti per voi. Si può fare tutto ciò che riguarda la programmazione negli script di shell. Vuoi?

Continuo a chiedere la stessa domanda, che è quello che mi è atterrato qui. Io uso sia MySQL e MongoDB (non in tandem attualmente, anche se la sua idea). Devo dire onestamente io sono molto felice di toccare mai MySQL di nuovo. Che ci sia il rispetto "ACID", ma hai mai incontrato la necessità di riparare le tabelle con MySQL? Avete mai avuto un database danneggiato? Succede. Hai mai avuto altri problemi con MySQL? Eventuali contestazioni serratura o serrature morto? Eventuali problemi con il clustering? Quanto è stato facile da installare e configurare?

MongoDB ... si accende ed è fatta .... Poi è autosharding. E 'incredibilmente semplice ed è anche incredibilmente veloce. Quindi, pensare a questo. Il vostro tempo.

No, non hanno join ma è una dichiarazione del tutto corretto dire che sconta oltre il 99% delle esigenze di gestione dei dati. Ho spesso l'opposizione quando si cerca di spiegare MongoDB, la gente ancora sghignazzando. Diciamo solo affrontarlo. La gente non vuole imparare cose nuove e pensano che quello che sanno è tutto di cui hanno bisogno. Certo, si può scappare utilizzando MySQL il resto della tua vita e costruire i vostri siti web. Funziona, sappiamo che funziona. Sappiamo anche fallisce. Se non lo fa, si sarebbe chiedere mai la domanda e noi probabilmente non vedere così molti database di documenti oriented. Sappiamo che sì lo fa scala, ma è un dolore nella parte posteriore per scalarla.

consentono anche di eliminare il traffico e il ridimensionamento dalla foto. Estrarre l'installazione. Ora concentriamoci sul consumo. Qual è la vostra esperienza quando si utilizza MySQL? Quanto sei bravo con l'architettura MySQL e fare query efficienti? Quanto tempo dedichi alla ricerca sulla query con spiegare? Quanto tempo dedichi fare diagrammi di schema? ... Io dico che prendere tempo indietro. E 'meglio spesi altrove.

Ecco i miei due centesimi. Ho davvero l'amore MongoDB e la speranza di non usare di nuovo MySQL e per il tipo di siti web costruisco, è molto probabile che non avrò bisogno di. Anche se sto ancora cercando di scoprire quando vorrei utilizzare MySQL su MongoDB, non quando posso (diciamocelo, memorizza i dati, congratulazioni, potrei scrivere un sacco di file XML troppo ma non è una buona idea) , ma quando si beneficerebbe di utilizzare uno o l'altro. Nel frattempo, ho intenzione di andare a fare il mio lavoro con MongoDB e hanno meno mal di testa.

Fino a quando non hai bisogno di transazioni multi-oggetto, MongoDB può essere un sostituto favorevole per un RDMBS, soprattutto in un contesto di un'applicazione web. Velocità, schemalessness, e la modellazione del documento sono tutti utili questo dominio.

A mio parere i database orientati ai documenti sono solo buoni per

  1. Banche dati quali dati viene descritta meglio tramite un modello gerarchico (albero). Questo non è comune per i database del sito web.
  2. database con un'enorme quantità di dati come i database di Facebook e Amazon. In questo caso è necessario sacrificare i vantaggi del modello relazionale.

Per quanto ne so, i database di documenti non hanno JOIN. Che è praticamente uno show-stopper per> 99% delle esigenze di gestione dei dati.

Come Matthew Flaschen sottolinea nei commenti, anche sul desktop, database come SQLite stanno introducendo la semantica SQL per aree che sono tradizionalmente utilizzati formati di file proprietà o XML.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top