Wirtualizacja danych i zapytania federacyjne

Jedno polecenie SQL w poprzek wszystkie twoje bazy danych.

Twoje zamówienia są w MySQL. Twoi klienci są w PostgreSQL. Cele, o które wszyscy się spierają, znajdują się na serwerze SQL Server w centrali. zapytanie federacyjne pozwala napisać jeden zwykły SELECT który odczytuje wszystkie trzy naraz i udostępnia jedną tabelę — bez eksportów, bez kopiowania czegokolwiek i bez otwierania niczego nowego na zaporze sieciowej.

On every plan, including Free · Free runs 2 sources and 250 result rows — the ceilings grow with your tier

Jedno pole SQL, a nie konstruktor połączeń Bazy danych w różnych biurach, chmurach i krajach Nigdy nie ma reguły zapory przychodzącej Odmawia, zamiast zgadywać

38 łączniki bazy danych — połącz dowolne z nich w dowolnej kombinacji

Microsoft SQL ServerPostgreSQLMySQLMariaDBOraclePłatek śnieguGoogle BigQuerySQLiteMicrosoft AccessDuckDBSupabase

Obok nich w strumieniach zapytań: 8 Łączniki API, zapytania wykonywane przy użyciu tego samego kodu SQL

PasekHubSpotShopifyReklamy GoogleGoogle Analytics 4Google Search ConsoleShipStationiTick

53 źródeł w sumie. Łączniki API są przeszukiwane za pomocą SQL, tak jak wszystko inne — a instrukcja federacyjna łączy je baza danych znajomości. Zobacz złącze API

Wirtualizacja danych w jednym stwierdzeniu

Umieść nazwę połączenia przed tabelą

To jedyny nowy pomysł na tej stronie. Każda podświetlona poniżej nazwa to inna baza danych, w innym miejscu, dostępna dla innego agenta sieciowego — i nadal jest to jedno zapytanie.

przychody-według-regionu.sql 3 połączenia · 3 agentów · 1 oświadczenie
-- jedno zapytanie federacyjne · nic nigdzie nie kopiowane
SELECT   c.region,
         COUNT(*)      AS święcenia,
         SUMA(o.total)  AS przychody, cel t
Z     mysql_prod.zamówienia.sklepowe1 o
JOIN     pg_crm.publiczni.klienci2 c ON c.id = o.customer_id
JOIN     mssql_erp.dbo.region_targets3 t ON t.region = c.region
GDZIE    o.placed_at >= DATA '2026-07-01'
GROUP BY c.region, t.cel
ORDER BY przychód DESC;
Każda baza danych obsługuje: własne filtrowanie i grupowanie Zajmujemy się: połączenia między nimi i ich kolejność

mysql_prod, pg_crm oraz mssql_erp to po prostu nazwy, które nadałeś swoim powiązaniom — te trzy części to połączenie, schemat, tabela. To właśnie mają na myśli ludzie mówiąc federacyjna baza danych:trzy oddzielne bazy danych odpowiadające na jedno pytanie, bez łączenia i przenoszenia czegokolwiek. Schemat ilustracyjny; Twoje tabele będą Twoimi tabelami.

Gdzie każde imię się rozwiązuje

1 MySQL mysql_prod MySQL · shop.orders Agent w chmurze Filtruje według lipca, a następnie sumuje przychody na klienta przed wysłaniem czegokolwiek.
2 PostgreSQL pg_crm PostgreSQL · public.customers Agent regionalny Zwraca tylko kolumny id i region — jedyne dwie to nazwy zapytań.
3 Microsoft SQL Server mssql_erp SQL Server · dbo.region_targets Agent centrali Przekazuje cel na region, napisany jako T-SQL, dzięki czemu działa natywnie.

Trzech agentów, trzy sieci, jedno oświadczenie — i żadna z nich nie otworzyła portu, aby to zrobić.

Co się nie zmienia

Większy zasięg, nie większa ekspozycja

Odczyt dwóch baz danych jednocześnie przebiega dokładnie tą samą ścieżką, co odczyt jednej. Nie otwiera to niczego nowego, co mogłoby je otworzyć.

Tylko wysyłka

Agent otwiera jedno szyfrowane połączenie do Query Streams i przesyła przez nie zarówno żądanie, jak i wyniki. Bez portu przychodzącego, bez VPN, bez zmiany zapory sieciowej — a Twoje dane uwierzytelniające nigdy nie opuszczają sieci.

