Eén SQL-instructie over al uw databases.

Een gefedereerde query is één SQL-instructie die gegevens uit meerdere afzonderlijke databases leest en één gecombineerd resultaat oplevert. Er wordt niets eerst gekopieerd: uw instructie wordt opgesplitst in een kleine query per database, elke query beantwoordt het deel dat hij kan, en de delen worden samengevoegd tot het antwoord. In Query Streams wordt een instructie gefedereerd zodra deze twee of meer van uw verbindingen noemt.

Nee. Ze kunnen zich in verschillende kantoren, verschillende cloudaccounts, verschillende landen of een combinatie van alle drie bevinden — één in een serverruimte, één in een privécloudnetwerk, één op een machine in een magazijn. Elke locatie draait een netwerkagent en elke agent bereikt Query Streams door uit te bellen. Voor uw firewall is dat gewoon een normale uitgaande verbinding, dus er hoeft niets geopend te worden en er hoeft geen VPN te worden opgezet.

Je kunt ook meerdere databases op één server naar dezelfde agent laten verwijzen; één agent per locatie is gebruikelijk, niet één per database.

Niet voor dit doel. Er hoeft niets geladen te worden en er is geen schema om in de gaten te houden — de query leest uw live databases op het moment dat u deze uitvoert, dus het antwoord kan niet verouderd zijn zoals een kopie van gisteravond. Wat federatie niet vervangt, is zware historische analyses over zeer grote volumes; dat blijft de taak van een datawarehouse. Een grove test: als de vraag meerdere systemen omvat en actueel moet zijn, gebruik dan federatie.

Elk van uw databaseverbindingen, in elke combinatie: SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access en DuckDB. Elke database wordt benaderd in zijn eigen dialect, dus dezelfde instructie kan verschillende typen gegevens verzenden. BOVENKANT naar SQL Server en LIMIET naar PostgreSQL zonder dat u erover hoeft na te denken.

Databases verschillen daadwerkelijk in wat ze kunnen berekenen en hoe ze sorteren en afronden, waardoor niet elke combinatie van elke expressie exact beantwoord kan worden. In dat geval krijg je een specifiek bericht met de naam van de expressie, in plaats van een getal dat er bijna is.

Het hangt ervan af hoeveel werk elke database zelf kan doen – en dat is precies waar we op optimaliseren, en wat het uitvoeringsplan u ook laat zien. Wanneer het filteren en groeperen allemaal binnen uw databases plaatsvindt, wordt er weinig data verplaatst en voelt het aan als een normale query. Wanneer een grote join door ons moet worden afgerond, vindt er meer dataverplaatsing plaats, en het uitvoeringsplan geeft dit aan voordat u de query uitvoert. Elke database heeft ook een limiet per query, zodat een fout vroegtijdig wordt gestopt in plaats van dat het proces blijft voortduren.

Het maakt gebruik van hetzelfde beveiligingsmodel als elke andere query die u hier uitvoert. Elk onderdeel gaat via uw eigen netwerkagent over één versleutelde uitgaande verbinding — geen inkomende poort, geen VPN, geen firewallwijziging — en uw databasegegevens verlaten uw netwerk nooit. Elk onderdeel wordt alleen-lezen gecontroleerd (SELECT, MET, UITLEGGENEen gefedereerde query kan nergens naartoe schrijven, en elke database ziet alleen een query die de kolommen raakt die je hebt benoemd.

Het idee is hetzelfde als datgene dat Trino en Presto populair hebben gemaakt: één SQL-statement, doorgestuurd naar meerdere bronnen. Het verschil zit hem in wat je moet uitvoeren en leren. Dat zijn clusters die je moet implementeren, configureren en aansluiten op je netwerk; de data-virtualisatieplatforms voegen daar een modelleringslaag en een bijbehorende licentie aan toe. Onze oplossing biedt dezelfde functionaliteit binnen de tool die je team al gebruikt voor query's, en maakt gebruik van de verbindingen die je al hebt ingesteld, zonder dat je een eigen server hoeft te beheren.

Het andere verschil is dat we weigeren. Wanneer databases het oneens zijn op een manier die een cijfer zou kunnen veranderen, stoppen we en benoemen we de expressie die we niet konden verwerken in plaats van een plausibele oplossing terug te geven.

Je kunt alles doen met een opgeslagen query, want dat is het in feite. Sla hem op, deel hem met je team, voeg filters toe, plan hem in als rapport in Slack of via e-mail, publiceer hem als REST-endpoint of haal de resultaten op in Excel en Google Sheets. Nova kan ook je schema's lezen en de query opstellen als je de vraag liever beschrijft dan de joins zelf schrijft.