it-swarm.it

Perché i database relazionali non sono in grado di soddisfare le dimensioni dei Big Data?

Si ripete spesso che il problema dei Big Data è che i database relazionali non possono ridimensionarsi per elaborare i grandi volumi di dati che vengono ora creati.

Ma quali sono questi limiti di scalabilità a cui le soluzioni Big Data come Hadoop non sono vincolate? Perché Oracle RAC o MySQL sharding o MPP RDBMS come Teradata (ecc.) Non riescono a raggiungere questi talenti?

Sono interessato ai limiti tecnici - Sono consapevole che i costi finanziari del clustering RDBMS possono essere proibitivi.

17
Jeremy Beard

MS ha appena avuto un discorso tecnico nei Paesi Bassi, dove hanno discusso alcune di queste cose. Inizia lentamente, ma entra nella carne di Hadoop intorno al segno dei 20 minuti.

L'essenza è che "dipende". Se hai un set di dati organizzato in modo ragionevole, (almeno un po ') facile da partizionare che (almeno un po') è omogeneo, dovrebbe essere abbastanza facile ridimensionare a quei volumi di dati elevati con un RDBMS, a seconda di cosa stai facendo .

Hadoop e MR sembrano essere più orientati alle situazioni in cui sei costretto a scansioni distribuite di dati di grandi dimensioni, specialmente quando quei dati non sono necessariamente così omogenei o strutturati come quello che troviamo nel mondo RDBMS.

A quali limiti non sono vincolate le soluzioni Big Data? Per me, il limite più grande a cui non sono tenuti è di dover creare uno schema rigido in anticipo. Con le soluzioni Big Data, ora inserisci enormi quantità di dati nella "scatola" e aggiungi successivamente logica alle tue domande per far fronte alla mancanza di omogeneità dei dati. Dal punto di vista di uno sviluppatore, il compromesso è la facilità di implementazione e flessibilità sul front-end del progetto, rispetto alla complessità delle query e alla coerenza dei dati meno immediata.

15
Dave Markle

Il pioniere del database e ricercatore Michael Stonebraker ha co-scritto un paper che discute i limiti delle architetture di database tradizionali. In generale, si espandono con hardware più costoso, ma hanno difficoltà a ridimensionarsi con più hardware di base in parallelo e sono limitati da un'architettura software legacy progettata per un'era precedente. Sostiene che l'era di BigData richiede molteplici nuove architetture di database che sfruttano l'infrastruttura moderna e ottimizzano per un carico di lavoro particolare. Esempi di questo sono il progetto C-store, che ha portato al database commerciale Vertica Systems, e il progetto H-store che ha portato a VoltDB, un database SQL in memoria OLTP SQL progettato per l'alta velocità Carichi di lavoro di BigData. (Informativa completa, lavoro per VoltDB).

Potresti trovare questo webinar interessante su questo argomento. Risponde ad alcuni dei miti sorti con il successo dei database NoSQL. Fondamentalmente, sostiene che SQL non è stato il problema, non dovrebbe essere necessario rinunciare alle funzionalità tradizionali del database come la coerenza per ottenere prestazioni.

6
BenjaminBallard

Non è del tutto vero che RDBMS non può ridimensionare. Tuttavia, la verità parziale nell'affermazione dipende dall'architettura. Nell'elenco che hai fornito, Oracle RAC è diverso dal resto (MySQL e Teradata frammentati). La differenza principale è il disco condiviso rispetto alle architetture condivise.

Le architetture di dischi condivisi come Oracle RAC soffrono di ridimensionamento perché a un certo punto o tutte le macchine in esecuzione dovrebbero sincronizzarsi su una parte dei dati. Ad es. Global Lock Manger è un assassino. Puoi continuare a perfezionarlo in una certa misura, ma alla fine colpirai un muro. Se non riesci ad aggiungere facilmente macchine, dovresti avere meno macchine super potenti che potrebbero bruciare la tua tasca. In caso di architetture non condivise (o dati condivisi), ogni macchina diventa proprietaria di alcuni dati. Non è necessario sincronizzarsi con altri mahcine se si desidera aggiornare alcuni dati.

Poi arriva la razza di database NoSQL. Tratterei loro un sottoinsieme dei database RDBMS tradizionali. Non tutte le applicazioni in questo mondo avranno bisogno di tutte le funzionalità offerte da RDBMS. Se voglio usare il database come cache, non mi interesserebbe la durabilità. In alcuni casi potrebbe anche non interessarmi della coerenza. Se tutta la mia ricerca di dati si basa su una chiave, non ho bisogno del supporto per le query di intervallo. Potrei non aver bisogno di indici secondari. Non ho bisogno dell'intero livello di elaborazione delle query/ottimizzazione delle query che hanno tutti i database tradizionali.

5
sunil