Memorizza grandi quantità di dati

3

Stavo facendo un brainstorming e ho trovato un argomento piuttosto interessante che non sono riuscito a trovare una soluzione per me.

Come funziona la memorizzazione di quantità eccessive di dati? Intendo fisicamente, non importa quanto grande sia l'unità, ci saranno sempre più dati di quanta c'è spazio su un singolo disco. E sto indovinando che questa è più una domanda fondamentale, perché posso vedere come funziona con il caching, dal momento che è essenzialmente lo stesso problema, tranne che è la RAM che si esaurisce. Quando un server esaurisce la RAM, si avvia un secondo server, quindi si inviano entrambi i server per trovare la chiave necessaria, è OK perché la RAM è veloce, ma come funziona con i database relazionali? Non puoi dividere una tabella tra due unità o puoi? Anche se fosse possibile, non funzionerebbe ancora perché l'interrogazione di più database sarebbe lenta? Apparentemente c'è una sorta di soluzione a questo problema, dal momento che Google, Facebook e altri sono funzionanti e sicuramente possiedono una quantità folle di dati.

    
posta php_nub_qq 19.09.2015 - 22:47
fonte

3 risposte

9

Il termine più generalizzato per questo è "indice distribuito", ed è davvero un argomento abbastanza complesso in cui viene svolta molta ricerca attiva.

Il primo passo è un server di indicizzazione dedicato, cioè uno che non contiene dati in sé ma per ogni chiave sa quale server ha i dati per quella chiave e inoltra la richiesta lì.

Quando anche l'indice diventa troppo grande per un server, è possibile suddividere l'indice, in modo più ingenuo, facendo in modo che ciascun server di indicizzazione sia responsabile di un uguale intervallo di spazio della chiave, ad es. con i tasti stringa uno è responsabile per A-M e l'altro per N-Z. Ma i dati potrebbero essere distribuiti in modo non uniforme e la distribuzione può cambiare, quindi è necessario che gli intervalli siano dinamici.

Il passaggio successivo è quindi una gerarchia di server di indici, in cui il primo determina solo quale altro server è responsabile dell'intervallo in cui è presente la chiave richiesta, possibilmente con più di tali "hop".

La cosa davvero complicata a proposito di questo è come coordinare i cambiamenti nell'indice (aggiunte, cancellazioni) tra i server, specialmente quando si replicano parti dell'indice su più server per gestire una grande quantità di richieste. Ti imbatti in tutti i tipi di problemi di concorrenza molto complessi: deadlock, blocco della serratura, blocchi distribuiti che sono inaccettabilmente lenti, che si occupano di ritardi e interruzioni della rete ... Come ho scritto, argomento di ricerca attivo!

    
risposta data 19.09.2015 - 23:37
fonte
3

I file system possono estendersi su più dischi fisici. Potresti avere familiarità con il concetto di "partizioni", in cui un supporto fisico è suddiviso in più volumi logici, ad es. un disco rigido in un'installazione tipica di Windows potrebbe avere una partizione C: e D: . Tuttavia, questo non deve essere una mappatura 1: n e alcuni file system possono gestire n: m mappature tra unità e volumi / file system.

La motivazione principale per un livello di astrazione tra volumi logici e dischi fisici non è la potenziale maggiore capacità di archiviazione, ma maggiore flessibilità e migliore tolleranza d'errore, specialmente in un'impostazione del server: quando un disco rigido si guasta, voglio che il server continui in esecuzione senza interruzioni o tempi di inattività, anche quando sostituisco il disco guasto. Questa tolleranza di errore implica che gli stessi dati vengano replicati su più dischi rigidi (ad esempio in una configurazione RAID-6); la possibilità di eseguire l'hot-swap di un'unità richiede che le applicazioni non siano consapevoli dei dischi fisici (ad esempio, utilizzano solo il file system, non accedono direttamente al dispositivo).

Questa funzionalità può essere fornita dai controller del disco hardware che si presentano al sistema operativo come un singolo disco, ma in realtà contengono più unità. Tuttavia, ci sono anche approcci software. Su Linux, è possibile utilizzare Logical Volume Manager per implementare partizioni multi-drive, spostare partizioni tra le unità o per unità hot-swap. Il file system ZFS è stato creato per supportare enormi quantità di dati e include una gestione sofisticata di grandi pool di unità fisiche. Un file system ZFS è distribuito su tutti i dischi nel suo pool e può supportare lo swapping a caldo se in una configurazione RAID adeguata.

Ad esempio, ho configurato un server con un pool ZFS da ~ 1TB su dischi 10 × 150 GB. Il livello RAID scelto può resistere a due guasti del disco e uno dei dischi è un hot spare che verrà utilizzato per ripristinare il pool fino a quando i dischi guasti possono essere scambiati. Ovviamente, questo potrebbe essere scalato con dischi più grandi. Per esempio. con 20 dischi da 2 TB, li configurerei in un pool da 30 TB.

Il livello RAID scelto ha implicazioni sulle prestazioni. Poiché un file è tipicamente distribuito su più dischi, la sua lettura può utilizzare la larghezza di banda combinata di tutte le unità. Tuttavia, le prestazioni in scrittura vengono ridotte quando lo stesso file viene scritto su più unità per la tolleranza agli errori.

Con tecniche come RAID o Storage Area Networks, c'è molto che puoi fare per espandere la capacità di archiviazione di un sistema. Tuttavia, a un certo punto i dati possono diventare troppo grandi per essere gestiti su un singolo sistema, ad es. se si ha un throughput troppo elevato o se è necessario un livello di sistema piuttosto che una tolleranza ai guasti a livello del disco. In uno scenario del genere, è necessaria un'architettura software distribuita diversa per aumentare ulteriormente, anche se i problemi relativi alla coerenza dei dati si presentano quando si hanno più sistemi responsabili degli stessi dati.

    
risposta data 20.09.2015 - 13:40
fonte
2

I più grandi sistemi di storage utilizzano sistemi di file paralleli specializzati come Lustre, GPFS, BeeGFS, ecc. I più grandi supercomputer al mondo si affidano a una di queste, tipiche installazioni che raggiungono bene la gamma dei petabyte, i. e. contengono letteralmente migliaia di dischi rigidi (1 petabyte = 1000 terabyte). Queste unità sono collegate a un numero di server front-end dedicati (spesso chiamati nodi I / O), che forniscono una vista unificata del file system al resto dei supercomputer.

L'uso di questi filesystem è proprio come con qualsiasi altro filesystem montato via NFS, la semantica è POSIX-like (POSIX- "like" perché molti di questi file system paralleli si discostano sottilmente dalla rigida semantica di POSIX per motivi di prestazioni). Non si vede, su quale file è posizionato il disco, nemmeno su quale server gestisce i suoi dati. Questo viene sottratto dal file system. I file possono anche essere a strisce su più server per ottenere un throughput più elevato.

Naturalmente, i file system come questi hanno latenze più elevate rispetto a un disco locale, quindi offrono i migliori risultati quando gli accessi ai dati sono ampi e sequenziali. Pertanto, inserire un database su di essi non è generalmente l'idea migliore, tuttavia, può essere fatto. Come ho detto, l'uso di un file system parallelo non è molto diverso dall'uso di qualsiasi altro file system montato via NFS.

    
risposta data 20.09.2015 - 15:35
fonte

Leggi altre domande sui tag