Tylko do odczytu, każdy element

Każda część zapytania jest sprawdzana przed jego wysłaniem: SELECT, Z oraz WYJAŚNIĆ Zapytanie federacyjne nie może zapisać danych do żadnej z Twoich baz danych, a odrzucone dane w ogóle do nich nie docierają.

Nie może uciec z twojego serwera

Istnieje limit danych, jakie jedna baza danych może przekazać w ramach jednego zapytania, a agent zatrzymuje się w momencie jego osiągnięcia. Błąd w GDZIE klauzula ta kosztuje Cię komunikat o błędzie, a nie popołudnie.

Jak to działa

Trzy kroki, z których żaden nie jest kanałem danych

01

Wybierz swoje połączenia

Wybierz co najmniej dwa połączenia, które Twój zespół już skonfigurował. Dwa to minimum — to właśnie one decydują o federacji zapytania. Nic nie zostanie skopiowane i nie zostaną utworzone żadne nowe hasła.

02

Napisz jedno stwierdzenie

Nadaj każdej tabeli nazwę połączenie.schema.table, a następnie napisz normalny kod SQL. Przed uruchomieniem możesz zapoznać się z planem: do której bazy danych jest kierowane pytanie. Możesz też opisać pytanie i pozwolić Novie je opracować.

03

Zapisz jak każde inne zapytanie

Po uruchomieniu zapytanie zostaje zapisane — można je więc udostępniać, stosować filtry, wysyłać jako cotygodniowy raport, publikować jako punkt końcowy interfejsu API lub wczytywać do arkusza kalkulacyjnego.

Dlaczego jest szybki

Każda baza danych wykonuje swoją część pracy

Leniwym sposobem na połączenie dwóch baz danych jest przeciągnięcie obu tabel przez sieć i późniejsze uporządkowanie. To powolne i oznacza, że z budynku opuszcza znacznie więcej danych, niż jest to potrzebne.

Robimy więc odwrotnie. Filtrowanie, wybieranie kolumn i zliczanie sum jest przekazywane powrót do każdej bazy danych, aby wykonać ją samodzielnie, w swoim własnym języku. Raport grupujący miliony wierszy odsyła garść zgrupowanych sum — a nie miliony rzędów za nimi.

Cokolwiek zostanie, robimy to — i pokazujemy, co jest co. Łączenie baz danych to nasze zadanie, ponieważ żadna z nich nie widzi pozostałych. Plan określa, o co poproszono każdą bazę danych i co zrobiliśmy, więc kosztowne zapytanie jest oczywiste. zanim ty to uruchamiasz.

POWOLNA DROGA cały stół podróżuje przefiltruj tutaj ZAPYTANIE PRZENOSI SIĘ DROGA filtr + suma w bazie danych 12 rzędów ścieg jedna odpowiedź
Szczera odpowiedź

Wolałby odmówić, niż po cichu się mylić

Oto niewygodna prawda o łączeniu oddzielnych baz danych: nie zawsze się one ze sobą zgadzają. Dwóm z nich można zadać to samo pytanie i otrzymać odpowiedzi różniące się ostatnim miejscem po przecinku, tym, co uznaje się za równe, lub znaczeniem „pierwszej dziesiątki”.

Jeśli jesteś nowy, oto krótka wersja: Baza danych to nie tylko zbiór wierszy. Ma własne zdanie na temat tego, jak sumować pieniądze, jak sortować słowa i gdzie powinny znajdować się puste wartości. Poproś dwie różne bazy danych o posortowanie tej samej listy nazwisk klientów, a otrzymasz dwa różne zamówienia — nie dlatego, że jedno jest zepsute, ale dlatego, że zostały zbudowane według innych reguł. Każde narzędzie łączące bazy danych musi sobie z tym poradzić. Większość po cichu wybiera jedną odpowiedź i ma nadzieję. My nie.

To, co robimy, ma dokładnie dwa rezultaty, a Kreator zapytań pokazuje, który z nich posiadasz: plan w formie pigułki, który wyświetla komunikat o gotowości lub odmowie w trakcie pisania, oraz zakładkę Plan z pełnym działaniem.

Zwykle: po prostu robimy to sami

