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

17

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.

scalability

— Jeremy Beard
fonte

15

MS ha appena tenuto un discorso tecnico nei Paesi Bassi, dove hanno discusso 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.

— Dave Markle
fonte

Grazie Dave, mi stai avvicinando a quello che sto cercando di scoprire. Dici che Hadoop è orientato a situazioni con grandi scansioni distribuite - se alcuni / molti RDBMS hanno soluzioni raggruppate (RAC, shard, MPP, ecc.), Perché non possono farlo anche loro? Cosa rende impossibile per un RDBMS ordinare 10 trilioni di record in 16 ore come può fare un cluster Hadoop molto grande? vedi qui

— Jeremy Beard,

2

Niente rende impossibile per un cluster RDBMS eseguire questo tipo di lavoro ed è possibile configurare un RDBMS per scalare per fare questo tipo di cose. Il problema con un RDBMS è che per fare ciò, devi stare molto attento a come strutturi il tuo schema e le tue partizioni affinché funzioni. Le architetture di Big Data vincono quando i tuoi dati non sono abbastanza strutturati per essere partizionati e ottimizzati facilmente o efficacemente in un RDBMS.

— Dave Markle,

1

I progettisti di database incompetenti rendono difficile il ridimensionamento dei database relazionali. Troppe aziende pensano che gli sviluppatori applicatiopn possano progettare database (o peggio usare ORMS per progettare) quando devono assumere sviluppatori di database competenti fin dall'inizio. La seconda persona che assumi per un progetto che coinvolge dati dovrebbe essere lo sviluppatore del database.

— HLGEM,

3

@HLGEM: la mia risposta è "meh". Gli sviluppatori più efficaci saranno quelli che capiranno entrambi i lati dello stack: l'idea che esista un buon "sviluppatore di applicazioni" che lavora sempre con un RDBMS senza sapere come funziona è un errore . Allo stesso modo, l'idea che esista un buon "sviluppatore di database" che non capisce gli ORM o il suo lato applicazione è, IMO, un errore.

— Dave Markle,

6

Il pioniere del database e ricercatore Michael Stonebraker ha co-scritto a documento che discute i limiti delle architetture di database tradizionali. In genere, 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. Ne sono un esempio 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 OLTP in memoria progettato per carichi di lavoro BigData ad alta velocità. (Informativa completa, lavoro per VoltDB).

Questo webinar potrebbe essere 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à del database tradizionale come la coerenza per ottenere prestazioni.

— BenjaminBallard
fonte

6

Per qualificarti come divulgazione completa, dovresti probabilmente anche menzionare che il tuo co-fondatore e CTO Michael Stonebraker è stato anche co-architetto di tutti i tuoi esempi. E che il supporto SQL di VoltDB è un sottoinsieme imbarazzantemente piccolo .

— Daniel Lyons,

5

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 esempio, Global Lock Manger è un killer. 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.

— Sunil
fonte