Debolezze 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 archivi di valori-chiave, archivi di dati grafici e archivi di documenti?

Mi sono divertito a trovare i punti di forza, ma i documenti sui punti deboli sembrano essere più scarsi.

Modifica: in confronto tra loro e con i database relazionali.

Risposte:


7

Il principale punto di forza / debolezza di qualsiasi archivio di dati distribuito deriva dal teorema della PAC. Vedi http://blog.nahurst.com/visual-guide-to-nosql-systems per una rapida panoramica di cosa significhi in pratica per un gran numero di sistemi NoSQL disponibili.


1
Si noti che questo non è in realtà uno svantaggio particolare di NOSQL. Il teorema CAP si applica ugualmente a qualsiasi archivio di dati distribuiti: SQL, NOSQL, relazionale o non relazionale.
nvogel

6

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


Va bene, e gli altri due? Per quanto ne so, i database dei grafici riguardano tutte le relazioni, per esempio.
Edilum,

1
@Aedilum: la mia esperienza riguarda principalmente database relazionali, ma sospetto che archivi di valori-chiave, archivi di dati grafici e archivi di documenti risolvano tutti problemi specifici. In generale, ciascuno sarà forte nel dominio problematico per il quale è specificamente progettato e più debole negli altri domini.
Robert Harvey,

2

Questo è molto soggettivo, ciò che pensi possa essere un punto debole, qualcun altro potrebbe pensare che sia la sua più grande forza.

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

Pertanto, qualsiasi punto debole dei prodotti è la sua incapacità di fare ciò di cui hai bisogno in modo efficiente nel tempo o nello spazio.


In effetti, una delle cose che ho imparato su NoSQL è che sono tutti fatti per risolvere problemi a cui RDBMS fa fatica, come enormi quantità di operazioni in brevi periodi o relazioni complesse.
Edilum,

1

Inizierò notando che amo i database NoSQL e sto per abbandonare i nostri database e applicazioni basati su SQL dove ha senso. Questo processo ha portato alla luce una grave debolezza: la storia operativa non è ancora arrivata. Quello che intendo con questo è:

  • NoSQL è ancora un obiettivo in rapido movimento. Devi conoscerlo abbastanza intimamente per sapere cosa è cambiato tra le versioni. Da un punto di vista operativo ciò crea alcune difficoltà: gli amministratori di sistema sono abituati a cose ragionevolmente documentate con le migliori pratiche. Quando non sono state definite le migliori pratiche, diventa un po 'spaventoso per loro.
  • Pochissime persone là fuori hanno familiarità con il loro funzionamento oltre la comunità di sviluppo. Questo lo rende una sfida quando si desidera consegnare il prodotto alle operazioni e averlo fatto.
  • I migliori tipi di operazioni tendono a essere in grado di gestire l'SQL leggero e almeno riconoscerlo. Json o qualunque cosa parli il tuo nosql è 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 a volte complicata è la segnalazione: molti strumenti userland possono collegarsi direttamente ai database sql, NoSQL richiede ancora che uno sviluppatore attraversi quel bridge.


Quindi, linea di fondo ... Non ci sono reali punti deboli su tutta la linea che non sono correlati all'infanzia dei prodotti NoSQL?
Edilum,

@ Edilum: quell'infanzia è un avvertimento piuttosto grande.
Robert Harvey,

@Robert Harvey: esattamente, l'infanzia genera molti problemi. @Aedilum: come genere non c'è un'orribile debolezza presumendo che tu stia facendo cose con il tuo database NoSQL che hanno senso e hai le braciole per gestirlo, compresa la rotazione della tua soluzione nel buio della notte quando la produzione sta calando perché non esiste un manuale e nessun supporto a pagamento. Ha senso?
Wyatt Barnett,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.