Caratteristiche e gestione dati nell’architettura multi-tenant in informatica
Software SaaS
SaaS è l’acronimo di Software-as-a-Service, software come servizio. Con SaaS, conosciuto anche come software on-demand, ci si riferisce ad un modello di distribuzione del software che diventa utilizzabile tramite internet senza dover essere installato in azienda.
Oggi il panorama SaaS rende disponibile quasi tutte le categorie di software per il business: CRM (Customer relationship management), ERP (Enterprise Resource Planning), contabilità ecc.
Il software non è più acquistato, ma viene preso in “affitto” con il pagamento di un canone, mensile o annuale, ed il rapporto tra fornitore e cliente è regolato dallo SLA (Service Level Agreement). L’azienda non si deve occupare dell’installazione, della manutenzione e aggiornamento del software. Non deve predisporre e gestire l’hardware. L’unica cosa di cui ha bisogno è un browser e di una connessione internet: il software è ospitato sui server del fornitore che si occupa di gestirlo e renderlo disponibile.
Gestione dati nell’architettura multi-tenant
Quando l’applicazione SaaS viene progettata, viene realizzata anche una configurazione standard del database con tabelle, campi e query predefinite, adatte al tipo di applicazione. Il problema si pone poiché clienti diversi possono presentare esigenze diverse, non difficilmente possono essere soddisfatte da un modello dati predefinito. Si rende perciò necessario implementare un metodo che permetta ai clienti di personalizzare il modello dati predefinito secondo le proprie esigenze senza compromettere il modello dati generale. Ci sono tre metodi differenti che vanno dall’isolamento dei dati ai dati completamente condivisi: database separati, database condiviso a schemi separati e database condiviso con schema condiviso.
Database Separati
Questo è l’approccio più semplice all’isolamento dei dati e consiste nell’attribuire ad ogni tenant un database dedicato che può essere modificato liberamente secondo le sue esigenze: può aggiungere campi, query, nuove tabelle e relazioni ma sempre nei limiti del programma.
Questo è il miglio approccio se si cerca l’isolamento dei dati, importante per settori come quello bancario. Inoltre il backup e ripristino dei dati è una procedura semplice.
Sfortunatamente questo approccio tende a generare costi superiori: il numero di database che possono risiedere su ogni server è limitato e quindi l’infrastruttura tenderà a crescere facilmente.
Database condiviso, schemi separati
E’ un approccio che permette di ospitare sullo stesso database diversi clienti, ciascuno dei quali ha il proprio gruppo di tabelle personalizzato. Questo metodo permette ai clienti di estendere e personalizzare le proprie tabelle pur mantenendo i vantaggi economi di un database condiviso. E’ un approccio relativamente semplice da implementare ed offre un discreto livello di isolamento logico dei dati anche se non paragonabile a quello con database separati.
Lo svantaggio principale è la maggior difficoltà, in caso di problemi, nel ripristino dei dati di un cliente. Nel caso dei database separati basta semplicemente ripristinare il database di un dato cliente. In questa implementazione per il ripristinare il database significa riscrivere tutti i dati dei clienti presenti nel database, indipendentemente dal fatto che questi abbiamo problemi o meno.
L’approccio a schemi separati è indicato per le applicazioni con uso ridotto di tabelle, permette di includere in un unico server un numero maggiore di clienti rispetto ai database separati permettendo così di abbassare i costi.
Database condiviso, schemi condivisi
Il database condiviso a schemi condivisi consiste nel memorizzare i dati dei clienti nello stesso database e con lo stesso set di tabelle. Una tabella memorizza record di più clienti identificandoli tramite un id cliente. La tabella presenta un set di campi standard e alcuni campi personalizzabili. Ogni cliente può decidere come utilizzare tali campi.
Avere un database condiviso con schemi condivisi comporta un costo inferiore rispetto agli altri approcci perché permette di supportare un numero di clienti più ampio su un singolo database. Aspetti negativi sono una personalizzazione limitata e la possibile implementazione di funzionalità di protezione aggiuntive per proteggere l’accesso ai dati altrui (sia per errore sia per attacchi informatici). Le operazioni di ripristino dei dati, nel caso si presentassero problemi, sono complesse come nel caso degli schemi separati.
Questo approccio è indicato se si desidera supportare un numero elevato di clienti su un numero di server limitato. Tuttavia la presenza di un numero molto elevato di righe nelle tabelle può ridurre le prestazioni per tutti i clienti inclusi nel database.