Kiedy nieporozumienie dotyczy Jak Po wykonaniu obliczeń przestajemy prosić bazę danych o wykonanie tej części i wykonujemy ją w kroku łączenia, gdzie obowiązuje jeden spójny zestaw reguł. To trochę obniża prędkość. Nie kosztuje Cię to dokładności ani uwagi — nie jesteś proszony o nic.

  • Pieniądze i precyzja. Bazy danych rozszerzają się i zaokrąglają ułamki dziesiętne inaczej, gdy sumy stają się duże. Jeśli sumowanie w źródle mogłoby zaokrąglać inaczej niż sumowanie centralne, przywracamy liczby i dodajemy je sami.
  • Sortowanie tekstu. Czy a przychodzi przed B, a także sposób porównywania akcentów, to ustawienie zależne od bazy danych. Porównania, które od niego zależą, są ustalane centralnie, a nie przenoszone.
  • Ranking i sumy bieżące. Funkcje okna — numery wierszy, sumy bieżące, „najlepsze 3 na region” — są zawsze obliczane po dostarczeniu elementów, ponieważ żadne pojedyncze źródło nie widzi pozostałych.
Czasami: zatrzymujemy się i mówimy ci

Kiedy kontynuowanie ulegnie zmianie które wiersze wróć – nie tylko jak szybko – nie ma pewnego sposobu, aby to zgadnąć. Zapytanie nie zostanie wykonane, a komunikat będzie zawierał nazwę dokładnego wyrażenia i dokładną bazę danych w Twoim własnym SQL, dzięki czemu będziesz wiedział, co edytować.

  • Funkcja, której źródło nie może wykonać. Jeśli Twój filtr używa czegoś, czego nie możemy wiernie wyrazić w dialekcie tej bazy danych, jedynym rozwiązaniem jest wysłanie szerszego zapytania niż to, które napisałeś, lub wymyślenie odpowiednika. Obie odpowiedzi są błędne, więc odmawiamy.
  • Limity wierszy wewnątrz utworu. A LIMIT lub SZCZYT Zastosowana do jednego źródła przed połączeniem zwraca dowolną liczbę wierszy, a następnie łączy je — wiarygodnie wyglądającą tabelę bezsensownych danych. Limity należą do gotowego wyniku.
  • Przesunięta bramka. Jeśli połączenie zostało przekierowane do innej bazy danych od czasu zaplanowania zapytania, zapisany plan jest nieaktualny i prosimy o ponowne zaplanowanie, zamiast uruchamiać wczorajszy plan na podstawie dzisiejszych danych.

Trzy odmowy i co każda z nich oznacza

Odrzucony

Nie można pchać NIŻSZE(c.email_domain) = ? do mssql_erp: funkcja nie znajduje się na liście dozwolonych funkcji pushdown.

Innymi słowy: Twój filtr opakowuje kolumnę w funkcję, której nie można zaufać, że zastosuje ją w taki sam sposób, w jaki zrobilibyśmy to my, więc nie możemy zagwarantować, że zwróci te same wiersze. Co zrobić: zamiast tego porównaj zwykłą kolumnę lub przenieś ten warunek poza źródło — komunikat podpowie Ci, na które źródło należy zwrócić uwagę.

Odrzucony

LIMIT 100 nie można zastosować do pojedynczego źródła przed połączeniem: wynikiem byłoby 100 dowolnych wierszy, a nie pierwsze 100 odpowiedzi.

Innymi słowy: „pierwsze 100” ma znaczenie dopiero wtedy, gdy wszystko zostanie połączone i posortowane. Co zrobić: pozostaw limit na całym oświadczeniu, czyli tam, gdzie zostanie osiągnięte to, czego oczekujesz.

Wymaga ponownego planowania

Źródło 2 wskazuje teraz na inne połączenie lub bazę danych niż w momencie planowania tego zapytania.

Innymi słowy: ktoś zmienił co pg_crm odnosi się do. Co zrobić: otwórz go w Kreatorze zapytań i zaplanuj ponownie — jednym kliknięciem możesz zobaczyć nowy plan przed jego uruchomieniem.

Zasada, która za tym wszystkim stoi: jeśli zapytanie zostanie zwrócone zło, odmawiamy. Jeśli to po prostu wróci powoli, uruchamiamy go i ostrzegamy. Błędne dane nigdy nie są kompromisem, który zawieramy w Twoim imieniu.

