Data Warehousing - Strategia di partizionamento

Il partizionamento viene eseguito per migliorare le prestazioni e facilitare la facile gestione dei dati. Il partizionamento aiuta anche a bilanciare i vari requisiti del sistema. Ottimizza le prestazioni hardware e semplifica la gestione del data warehouse partizionando ogni tabella dei fatti in più partizioni separate. In questo capitolo, discuteremo diverse strategie di partizionamento.

Perché è necessario partizionare?

Il partizionamento è importante per i seguenti motivi:

  • Per una facile gestione,
  • Per assistere il backup / ripristino,
  • Per migliorare le prestazioni.

Per una facile gestione

La tabella dei fatti in un data warehouse può aumentare fino a centinaia di gigabyte. Questa tabella dei fatti di dimensioni enormi è molto difficile da gestire come una singola entità. Quindi necessita di partizionamento.

Per assistere il backup / ripristino

Se non partizioniamo la tabella dei fatti, dobbiamo caricare la tabella dei fatti completa con tutti i dati. Il partizionamento ci consente di caricare solo la quantità di dati necessaria su base regolare. Riduce il tempo di caricamento e migliora anche le prestazioni del sistema.

Note- Per ridurre le dimensioni del backup, tutte le partizioni diverse dalla partizione corrente possono essere contrassegnate come di sola lettura. Possiamo quindi mettere queste partizioni in uno stato in cui non possono essere modificate. Quindi possono essere sottoposti a backup. Significa che deve essere eseguito il backup solo della partizione corrente.

Per migliorare le prestazioni

Partizionando la tabella dei fatti in set di dati, le procedure di query possono essere migliorate. Le prestazioni della query sono migliorate perché ora la query analizza solo le partizioni rilevanti. Non è necessario scansionare tutti i dati.

Partizionamento orizzontale

Esistono vari modi in cui una tabella dei fatti può essere partizionata. Nel partizionamento orizzontale, dobbiamo tenere presenti i requisiti per la gestibilità del data warehouse.

Partizionamento in base al tempo in segmenti uguali

In questa strategia di partizionamento, la tabella dei fatti viene partizionata sulla base del periodo di tempo. Qui ogni periodo di tempo rappresenta un periodo di conservazione significativo all'interno dell'azienda. Ad esempio, se l'utente richiedemonth to date dataquindi è opportuno suddividere i dati in segmenti mensili. Possiamo riutilizzare le tabelle partizionate rimuovendo i dati al loro interno.

Partizione in base al tempo in segmenti di dimensioni diverse

Questo tipo di partizione viene eseguito laddove si accede raramente ai dati obsoleti. È implementato come un insieme di piccole partizioni per dati relativamente attuali, partizioni più grandi per dati inattivi.

Punti da notare

  • Le informazioni dettagliate rimangono disponibili online.

  • Il numero di tabelle fisiche viene mantenuto relativamente piccolo, il che riduce i costi operativi.

  • Questa tecnica è adatta dove è richiesto un mix di dati che immergono la storia recente e il data mining attraverso l'intera storia.

  • Questa tecnica non è utile quando il profilo di partizionamento cambia regolarmente, perché il ripartizionamento aumenterà il costo operativo del data warehouse.

Partizione su una dimensione diversa

La tabella dei fatti può anche essere partizionata sulla base di dimensioni diverse dal tempo come gruppo di prodotti, regione, fornitore o qualsiasi altra dimensione. Facciamo un esempio.

Supponiamo che una funzione di mercato sia stata strutturata in dipartimenti regionali distinti come in a state by statebase. Se ogni regione desidera interrogare le informazioni acquisite all'interno della propria regione, sarebbe più efficace suddividere la tabella dei fatti in partizioni regionali. Ciò farà accelerare le query perché non richiede la scansione di informazioni non pertinenti.

Punti da notare

  • La query non deve eseguire la scansione di dati irrilevanti che accelera il processo di query.

  • Questa tecnica non è appropriata quando è improbabile che le dimensioni cambino in futuro. Quindi, vale la pena determinare che la dimensione non cambia in futuro.

  • Se la dimensione cambia, l'intera tabella dei fatti dovrebbe essere ripartizionata.

