Blog
Quali sono le caratteristiche di un database HANA?
- 06/01/2021
- Scritto da: Grazia Livia Masulli
- Categoria: SAP S/4HANA
La base di dati HANA è il cuore della piattaforma SAP HANA. Quali sono le sue caratteristiche principali?
Si tratta innanzitutto di una soluzione con archiviazione in memoria (“In-memory storage”). In pratica i dati non vengono salvati su dischi rigidi ma sono contenuti nella memoria principale dei server.
Questa soluzione rende possibile accedere ai dati molto più rapidamente (si parla di velocità anche 100.000 volte superiori a quelle ottenibili con dischi rigidi).
Inoltre la memoria è connessa alla CPU (la parte del server che compie le operazioni processando i dati) da dei collegamenti (“Bus”) ad alta velocità, che consentono un ulteriore miglioramento delle prestazioni.
Inoltre in HANA la maggior parte dei dati sono organizzati su tabelle colonnari (“Columnar tables”).
I database tradizionali sono organizzati su righe, e in questo caso i dati sono in generali rapidi da scrivere ma più lenti da leggere: se una tabella ha molte colonne e siamo alla ricerca di una informazione specifica contenuta solo in alcune colonne sarà necessario leggere tutta la fila – comprese le colonne non necessarie – e dopo scartare i dati inutili.
Ovviamente i database tradizionali organizzati per righe hanno anche dei vantaggi: ad esempio la scrittura è molto veloce. Uno degli svantaggi della gestione dei dati in database a colonne è invece che le operazioni nei quali vengono inseriti e aggiornati i dati sono più complesse ed utilizzano più memoria e CPU.
Vediamo un esempio pratico con una tabella di dati semplice (dovete ovviamente immaginare che nella realtà le tabelle sono molto più estese, con migliaia o anche milioni di dati).
Una tabella tradizionale ha questo tipo di struttura:
| Marca | Modello | Colore |
|---|---|---|
| Ferrari | Portofino | Rosso |
| Ferrari | Portofino | Nero |
| Ferrari | Portofino | Argento |
| Ferrari | California | Rosso |
| Ferrari | California | Nero |
| Lamborghini | Aventador | Giallo |
| Lamborghini | Aventador | Rosso |
| Lamborghini | Gallardo | Giallo |
Questa invece sarebbe la struttura della stessa tabella organizzata per colonne:
| Marca 0 - Ferrari 1 - Lamborghini | Modello 0 - Portofino 1 - California 2 - Aventador 3 - Gallardo | Colore 0 - Rosso 1 - Nero 2 - Argento 3 - Giallo |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 0 | 1 |
| 0 | 0 | 2 |
| 0 | 1 | 0 |
| 0 | 1 | 1 |
| 1 | 2 | 3 |
| 1 | 2 | 0 |
| 1 | 3 | 3 |
Come vedete le colonne iniziano con un “dizionario” che spiega come interpretare il contenuto dei diversi attributi (“Marca”, “Modello”, “Colore”, etc.).
Successivamente i dati sono registrati in un modo più compatto grazie alla codifica.
Inoltre HANA utilizza degli algoritmi di compressione dei dati: l’algoritmo più appropriato viene valutato in base alla struttura di ogni colonna.
Un vantaggio aggiuntivo di questa struttura è che ogni colonna può essere processata in parallelo da un diverso nucleo del processore (CPU Core): nei bei tempi andati ogni processore aveva un unico nucleo, ora ne hanno vari indipendenti ed ognuno di essi può lavorare a una attività diversa.
Per rendere ancora più veloce il tutto i server possono anche avere vari processori, ognuno con vari nuclei – questa configurazione rende molto rapido ed efficiente l’accesso in parallelo a varie colonne.
Infine HANA permette di utilizzare delle banche di dati distribuite: i dati vengono divisi tra vari gruppi di server (o addirittura una singola tabella, se molto grande, può essere divisa in varie partizioni e salvata su diversi server).
Questa soluzione tecnica permette di analizzare rapidamente enormi quantità di dati e gestire calcoli complessi.
Al momento la dimensione massima di una tabella di HANA è di due miliardi di records. Se la tabella passa questo limite l’intero database può smettere di funzionare.
Per ciò che riguarda la scalabilità di HANA (ossia la possibilità di estendere le capacità della base di dati) esistono fondamentalmente due soluzioni:
- Scale up (estensione “verticale”). Con questa strategia viene aumentata la memoria RAM della base di dati. Anche la CPU deve essere incrementata proporzionalmente. Il livello massimo di memoria gestibile dipende dall’hardware utilizzato (ad esempio IBM, Cisco, HP hanno limiti differenti).
- Scale out (estensione “orizzontale”). Con questa strategia vengono raggruppati assieme diversi sistemi HANA più piccoli. Il risultato finale è quindi una base di dati in cluster con archiviazione condivisa.
La raccomandazione standard è quella di estendere verticalmente il sistema fino a raggiungere il massimo della memoria possibile (il limite fisico). A quel punto è il momento di aggiungere nuovi server con una estensione orizzontale.
Inoltre, anche quando si inizia ad estendere orizzontalmente il sistema, è buona pratica scegliere la configurazione con il minor numero di nodi possibile.
È importante osservare anche che tabella sono correlate semanticamente, e che tutte quelle che appartengono allo stesso gruppo devono stare nello stesso nodo.
Vediamo ora la recuperabilità di un database HANA.
Recuperabilità (Recoverability) di una base di dati significa che in caso di guasto, le informazioni possono essere ripristinate fino al punto in cui si è verificato il guasto.
Questa è una delle considerazioni più importanti per un sistema come SAP S/4HANA e deve essere pianificata correttamente. Abbiamo commentato all’inizio dell’articolo che HANA è una base di dati In-memory storage (archiviazione in memoria), ossia con i dati memorizzati nella RAM.
Poiché in caso di interruzione di corrente i dati potrebbero essere persi (la RAM si cancellerebbe), c’è anche una memorizzazione persistente sul disco duro per proteggere contro eventuali guasti.
Durante le operazioni normali, i dati vengono infatti passati dalla memoria RAM al disco rigido a intervalli regolari. Questo crea un savepoint (punto di salvataggio).
Inoltre, dei log (registrazioni) vengono generati per ogni cambiamento di dati dopo ogni operazione. Anche i dati dei log sono salvati sul disco rigido dopo ogni transazione. Pertanto, in caso di interruzione di corrente, il database può essere riavviato senza problema. Esso terrà infatti conto dei dati di log dopo il punto di salvataggio. Questo meccanismo permette di evitare perdite di dati in caso di problemi come cali di tensione ed interruzioni di corrente.