Pro di database come BigTable, SimpleDB

Question

I paradigmi della nuova scuola di datastore come Google BigTable e Amazon SimpleDB sono progettati specificamente per la scalabilità, tra le altre cose. Fondamentalmente, non consentire join e denormalizzazione sono i modi in cui questo viene realizzato.

In questo argomento, tuttavia, il consenso sembra essere che si unisce a grandi le tabelle non devono necessariamente essere troppo costose e la denormalizzazione è "sopravvalutata" in una certa misura Perché, quindi, questi sistemi di cui sopra non consentono i join e costringono tutto insieme in un'unica tabella per raggiungere la scalabilità? Sono i volumi di dati che devono essere archiviati in questi sistemi (molti terabyte)?
Le regole generali per i database semplicemente non si applicano a queste scale? È perché questi tipi di database sono stati progettati appositamente per l'archiviazione di molti oggetti simili?
O mi sto perdendo un quadro più ampio?

Answer 1

I database distribuiti non sono così ingenui come suggerisce Orion; c'è stato un bel po 'di lavoro fatto per ottimizzare le query completamente relazionali su set di dati distribuiti. Potresti voler vedere cosa stanno facendo aziende come Teradata, Netezza, Greenplum, Vertica, AsterData, ecc. (Oracle è entrata nel gioco, infine, anche con il loro recente annuncio; Microsoft ha acquistato la sua soluzione in nome della società che un tempo si chiamava DataAllegro).

Detto questo, quando i dati aumentano in terabyte, questi problemi diventano molto banali. Se non hai bisogno delle rigide garanzie di transazionalità e coerenza che puoi ottenere dagli RDBM, spesso è molto più facile denormalizzare e non fare join. Soprattutto se non è necessario fare molti riferimenti incrociati. Soprattutto se non stai effettuando analisi ad hoc, ma hai bisogno di un accesso programmatico con trasformazioni arbitrarie.

La denormalizzazione è sopravvalutata. Solo perché è quello che succede quando si ha a che fare con una Tera 100, ciò non significa che questo fatto dovrebbe essere usato da ogni sviluppatore che non si è mai preso la briga di conoscere i database e ha problemi a interrogare un milione o due righe a causa della scarsa pianificazione dello schema e dell'ottimizzazione delle query .

Ma se sei nella gamma 100 Tera, sicuramente ...

Oh, l'altro motivo per cui queste tecnologie stanno ottenendo il buzz: le persone stanno scoprendo che alcune cose non sono mai appartenute al database in primo luogo e si stanno rendendo conto che non hanno a che fare con le relazioni nei loro campi particolari, ma con coppie chiave-valore di base. Per cose che non avrebbero dovuto essere in un DB, è del tutto possibile che il framework Map-Reduce, o qualche sistema di archiviazione persistente, eventualmente coerente, sia la cosa giusta.

Su scala meno globale, consiglio vivamente BerkeleyDB per questo tipo di problemi.

Answer 2

Non li conosco molto bene (ho letto solo gli stessi blog / notizie / esempi di tutti gli altri) ma la mia opinione è che hanno scelto di sacrificare molte delle normali funzionalità di DB relazionali nel nome di scalabilità - proverò a spiegare.

Immagina di avere 200 righe nella tua tabella di dati.

Nel data center di google, 50 di queste righe sono archiviate sul server A, 50 su B e 100 sul server C. Inoltre, il server D contiene copie ridondanti di dati dai server A e B e il server E contiene copie ridondanti di dati su server C.

(Nella vita reale non ho idea di quanti server verrebbero utilizzati, ma è impostato per gestire molti milioni di righe, quindi ne immagino alcuni).

Per " selezionare * dove name = 'orion' " ;, l'infrastruttura può inviare la query a tutti i server e aggregare i risultati che ritornano. Ciò consente loro di scalare praticamente in modo lineare su tutti i server che vogliono (FYI questo è praticamente ciò che mapreduce è)

Ciò significa tuttavia che sono necessari alcuni compromessi.

Se fosse necessario eseguire un join relazionale su alcuni dati, in cui erano distribuiti tra 5 server, ognuno di questi server avrebbe dovuto estrarre i dati dagli altri per ogni riga . Prova a farlo quando hai 2 milioni di righe distribuite su 10 server.

Questo porta al compromesso n. 1 - Nessun join.

Inoltre, a seconda della latenza della rete, del carico del server, ecc., alcuni dei tuoi dati potrebbero essere salvati all'istante, ma alcuni potrebbero richiedere un secondo o 2. Ancora una volta, quando hai dozzine di server, questo diventa sempre più lungo e il l'approccio normale di "tutti aspettano solo che il ragazzo più lento abbia finito" non diventa più accettabile.

Questo porta al compromesso n. 2 - I tuoi dati potrebbero non essere sempre immediatamente visibili dopo che sono stati scritti.

Non sono sicuro di quali altri compromessi ci siano, ma al di sopra della mia testa quelli sono i principali 2.

Answer 3

Quindi quello che sto ottenendo è che l'intero "denormalize", nessun join " la filosofia esiste, non perché i join stessi non si ridimensionano in sistemi di grandi dimensioni, ma perché sono praticamente impossibili da implementare in database distribuiti.

Questo sembra abbastanza ragionevole quando si memorizzano dati in gran parte invarianti di un singolo tipo (come fa Google). Sono sulla buona strada qui?

Answer 4

Se stai parlando di dati praticamente di sola lettura, le regole cambiano. La denormalizzazione è più difficile nelle situazioni in cui i dati cambiano perché il lavoro richiesto è aumentato e ci sono più problemi con il blocco. Se i dati cambiano a malapena, la denormalizzazione non è un problema.

Answer 5

Novaday È necessario trovare più ambiente interoperativo per i database. Più frequentemente non sono necessari solo DB relazionali, come MySQL o MS SQL, ma anche fattorie Big Data come Hadoop o DB non relazionali come MongoDB. In alcuni casi, tutti quei DB verranno utilizzati in un'unica soluzione, pertanto le loro prestazioni devono essere le più uguali possibili su scala macro. Significa che non sarai in grado di usare diciamo Azure SQL come DB relazionale e una VM con 2 core e 3 GB di RAM per MongoDB. È necessario ridimensionare la soluzione e utilizzare DB come servizio quando è possibile (se non è possibile, quindi creare il proprio cluster in un cloud).