Punti deboli con diversi tipi di database NoSQL

10

Ecco la mia domanda: quali sono i punti deboli con diversi tipi di database NoSQL? In particolare, quali sono i punti deboli di negozi di valore chiave, archivi di dati grafici e archivi di documenti?

Mi è stato facile trovare i punti di forza, ma i documenti sulle debolezze sembrano essere più scarsi.

Modifica: in confronto tra loro e ai database relazionali.

    
posta Aedilum 09.05.2011 - 19:18
fonte

4 risposte

7

Il maggior punto di forza / debolezza di qualsiasi archivio dati distribuito deriva dal teorema CAP. Vedi link per una rapida carrellata di ciò che significa in pratica per un gran numero di sistemi NoSQL che sono là fuori.

    
risposta data 09.05.2011 - 22:59
fonte
6

Se li stai confrontando con i database relazionali, l'ovvia debolezza è che gli store con valore-chiave non sono relazionali. Di conseguenza, può essere più difficile scrivere report utilizzando gli archivi di valori-chiave di quanto non stia utilizzando un database relazionale, per il quale tali report e l'estrazione dei dati sono progettati in modo specifico.

    
risposta data 09.05.2011 - 20:57
fonte
2

Questo è molto soggettivo, quello che pensi possa essere una debolezza, qualcun altro potrebbe pensare che sia la sua più grande forza.

Tutti i database NoSQL che sono attualmente popolari stanno affrontando problemi a cui i sistemi RDBMS esistenti erano deboli, e di solito sono altamente specializzati in un particolare problema che il mittente aveva e stava cercando di risolvere.

Quindi, la debolezza di qualsiasi prodotto è la sua inabilità a fare ciò che tu hai bisogno di fare in un modo efficiente in termini di tempo o spazio.

    
risposta data 09.05.2011 - 21:14
fonte
1

Inizierò osservando che adoro i database NoSQL e che sono in procinto di abbandonare i nostri database e applicazioni basati su SQL dove ha senso. Questo processo ha portato alla luce una grande debolezza: la storia operativa non è ancora arrivata. Quello che intendo con questo è:

  • NoSQL è ancora un obiettivo in rapido movimento. Devi essere abbastanza intimamente a conoscenza per sapere cosa è cambiato tra le versioni. Da un punto di vista operativo ciò crea alcune difficoltà: gli amministratori di sistema sono abituati a documentazioni ragionevoli con le migliori pratiche. Quando le best practice non sono state definite, diventa un po 'spaventoso per loro.
  • Molto, molto poche persone là fuori hanno familiarità con il loro funzionamento oltre la comunità di sviluppo. Ciò rappresenta una sfida quando si desidera consegnare il prodotto alle operazioni e utilizzarlo.
  • I migliori tipi di operazioni tendono a essere in grado di gestire l'SQL leggero, e almeno a riconoscerlo. Json o qualunque cosa tu nosql parli è un po 'una curva di apprendimento.
  • La reputazione è una cosa complicata - la perdita di dati è molto spaventosa per i tipi di operazioni. Sono arrivati a credere che i database SQL sopravviveranno all'olocausto nucleare. NoSQL sarà un po 'un lavoro di vendita lì.

Un'altra cosa difficile a volte sta riportando - molti strumenti di userland possono collegarsi direttamente ai database sql, NoSQL richiede ancora uno sviluppatore per attraversare quel bridge.

    
risposta data 09.05.2011 - 23:36
fonte

Leggi altre domande sui tag