Nie musisz sam rozwiązywać problemu odmowy. Nova siedzi obok edytora w Kreatorze Zapytań i płynnie posługuje się całym tym systemem: zapytaj, a on wyjaśni odmowę prostymi słowami, przepisze zapytanie, aby zostało wykonane, i sprawdzi nowy plan. A jeśli wolisz w ogóle pominąć pisanie SQL, opisz pytanie, a Nova sama utworzy sfederowane zapytanie.

A dla tych, którzy wolą szczegóły niż pewność: karta Plan w Kreatorze zapytań zawiera listę wszystkich źródeł, zapytanie, do którego zostało wysłane, które z warunków zostało zastosowane samodzielnie oraz które części zostały dokończone centralnie. Nic w decyzji nie jest ukryte — nawet te części, w których wybraliśmy wolniejszą, bezpieczniejszą trasę.

Nic nie jest przypadkiem szczególnym

Zapytanie federacyjne to po prostu zapytanie

Nie jest to oddzielny produkt z własnymi regułami. Po zapisaniu, każda inna część Query Streams traktuje go jak wszystko inne, co napisałeś.

Kreator zapytań

Napisz to w tym samym edytorze, mając obok siebie to samo drzewo schematów. Karta Plan pokazuje, o co poproszono każdą bazę danych; karta Insights przedstawia wykresy wydajności każdej z nich.

Nova AI

Nova AI

Opisz pytanie po angielsku, a Nova odczyta Twoje schematy i utworzy szkic oświadczenia – uwzględniając, do którego połączenia należy każda tabela. Może je również uruchomić i przedstawić wynik na wykresie.

Arkusze Google

Arkusze Google

Wybierz zapisane zapytanie w dodatku, a połączone wyniki pojawią się w Twoich komórkach, sformatowane i odświeżalne — tak samo jak w przypadku dowolnego zapytania do pojedynczej bazy danych.

Microsoft Excel

Excel

Podobnie jest w programie Excel: możesz uruchomić jeden arkusz lub cały arkusz z zamrożonymi nagłówkami, filtrami i aktualizacjami na miejscu, które nie zmieniają kolumn formuł.

Interfejs API REST

API REST bazy danych

Opublikuj wynik międzybazowy jako punkt końcowy JSON z kluczem. Dzięki temu osoba, która go wykorzysta, nie będzie musiała wiedzieć, że pochodzi on z trzech systemów.

MCP

MCP dla asystentów AI

Claude i inni asystenci mogą wyświetlać i uruchamiać Twoje zapytania federacyjne za pośrednictwem MCP, dzięki czemu na pytanie „jak radziły sobie poszczególne regiony w zeszłym tygodniu” można odpowiedzieć na czacie.

Raporty i alerty

Ustaw harmonogram, a łączne liczby zostaną przesłane na Slacka, Google Chat, Discorda, Telegrama lub e-mail — możesz też ustalić próg i otrzymywać informacje dopiero wtedy, gdy coś się zmieni.

Automatyzacja i udostępnianie

Synchronizuj wyniki z arkuszem kalkulacyjnym zgodnie z harmonogramem lub udostępnij zapytanie współpracownikowi, który widzi tylko filtry i przycisk Uruchom — nigdy Twoje zapytanie SQL ani połączenia.

Gdzie zarabia na swoje utrzymanie

Raporty, które kiedyś składały się z dwóch eksportów i funkcji WYSZUKAJ.PIONOWO

Prawie nikt nie ma jednej bazy danych. Jest ERP, sklep, CRM i cokolwiek, na czym opierało się ostatnie przejęcie.

Zamówienia tutaj, klienci tam

Sklep zapisuje zamówienia w MySQL; CRM przechowuje klientów i regiony w PostgreSQL. „Przychody według regionu” nie ograniczają się do dwóch eksportów i wyszukiwania, lecz stają się jednym zapisanym zapytaniem, które każdy może ponownie uruchomić.

Po przejęciu

Dwie firmy, dwa stosy, jeden pakiet płyt w piątek. Połączony widok otrzymasz już pierwszego dnia, podczas gdy prawdziwa migracja zajmie osiemnaście miesięcy, jak zwykle.

Zapasy w stosunku do wyprzedaży

