Un'istruzione SQL attraverso tutti i tuoi database.

Una query federata è un'unica istruzione SQL che legge da più database separati e restituisce un singolo risultato combinato. Nulla viene copiato prima: l'istruzione viene suddivisa in una piccola query per ogni database, ognuna delle quali risponde alla parte che può e le parti vengono unite per ottenere il risultato finale. In Query Streams, un'istruzione diventa federata non appena specifica due o più connessioni.

No. Possono trovarsi in uffici diversi, account cloud diversi, paesi diversi o in una combinazione di tutti e tre: uno in una sala server, uno in una rete cloud privata, uno su una macchina in un magazzino. Ogni sede esegue un Network Agent e ogni agente raggiunge Query Streams tramite una connessione in uscita. Per quanto riguarda il firewall, si tratta semplicemente di una normale connessione in uscita, quindi non c'è nulla da aprire né VPN da configurare.

È anche possibile indirizzare più database su un singolo server allo stesso agente; di norma è previsto un agente per sede, non uno per database.

Non per questo. Non c'è nulla da caricare e nessuna pianificazione da gestire: la query legge i database attivi nel momento stesso in cui viene eseguita, quindi la risposta non può essere obsoleta come potrebbe esserlo una copia della sera prima. Ciò che la federazione non sostituisce è l'analisi storica approfondita su volumi di dati molto grandi; questo compito rimane di competenza di un data warehouse. Un test approssimativo: se la domanda riguarda diversi sistemi e deve essere aggiornata, conviene federarla.

Qualsiasi delle tue connessioni al database, in qualsiasi combinazione: SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access e DuckDB. Ogni database viene interrogato nel suo dialetto, quindi la stessa istruzione può inviare SUPERIORE a SQL Server e LIMITE a PostgreSQL senza che tu te ne accorga.

I database differiscono effettivamente per ciò che possono calcolare e per come ordinano e arrotondano i dati, quindi non è possibile rispondere esattamente a tutte le combinazioni di ogni espressione. In questi casi, viene visualizzato un messaggio specifico che indica l'espressione, anziché un numero approssimativo.

Dipende da quanta parte del lavoro ciascun database può svolgere autonomamente, ed è proprio questo che ottimizziamo e che viene mostrato nel piano di esecuzione. Quando il filtraggio e il raggruppamento avvengono interamente all'interno dei database, vengono trasferiti pochissimi dati e l'esecuzione risulta simile a una normale query. Quando è necessario completare un join di grandi dimensioni, vengono trasferiti più dati e il piano di esecuzione lo segnala prima dell'esecuzione. Ogni database ha inoltre un limite massimo per query, in modo che un errore venga bloccato tempestivamente anziché prolungare eccessivamente l'esecuzione.

Utilizza lo stesso modello di sicurezza di ogni altra query che esegui qui. Ogni elemento viaggia attraverso il tuo Network Agent su una connessione in uscita crittografata, senza porte in entrata, VPN o modifiche al firewall, e le credenziali del tuo database non lasciano mai la tua rete. Ogni elemento viene controllato in sola lettura (SELEZIONARE, CON, SPIEGARE), una query federata non può scrivere da nessuna parte e ogni database vede una query che accede solo alle colonne specificate.

L'idea è la stessa resa popolare da Trino e Presto: un'unica istruzione SQL, propagata a molteplici fonti. La differenza sta in ciò che devi gestire e imparare. Si tratta di cluster che si implementano, si ottimizzano e si integrano nella rete; le piattaforme di virtualizzazione dei dati aggiungono un livello di modellazione e una licenza corrispondente. La nostra soluzione offre la stessa funzionalità integrata nello strumento che il tuo team già utilizza per le query, raggiungendo le connessioni che hai già configurato, senza la necessità di gestire un server dedicato.

L'altra differenza è che noi ci rifiutiamo. Quando i database non concordano in un modo che potrebbe modificare un dato, ci fermiamo e indichiamo l'espressione che non siamo stati in grado di gestire, invece di restituire un valore plausibile.

Puoi fare tutto ciò che è possibile con una query salvata, perché di questo si tratta. Salvala, condividila con il tuo team, applica dei filtri, programma la sua invio come report a Slack o via email, pubblicala come endpoint REST oppure importa i risultati in Excel e Fogli Google. Nova può anche leggere i tuoi schemi e redigere l'istruzione se preferisci descrivere la domanda anziché scrivere le join.