Note - Si consiglia di eseguire la partizione solo sulla base della dimensione temporale, a meno che non si sia certi che il raggruppamento di dimensioni suggerito non cambierà durante la vita del data warehouse.

Partizione per dimensione della tabella

Quando non ci sono basi chiare per partizionare la tabella dei fatti su qualsiasi dimensione, allora dovremmo partition the fact table on the basis of their size.Possiamo impostare la dimensione predeterminata come punto critico. Quando la tabella supera la dimensione predeterminata, viene creata una nuova partizione di tabella.

Punti da notare

  • Questo partizionamento è complesso da gestire.

  • Richiede metadati per identificare quali dati sono archiviati in ciascuna partizione.

Dimensioni di partizionamento

Se una dimensione contiene un numero elevato di voci, è necessario partizionare le dimensioni. Qui dobbiamo controllare la dimensione di una dimensione.

Considera un design di grandi dimensioni che cambia nel tempo. Se dobbiamo memorizzare tutte le variazioni per applicare i confronti, quella dimensione potrebbe essere molto grande. Ciò influirebbe sicuramente sul tempo di risposta.

Partizioni Round Robin

Nella tecnica round robin, quando è necessaria una nuova partizione, viene archiviata quella vecchia. Utilizza i metadati per consentire allo strumento di accesso utente di fare riferimento alla partizione di tabella corretta.

Questa tecnica semplifica l'automazione delle funzionalità di gestione delle tabelle all'interno del data warehouse.

Partizione verticale

Partizionamento verticale, divide i dati verticalmente. Le immagini seguenti mostrano come viene eseguito il partizionamento verticale.

Il partizionamento verticale può essere eseguito nei due modi seguenti:

  • Normalization
  • Divisione di righe

Normalizzazione

La normalizzazione è il metodo relazionale standard di organizzazione del database. In questo metodo, le righe vengono compresse in una singola riga, quindi riduce lo spazio. Dai un'occhiata alle seguenti tabelle che mostrano come viene eseguita la normalizzazione.

Tabella prima della normalizzazione

Codice prodotto Qtà Valore data_vendite Store_id Nome del negozio Posizione Regione
30 5 3.67 3-agosto-13 16 soleggiato Bangalore S
35 4 5.33 3-set-13 16 soleggiato Bangalore S
40 5 2.50 3-set-13 64 san Mumbai W
45 7 5.66 3-set-13 16 soleggiato Bangalore S

Tabella dopo la normalizzazione

Store_id Nome del negozio Posizione Regione
16 soleggiato Bangalore W
64 san Mumbai S
Codice prodotto Quantità Valore data_vendite Store_id
30 5 3.67 3-agosto-13 16
35 4 5.33 3-set-13 16
40 5 2.50 3-set-13 64
45 7 5.66 3-set-13 16

Divisione di righe

La suddivisione delle righe tende a lasciare una mappa uno a uno tra le partizioni. Il motivo della suddivisione delle righe è accelerare l'accesso a un tavolo di grandi dimensioni riducendone le dimensioni.

Note - Durante l'utilizzo del partizionamento verticale, assicurarsi che non sia necessario eseguire un'operazione di join principale tra due partizioni.

Identifica la chiave per la partizione

È molto importante scegliere la giusta chiave di partizione. La scelta di una chiave di partizione sbagliata porterà a riorganizzare la tabella dei fatti. Facciamo un esempio. Supponiamo di voler partizionare la seguente tabella.

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

Possiamo scegliere di partizionare su qualsiasi chiave. Le due possibili chiavi potrebbero essere

  • region
  • transaction_date

Supponiamo che l'attività sia organizzata in 30 regioni geografiche e ogni regione abbia un numero diverso di filiali. Questo ci darà 30 partizioni, il che è ragionevole. Questo partizionamento è abbastanza buono perché la nostra acquisizione dei requisiti ha dimostrato che la stragrande maggioranza delle query è limitata alla regione aziendale dell'utente.

Se partizioniamo per transaction_date invece che per regione, l'ultima transazione di ogni regione sarà in una partizione. Ora l'utente che desidera esaminare i dati all'interno della propria regione deve eseguire query su più partizioni.

Quindi vale la pena determinare la giusta chiave di partizionamento.