Stan zapasów jest na bieżąco rejestrowany w systemie magazynowym w innym kraju, a sprzedaż w bazie danych sklepu. Jedno zestawienie pozwala je ze sobą zestawić – a to samo zestawienie może następnie docierać w każdy poniedziałek w formie raportu.

Jedna baza danych na witrynę, jeden numer

Ten sam schemat wdrożony dla każdego kraju, najemcy lub hali produkcyjnej. Zsumuj je w jednym poleceniu, zamiast tworzyć skrypt, który uruchamia zapytanie pięć razy i ręcznie je sumuje.

Proste definicje

Baza danych federacyjna, federacja danych, wirtualizacja danych

Trzy nazwy na zazębiające się idee, a marketing je zatarł. Oto, co każda z nich oznacza i co tak naprawdę robimy.

01

Zintegrowana baza danych

A federacyjna baza danych (lub federacyjny system baz danych) sprawia, że kilka oddzielnych baz danych zachowuje się jak jedna, bez ich scalania. Każda z nich ma własną pamięć masową, własny silnik i własnego właściciela; warstwa nad nimi przejmuje zapytanie i ustala, kto odpowiada na którą część.

Ta warstwa to właśnie Query Streams. Pod nią nie ma żadnej nowej bazy danych i nic nie jest do niej kopiowane.

02

Federacja danych

Federacja danych To podejście samo w sobie: pozostaw dane tam, gdzie zostały zapisane, i przeszukuj je, gdy ich potrzebujesz, zamiast najpierw wyodrębniać wszystko do centralnej kopii. Alternatywą jest potok danych i magazyn danych – przenieś wszystko w ciągu nocy, a następnie przeszukuj tylko kopię.

Oba są uzasadnione. Federacja wygrywa, gdy pytanie obejmuje wiele systemów, gdy dane muszą pozostać w jednym miejscu lub gdy projekt hurtowni danych kosztowałby więcej niż odpowiedź jest warta. Hurtownia danych nadal wygrywa w przypadku obszernych analiz historycznych na ogromnych wolumenach.

03

Wirtualizacja danych

Wirtualizacja danych jest większą kategorią przedsiębiorstw opartą na federacji — zwykle obejmującej federacyjne zapytania plus warstwę modelowania, buforowanie i narzędzia zarządzania, sprzedawane jako osobna platforma.

Jesteśmy świadomie wąskim, uczciwym wycinkiem tego: federacyjne zapytania dotyczące połączeń, które już posiadasz, w narzędziu, w którym Twój zespół już pisze zapytania. Bez projektu modelowania, bez własnego serwera do uruchomienia, bez konsultantów.

Często zadawane pytania dotyczące zapytań federacyjnych

Czym jest zapytanie federacyjne?

Zapytanie federacyjne to jedno polecenie SQL, które odczytuje dane z więcej niż jednej oddzielnej bazy danych i zwraca jeden, połączony wynik. Nic nie jest najpierw kopiowane: polecenie jest dzielone na małe zapytania dla każdej bazy danych, z których każde odpowiada na część, na którą może odpowiedzieć, a następnie fragmenty są łączone w odpowiedź. W strumieniach zapytań polecenie staje się federacyjne, gdy tylko nazwie dwa lub więcej połączeń.

Czy moje bazy danych muszą znajdować się w tym samym miejscu?

Nie. Mogą znajdować się w różnych biurach, na różnych kontach w chmurze, w różnych krajach lub w kombinacji wszystkich trzech – jeden w serwerowni, jeden w prywatnej sieci chmurowej, jeden na komputerze w magazynie. W każdej lokalizacji działa agent sieciowy, a każdy agent uzyskuje dostęp do strumieni zapytań poprzez wybieranie numeru. Z punktu widzenia zapory sieciowej jest to zwykłe połączenie wychodzące, więc nie ma potrzeby niczego otwierać ani budowania sieci VPN.

Można również wskazać kilka baz danych na jednym serwerze temu samemu agentowi; standardowo na jedną lokalizację przypada jeden agent, a nie jeden na bazę danych.

Czy potrzebuję również magazynu danych lub procesu ETL?

