2 motivi per cui un database federato non è così sbalorditivo

Spesso è il primo problema che risolvi quando passi al cloud: la tua azienda utilizza dozzine, a volte centinaia, di diversi database eterogenei e ora devi unirli in centinaia di visualizzazioni virtuali dei dati nel cloud.

La cosa buona di questo è che non è necessario migrare a nuovi database o persino spostare i dati da dove sono attualmente ospitati nel cloud. Dopotutto, potrebbero esserci applicazioni che dipendono da quei dati e l'ultima cosa che vuoi fare è memorizzare dati ridondanti.

Quindi, federati. Ciò ti offre una centralizzazione logica dei dati senza dover modificare la posizione in cui i dati sono archiviati fisicamente, cloud o meno.

Ma non così in fretta. Ci sono ostacoli da considerare. Ecco i miei primi due.

In primo luogo, le prestazioni. È certamente possibile combinare dati da un database basato su oggetti, un database relazionale e persino dati non strutturati, utilizzando una visualizzazione basata sui metadati centralizzata e virtualizzata. Ma la tua capacità di eseguire query in tempo reale su quei dati, in un ragionevole lasso di tempo, è un'altra storia.

Il piccolo sporco segreto dei sistemi di database federati (cloud o meno) è che, a meno che tu non sia disposto a dedicare il tempo necessario per ottimizzare l'uso del database virtuale, è probabile che si presentino problemi di prestazioni che fanno uso di un database federato , beh, inutile. A proposito, mettere il database federato nel cloud non ti aiuterà, anche se aggiungi più spazio di archiviazione virtuale e calcoli per provare a forzare le prestazioni.

Il motivo è che devono accadere così tante cose in background solo per ottenere i dati da molte fonti di database diverse. Questi problemi vengono risolti in genere con la determinazione di una buona progettazione del database federato, l'ottimizzazione del database e l'inserimento di limiti sul numero di database fisici che possono essere coinvolti in un singolo modello di accesso. Ho scoperto che il limite è in genere quattro o cinque.

Secondo, sicurezza. Sono abbastanza sicuro che la maggior parte dei database federati basati su cloud in esecuzione nel cloud hanno una vulnerabilità che può essere sfruttata ora e la maggior parte delle aziende che possiedono i dati non lo sanno.

La causa è la stessa del motivo per cui in genere si hanno problemi di prestazioni: ci sono così tante parti mobili che è difficile assicurarsi che tutti i dati, punti di accesso, metadati, ecc. Siano bloccati ma allo stesso tempo facilmente accessibili.

Sebbene i tuoi sistemi che utilizzano database federati possano crittografare i dati a riposo, spesso non crittografano i dati in volo. Oppure, se crittografa i dati durante il volo, probabilmente non stai crittografando i dati a riposo. Oppure esiste un percorso diretto al database fisico che ignora l'architettura del database federato e la sicurezza che fornisce.

Ad oggi, non ho visto un database federato con una solida sicurezza centralizzata che funzioni sia a livello di database virtuale che fisico. Quindi datti da fare a tappare quei buchi!