Nie w tym celu. Nie ma niczego do załadowania ani harmonogramu do pilnowania — zapytanie odczytuje bazy danych w momencie uruchomienia, więc odpowiedź nie może być nieaktualna, tak jak wczorajsza kopia. Federacja nie zastępuje jednak gruntownej analizy historycznej na bardzo dużych wolumenach; to wciąż zadanie magazynu danych. Prosty test: jeśli pytanie obejmuje wiele systemów i musi być aktualne, należy je zfederalizować.

Które bazy danych mogę łączyć?

Dowolne połączenie z bazą danych, w dowolnej konfiguracji: SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access i DuckDB. Każda baza danych jest wysyłana w osobnym dialekcie, więc to samo polecenie może zostać wysłane. SZCZYT do serwera SQL i LIMIT do PostgreSQL bez Twojego udziału.

Bazy danych różnią się pod względem tego, co potrafią obliczyć, oraz sposobu sortowania i zaokrąglania, więc nie na każdą kombinację każdego wyrażenia można odpowiedzieć dokładnie. W takim przypadku otrzymujesz konkretny komunikat z nazwą wyrażenia, a nie liczbę, która jest niemal poprawna.

Czy jest to wolniejsze niż zapytanie do jednej bazy danych?

Zależy to od tego, ile pracy każda baza danych może wykonać samodzielnie – a to właśnie optymalizujemy i dokładnie to pokazuje plan. Gdy filtrowanie i grupowanie odbywa się w bazach danych, niewiele danych jest przenoszonych i wygląda to jak normalne zapytanie. Gdy musimy dokończyć duże łączenie, przenosimy więcej danych, a plan to uwzględnia przed jego uruchomieniem. Każda baza danych ma również limit na zapytanie, więc błąd jest zatrzymywany na wczesnym etapie, zamiast się rozpędzać.

Czy bezpieczne jest kierowanie jednego zapytania do kilku baz danych produkcyjnych?

Korzysta z tego samego modelu bezpieczeństwa, co każde inne zapytanie, które tutaj uruchamiasz. Każdy element przechodzi przez Twojego własnego agenta sieciowego za pośrednictwem jednego szyfrowanego połączenia wychodzącego — bez portu przychodzącego, bez VPN, bez zmiany zapory sieciowej — a Twoje dane uwierzytelniające do bazy danych nigdy nie opuszczają Twojej sieci. Każdy element jest sprawdzany tylko do odczytu (SELECT, Z, WYJAŚNIĆ), zapytanie federacyjne nie może nigdzie zapisać, a każda baza danych widzi tylko zapytanie dotyczące wskazanych kolumn.

Czym to się różni od Trino, Presto lub Denodo?

Pomysł jest taki sam, jak ten, który spopularyzowały Trino i Presto: jedno polecenie SQL, przesyłane do wielu źródeł. Różnica polega na tym, czego trzeba uruchomić i czego trzeba się nauczyć. To klastry, które wdrażasz, dostrajasz i podłączasz do swojej sieci; platformy wirtualizacji danych dodają warstwę modelowania i odpowiednią licencję. Nasza funkcjonalność jest taka sama, jak ta, którą oferuje narzędzie, z którego korzysta już Twój zespół, docierając do połączeń, które już skonfigurowałeś, bez konieczności obsługi własnego serwera.

Drugą różnicą jest to, że odmawiamy. Gdy bazy danych nie zgadzają się w sposób, który mógłby zmienić wartość, zatrzymujemy się i podajemy nazwę wyrażenia, którego nie mogliśmy obsłużyć, zamiast zwracać coś prawdopodobnego.

Co mogę zrobić z wynikiem?

Wszystko, co możesz zrobić z dowolnym zapisanym zapytaniem, bo właśnie tym ono jest. Zapisz je, udostępnij zespołowi, dodaj filtry, zaplanuj raport w Slacku lub e-mailu, opublikuj jako punkt końcowy REST lub pobierz wyniki do Excela i Arkuszy Google. Nova może również odczytać Twoje schematy i utworzyć wersję roboczą zapytania, jeśli wolisz opisać pytanie zamiast pisać łączenia.

Twoje bazy danych pozostają tam, gdzie są. Pytanie przestaje być istotne.

Nazwij dwa połączenia, napisz jedno oświadczenie, przeczytaj plan przed jego uruchomieniem. Bez potoku, bez magazynu, bez zgłoszenia do zapory sieciowej.

Federated queries are on every plan, including Free