데이터 가상화 및 연합 쿼리

하나의 SQL 문 모든 데이터베이스.

주문 정보는 MySQL에 있습니다. 고객 정보는 PostgreSQL에 있습니다. 모두가 논쟁하는 타겟 데이터는 본사의 SQL Server에 저장되어 있습니다. 연합 쿼리 평범한 글을 하나 쓸 수 있게 해줍니다 선택 이 기능은 세 가지를 한 번에 읽어 하나의 표로 정리해 줍니다. 내보내기도 필요 없고, 어디에도 복사할 것이 없으며, 방화벽에서 새로 열어야 할 파일도 없습니다.

무료 티어 체험하기 팀 요금제

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

SQL 서버 하나만 사용하는 것이지, 조인 빌더를 사용하는 것이 아닙니다. 서로 다른 사무실, 클라우드 및 국가에 있는 데이터베이스 인바운드 방화벽 규칙은 절대 없습니다. 추측하기보다는 거절한다.

38 데이터베이스 커넥터 — 어떤 조합으로든 이들 간에 조인할 수 있습니다.

쿼리 스트림에서 그들과 함께: 8 API 커넥터는 동일한 SQL로 쿼리됩니다.

53 총 소스 수입니다. API 커넥터는 다른 모든 것과 마찬가지로 SQL로 쿼리되며, 연합 문은 소스를 조인합니다. 데이터 베이스 사이. API 커넥터를 참조하세요.

데이터 가상화, 한마디로 설명하자면

테이블 앞에 연결 이름을 붙이세요.

이 페이지에서 새롭게 제시된 내용은 이것뿐입니다. 아래 강조 표시된 각 이름은 서로 다른 위치에 있는 서로 다른 데이터베이스이며, 서로 다른 네트워크 에이전트를 통해 접근되지만, 여전히 하나의 쿼리로 처리됩니다.

지역별 수익.sql 연결 3개 · 에이전트 3개 · 문장 1개

-- 하나의 연합 쿼리 · 어디에도 복사된 내용 없음
선택   c.지역,
         COUNT(*)      AS 명령,
         SUM(o.total)  AS 수익, t.target
FROM     mysql_prod.shop.orders1 o
JOIN     pg_crm.공개.고객2 c 켜기 c.id = o.customer_id
JOIN     mssql_erp.dbo.region_targets3 t 켜기 t.region = c.region
어디    o.placed_at >= 날짜 '2026-07-01'
그룹 기준 c.지역, t.대상
주문 기준 수익 DESC;

각 데이터베이스는 다음을 처리합니다. 자체 필터링 및 그룹화 저희가 담당하는 분야는 다음과 같습니다: 그들 사이의 연결과 순서

mysql_prod, pg_crm 그리고 mssql_erp 이것들은 단순히 여러분이 여러분의 인맥에 붙인 이름일 뿐입니다. 세 부분은 다음과 같습니다. 연결, 스키마, 테이블이것이 사람들이 말하는 의미입니다. 연합 데이터베이스하나의 질문에 답하는 세 개의 개별 데이터베이스이며, 병합이나 이동은 없습니다. 이는 예시적인 스키마이며, 테이블 구조는 사용자 환경에 따라 달라집니다.

각 이름이 해석되는 곳

mysql_prod MySQL · shop.orders 클라우드 에이전트 7월로 필터링한 다음, 고객별 총 수익을 계산한 후 발송합니다.

pg_crm 포스트그레스 SQL · 공개 고객 지역 담당자 쿼리 이름인 id와 region 두 열만 반환합니다.

mssql_erp SQL Server · dbo.region_targets 본사 대리점 각 지역별 목표값을 T-SQL 형식으로 작성하여 제공하므로 네이티브에서 실행됩니다.

세 명의 에이전트, 세 개의 네트워크, 하나의 명령문 — 그런데 그 누구도 이를 위해 포트를 열지 않았습니다.

변하지 않는 것

노출 증가가 아닌 도달 범위 확대

두 개의 데이터베이스를 동시에 읽는 것은 하나의 데이터베이스를 읽는 것과 완전히 동일한 경로를 사용합니다. 이를 위해 새로운 경로를 열 필요는 없습니다.

출국 전용

에이전트는 Query Streams로 암호화된 연결을 하나 열고 요청과 결과를 모두 해당 연결을 통해 전송합니다. 인바운드 포트, VPN, 방화벽 변경이 필요 없으며, 사용자 자격 증명은 네트워크 외부로 유출되지 않습니다.

읽기 전용, 모든 항목

쿼리의 각 부분은 전송되기 전에 검사됩니다. 선택, 와 함께 그리고 설명하다 연합 쿼리는 데이터베이스에 쓰기 작업을 수행할 수 없으며, 거부된 요청은 해당 데이터베이스에 전혀 도달하지 않습니다.

그것은 당신의 서버와 함께 도망갈 수 없습니다.

데이터베이스가 단일 쿼리에 대해 제공할 수 있는 데이터 양에는 상한선이 있으며, 그 상한선에 도달하는 순간 에이전트는 작동을 멈춥니다. 오류가 발생하면... 어디 해당 조항 때문에 오류 메시지가 표시될 뿐, 시간을 허비할 필요는 없습니다.

작동 방식

세 단계 중 어느 단계도 데이터 파이프라인이 아닙니다.

인맥을 선택하세요

팀에서 이미 설정한 연결 중 두 개 이상을 선택하세요. 최소 두 개 이상이어야 쿼리가 페더레이션됩니다. 데이터가 복사되거나 새 암호가 생성되지 않습니다.

한 문장을 쓰세요

각 테이블의 이름을 다음과 같이 지정하세요. 연결.스키마.테이블그런 다음 일반 SQL을 작성하세요. 실행하기 전에 실행 계획을 확인할 수 있습니다. 어떤 데이터베이스에 어떤 작업을 요청하는지 알 수 있습니다. 또는 질문을 설명하여 Nova가 실행 계획을 작성하도록 할 수도 있습니다.

다른 쿼리처럼 저장하세요.

한 번 성공하면 해당 쿼리는 저장되므로 공유하거나, 필터를 적용하거나, 주간 보고서로 보내거나, API 엔드포인트로 게시하거나, 스프레드시트로 가져올 수 있습니다.

왜 빠른가

각 데이터베이스는 나름대로의 역할을 수행합니다.

두 데이터베이스를 결합하는 가장 쉬운 방법은 두 테이블을 네트워크를 통해 끌어다 놓고 나중에 정렬하는 것입니다. 하지만 이 방법은 속도가 느릴 뿐만 아니라, 필요한 데이터보다 훨씬 더 많은 데이터가 건물 밖으로 유출된다는 것을 의미합니다.

그래서 우리는 정반대로 합니다. 필터링, 열 선택, 합계 계산은 모두 우리가 처리합니다. 각 데이터베이스로 돌아가서 자체적으로 처리하도록 합니다.그 자체 언어로. 수백만 개의 행을 그룹화하는 보고서는 다음과 같은 내용을 반환합니다. 그룹화된 총계 몇 개 — 그들 뒤에 있는 수백만 줄의 줄이 아니라요.

남은 것은 저희가 처리하고, 어떤 것이 어떤 것인지 보여드리겠습니다. 데이터베이스 간의 조인은 우리의 역할입니다. 왜냐하면 어떤 데이터베이스도 다른 데이터베이스를 직접 볼 수 없기 때문입니다. 실행 계획에는 각 데이터베이스에 요청된 데이터와 우리가 완료한 작업이 명확하게 나와 있으므로 비용이 많이 드는 쿼리를 쉽게 파악할 수 있습니다. ~ 전에 당신이 운영하세요.

솔직한 답변

조용히 틀렸다는 것을 인정하기보다는 차라리 거부하는 쪽을 택할 것이다.

서로 다른 데이터베이스를 결합할 때 발생하는 불편한 진실은 바로 두 데이터베이스의 결과가 항상 일치하지는 않는다는 것입니다. 동일한 질문에 대해 두 데이터베이스가 서로 다른 소수점 자릿수, 동일하다고 간주하는 기준, 또는 "처음 10개"의 의미 등에서 차이를 보이는 결과를 도출할 수 있습니다.

이 분야에 처음이시라면, 간단히 설명해 드리겠습니다. 데이터베이스는 단순히 행들의 집합이 아닙니다. 금액을 계산하는 방법, 단어를 정렬하는 방법, 빈 값을 처리하는 방법 등 데이터베이스 고유의 규칙이 존재합니다. 서로 다른 두 데이터베이스에 동일한 고객 이름 목록을 정렬하도록 요청하면 실제로 두 가지 다른 결과가 나올 수 있습니다. 이는 한쪽이 고장 나서가 아니라, 두 데이터베이스가 서로 다른 규칙으로 구축되었기 때문입니다. 데이터베이스를 결합하는 모든 도구는 이러한 문제를 처리해야 합니다. 대부분은 조용히 하나의 해답을 선택하고 결과를 기대하지만, 우리는 그렇게 하지 않습니다.

우리가 대신하는 행동은 정확히 두 가지 결과를 낳습니다. 쿼리 빌더는 입력하는 동안 '준비됨' 또는 '거부됨'이라고 표시되는 플랜 필드와 전체 작업 내용이 포함된 플랜 탭을 통해 어떤 결과가 나왔는지 보여줍니다.

보통은 저희가 직접 합니다.

의견 차이가 있을 때 어떻게 계산이 완료되면 데이터베이스에 해당 부분을 요청하는 대신, 일관된 규칙 세트가 적용되는 스티치 단계에서 처리합니다. 속도가 약간 느려질 수는 있지만, 정확도나 사용자의 주의를 전혀 요구하지 않습니다. 사용자는 아무것도 할 필요가 없습니다.

돈과 정확성. 데이터베이스는 합계가 커지면 소수점 이하 자릿수를 늘리거나 반올림하는 방식이 다릅니다. 내부적으로 합산하는 방식과 중앙에서 합산하는 방식이 반올림 방식이 다를 경우, 해당 데이터를 다시 가져와서 직접 합산합니다.
텍스트 정렬 중. 이든 a 먼저 온다 B그리고 억양 비교 방식은 데이터베이스별 설정입니다. 이에 의존하는 비교는 중앙에서 결정되며, 하위 그룹으로 전달되지 않습니다.
순위 및 누적 합계. 행 번호, 누적 합계, "지역별 상위 3개"와 같은 윈도우 함수는 어떤 소스도 다른 소스를 볼 수 없기 때문에 항상 데이터가 도착한 후에 계산됩니다.

때때로 우리는 멈춰서 당신에게 말합니다.

계속 진행하면 변화가 생길 것입니다. 어떤 행들 응답 시간뿐 아니라 응답 시간까지 정확히 예측할 수 없기 때문에 쿼리가 실행되지 않습니다. 따라서 오류 메시지에는 사용자의 SQL 쿼리에서 정확한 표현식과 데이터베이스 이름이 표시되므로 어떤 부분을 수정해야 하는지 알 수 있습니다.

소스 코드가 수행할 수 없는 기능입니다. 만약 필터에 사용된 어떤 요소가 해당 데이터베이스의 방언으로 정확하게 표현될 수 없다면, 유일한 대안은 작성하신 쿼리보다 더 광범위한 쿼리를 보내거나 그와 동등한 기능을 하는 쿼리를 새로 만드는 것뿐입니다. 하지만 두 가지 모두 잘못된 해결책이므로, 저희는 이를 거부합니다.
조각 내부의 행 제한. A LIMIT 또는 맨 위 조인 전에 하나의 소스에 적용하면 임의의 몇 개의 행이 반환된 다음, 이들을 조인하여 그럴듯해 보이지만 의미 없는 테이블을 생성합니다. 제한 사항은 최종 결과에 적용됩니다.
목표가 바뀌었다. 쿼리가 계획된 이후 연결이 다른 데이터베이스를 가리키도록 변경된 경우, 저장된 계획은 최신 상태가 아니므로 어제의 계획을 오늘의 데이터에 대해 실행하는 대신 새 계획을 요청합니다.

세 번의 거절과 각각의 거절이 당신에게 말해주는 것

거부됨

밀 수 없습니다 LOWER(c.email_domain) = ? mssql_erp로 이동: 함수가 푸시다운 허용 목록에 없습니다.

다시 말해서: 필터가 열을 함수로 감싸고 있는데, 소스에서 해당 함수를 우리가 적용하는 방식과 동일하게 적용할 것이라고 보장할 수 없으므로 동일한 행을 반환한다고 보장할 수 없습니다. 해야 할 일: 대신 일반 열을 비교하거나 해당 조건을 소스 외부로 이동하세요. 메시지에 어떤 소스를 확인해야 하는지 나와 있습니다.

거부됨

제한 100 조인 전에 단일 소스에 적용할 수 없습니다. 결과는 응답의 처음 100개가 아니라 임의의 100개 행이 될 것입니다.

다시 말해서: "선착순 100인"이라는 말은 모든 것이 연결되고 정리된 후에야 비로소 의미를 갖습니다. 해야 할 일: 전체 문장에 제한을 두세요. 그러면 예상대로 작동할 겁니다.

재계획이 필요합니다

소스 2는 이제 이 쿼리가 계획되었을 때와는 다른 연결 또는 데이터베이스를 가리킵니다.

다시 말해서: 누군가가 무엇을 바꿨습니다 pg_crm ~을 가리킨다. 해야 할 일: 쿼리 빌더에서 열고 다시 계획을 세우세요. 한 번의 클릭으로 실행하기 전에 새 계획을 확인할 수 있습니다.

이 모든 것의 근본 규칙은 다음과 같습니다. 만약 쿼리 결과가 돌아온다면 잘못된우리는 거부합니다. 만약 그것이 단지 돌아오기만 한다면. 느리게저희가 해당 데이터를 분석하여 경고해 드립니다. 잘못된 데이터는 저희가 고객님을 위해 감수하는 절대적인 타협점이 아닙니다.

거절을 혼자서 해결해야 하는 것도 아닙니다. Nova는 쿼리 빌더에서 편집기 옆에 앉아 이 시스템 전체를 유창하게 구사합니다. 질문을 하면 거부 사유를 명확하게 설명하고, 실행 가능한 쿼리문을 다시 작성해 주며, 새로운 실행 계획까지 확인해 줍니다. SQL 쿼리를 직접 작성하고 싶지 않다면 질문을 설명하기만 하면 Nova가 연합 쿼리문을 자동으로 생성해 줍니다.

안심시키는 것보다 자세한 내용을 원하시는 분들을 위해 말씀드리자면, 쿼리 빌더의 계획 탭에서 모든 소스, 실제로 전송된 쿼리, 자체적으로 적용된 조건, 그리고 중앙에서 마무리 처리한 부분을 모두 확인할 수 있습니다. 더 느리지만 안전한 경로를 선택한 부분을 포함하여 모든 결정 과정이 투명하게 공개됩니다.

어떤 것도 특별한 경우가 아닙니다.

연합 쿼리는 단순한 쿼리입니다.

이는 별도의 규칙을 가진 독립적인 제품이 아닙니다. 일단 저장되면 Query Streams의 다른 모든 부분에서 사용자가 작성한 다른 코드와 마찬가지로 처리합니다.

쿼리 빌더

동일한 편집기에서 스키마 트리를 옆에 두고 작성하세요. '계획' 탭에는 각 데이터베이스에 요청된 내용이 표시되고, '통찰력' 탭에는 각 데이터베이스의 성능이 차트로 나타납니다.

Nova AI

질문을 영어로 설명하면 Nova가 스키마를 읽고 각 테이블이 어떤 연결에 속하는지 등을 포함하여 명령문을 작성합니다. 또한 명령문을 실행하고 결과를 차트로 표시할 수도 있습니다.

Google 스프레드시트

추가 기능에서 저장된 쿼리를 선택하면 통합된 결과가 서식이 지정되고 새로 고침 가능한 상태로 셀에 표시됩니다. 이는 단일 데이터베이스 쿼리와 동일한 기능입니다.

Excel

엑셀에서도 마찬가지입니다. 헤더를 고정하고 필터를 적용하며 수식 열은 그대로 유지하면서 제자리 업데이트를 수행하는 방식으로 한 번만 실행하거나 시트 전체를 실행할 수 있습니다.

데이터베이스 REST API

데이터베이스 간 결과를 키가 포함된 JSON 엔드포인트로 게시하면, 이를 사용하는 사람은 결과가 세 가지 시스템에서 왔다는 사실을 알 필요가 없습니다.

AI 비서를 위한 MCP

클로드와 다른 지원 담당자들이 MCP를 통해 연합 쿼리 목록을 작성하고 실행할 수 있으므로 "지난주 각 지역의 실적은 어땠나요?"와 같은 질문에 대한 답변을 채팅으로 확인할 수 있습니다.

보고서 및 알림

일정을 설정하면 집계된 수치가 Slack, Google Chat, Discord, Telegram 또는 이메일로 전송됩니다. 또는 임계값을 설정하여 변동 사항이 있을 때만 알림을 받도록 할 수도 있습니다.

자동화 및 공유

결과를 정해진 일정에 따라 스프레드시트에 동기화하거나, 동료와 쿼리를 공유하여 동료가 SQL 쿼리나 연결 정보는 절대 볼 수 없도록 할 수 있습니다.

그것이 제 역할을 하는 곳

이전에는 두 개의 내보내기와 VLOOKUP 함수를 사용하는 보고서가 있었습니다.

데이터베이스를 하나만 사용하는 곳은 거의 없습니다. ERP, 매장, CRM, 그리고 최근 인수된 회사가 사용하는 시스템까지 각기 다릅니다.

주문은 여기서, 고객은 저기서 받아요

해당 쇼핑몰은 MySQL에 주문 정보를 입력하고, CRM 시스템은 PostgreSQL에 고객 및 지역 정보를 저장합니다. 이제 "지역별 매출" 계산은 두 번의 내보내기와 조회 작업이 아닌, 누구나 다시 실행할 수 있는 하나의 저장된 쿼리로 가능해집니다.

인수 후

두 회사, 두 개의 스택, 금요일 마감인 이사회 회의 자료 하나. 첫날부터 통합된 시각을 제공받을 수 있지만, 실제 마이그레이션은 늘 그렇듯 18개월이 걸립니다.

재고 대 판매

재고 수준은 다른 국가의 창고 시스템에 저장되고, 매출은 매장 데이터베이스에 저장됩니다. 하나의 보고서로 이 두 가지 정보를 나란히 비교할 수 있으며, 이 보고서는 매주 월요일에 받아볼 수 있습니다.

사이트당 데이터베이스 하나, 번호 하나

국가별, 테넌트별 또는 생산층별로 동일한 스키마를 배포합니다. 쿼리를 다섯 번 실행하고 수동으로 합산하는 스크립트를 유지 관리하는 대신, 단 하나의 명령으로 모든 값을 합산할 수 있습니다.

명확한 정의

연합 데이터베이스, 데이터 연합, 데이터 가상화

겹치는 개념들을 나타내는 세 가지 이름, 그리고 수많은 마케팅 활동으로 인해 그 경계가 모호해졌습니다. 각각의 의미와 우리가 실제로 하는 일을 알아보겠습니다.

연합 데이터베이스

A 연합 데이터베이스 연합 데이터베이스 시스템(Federated Database System)은 여러 개의 개별 데이터베이스를 병합하지 않고도 하나의 데이터베이스처럼 작동하게 합니다. 각 데이터베이스는 자체 저장소, 엔진 및 소유자를 유지하며, 상위 계층에서 사용자의 쿼리를 받아 어떤 데이터베이스가 어떤 부분에 응답할지 결정합니다.

쿼리 스트림은 바로 그 계층을 의미합니다. 그 아래에 새로운 데이터베이스가 생성되는 것도 아니고, 어떤 것도 기존 데이터베이스에 복사되는 것도 아닙니다.

데이터 연합

데이터 연합 핵심은 바로 접근 방식 자체입니다. 데이터를 원래 위치에 그대로 두고 필요할 때만 쿼리하는 방식이지, 모든 데이터를 중앙 저장소에 먼저 추출하는 방식이 아닙니다. 대안은 파이프라인과 데이터 웨어하우스를 결합하는 방식인데, 이 경우 모든 데이터를 하룻밤 사이에 옮긴 다음 필요할 때만 복사본을 쿼리하게 됩니다.

둘 다 타당한 방식입니다. 시스템 간에 문제가 발생하거나, 데이터가 제자리에 유지되어야 하거나, 데이터 웨어하우스 구축 비용이 해결책의 가치보다 클 경우에는 데이터 통합이 유리합니다. 하지만 방대한 양의 데이터를 기반으로 심층적인 과거 분석을 수행해야 하는 경우에는 데이터 웨어하우스가 여전히 더 적합합니다.

데이터 가상화

데이터 가상화 더 큰 규모의 엔터프라이즈 범주는 연합 기반으로 구축되며, 일반적으로 연합 쿼리 기능과 모델링 계층, 캐싱 및 거버넌스 도구가 포함되어 자체 플랫폼으로 판매됩니다.

우리는 의도적으로 그 중에서 좁고 정직한 부분을 택했습니다. 기존 연결을 통한 연합 쿼리팀에서 이미 쿼리를 작성하는 데 사용하는 도구 내에서 바로 사용할 수 있습니다. 모델링 프로젝트도 필요 없고, 자체 서버를 운영할 필요도 없고, 컨설턴트도 필요 없습니다.

연합 쿼리 FAQ

연합 쿼리란 무엇인가요?

연합 쿼리는 여러 개의 개별 데이터베이스에서 데이터를 읽어 하나의 통합된 결과를 반환하는 단일 SQL 문입니다. 먼저 데이터를 복사하는 과정이 없습니다. SQL 문은 각 데이터베이스별로 작은 쿼리로 분할되고, 각 쿼리는 처리 가능한 부분에 대한 응답을 제공한 후, 이러한 분할된 쿼리들을 결합하여 최종 결과를 생성합니다. Query Streams에서 SQL 문은 두 개 이상의 연결을 지정하는 순간 연합 쿼리가 됩니다.

내 데이터베이스들은 모두 같은 위치에 있어야 하나요?

아니요. 서버는 서로 다른 사무실, 다른 클라우드 계정, 다른 국가에 위치할 수 있으며, 이 모든 것이 혼합된 형태일 수도 있습니다. 예를 들어 하나는 서버실에, 하나는 프라이빗 클라우드 네트워크에, 하나는 창고의 컴퓨터에 있을 수 있습니다. 각 위치에서는 네트워크 에이전트가 실행되고, 각 에이전트는 외부로 전화를 걸어 쿼리 스트림에 접근합니다. 방화벽 입장에서는 일반적인 아웃바운드 연결로 간주되므로, 열어야 할 포트도 없고 VPN을 구축할 필요도 없습니다.

하나의 서버에서 여러 데이터베이스를 동일한 에이전트에 연결할 수도 있습니다. 일반적으로는 데이터베이스당 에이전트가 아닌 위치당 에이전트 하나씩 사용하는 것이 일반적입니다.

데이터 웨어하우스나 ETL 파이프라인도 필요한가요?

이 경우에는 그렇지 않습니다. 로드해야 할 데이터도 없고 관리해야 할 일정도 없습니다. 쿼리는 실행되는 순간 실시간 데이터베이스를 읽어오기 때문에 어젯밤 복사본처럼 오래된 데이터가 나올 염려가 없습니다. 하지만 페더레이션이 대체할 수 없는 것은 매우 큰 용량의 데이터에 대한 심층적인 과거 분석입니다. 이는 여전히 데이터 웨어하우스의 역할입니다. 간단한 테스트 방법은 다음과 같습니다. 질문이 여러 시스템에 걸쳐 있고 최신 정보가 필요한 경우 페더레이션을 사용하는 것이 좋습니다.

어떤 데이터베이스들을 서로 결합할 수 있나요?

SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access, DuckDB 등 어떤 데이터베이스든 어떤 조합으로든 연결할 수 있습니다. 각 데이터베이스는 고유한 방언으로 요청되므로 동일한 쿼리라도 각기 다른 방식으로 전송될 수 있습니다. 맨 위 SQL Server로 그리고 LIMIT PostgreSQL로 자동으로 변환되므로 따로 신경 쓸 필요가 없습니다.

데이터베이스마다 계산 능력과 정렬 및 반올림 방식이 다르기 때문에 모든 표현식의 모든 조합에 대해 정확한 답을 드릴 수는 없습니다. 그런 경우에는 거의 정확한 숫자가 아니라 해당 표현식의 이름을 명시한 구체적인 오류 메시지가 표시됩니다.

하나의 데이터베이스를 조회하는 것보다 속도가 느린가요?

각 데이터베이스가 자체적으로 처리할 수 있는 작업량에 따라 달라지는데, 바로 이 부분을 최적화하는 것이 저희의 목표이며, 실행 계획에서 이를 정확하게 보여드립니다. 필터링과 그룹화 작업이 모두 데이터베이스 내부에서 이루어지는 경우, 데이터 이동량이 매우 적어 일반적인 쿼리처럼 느껴집니다. 하지만 대규모 조인 작업을 데이터베이스에서 처리해야 하는 경우에는 더 많은 데이터 이동이 발생하며, 실행 계획에서 실행 전에 이를 알려줍니다. 또한 각 데이터베이스에는 쿼리당 처리량 상한선이 설정되어 있어 오류가 발생하더라도 처리가 지연되지 않고 조기에 중단됩니다.

하나의 쿼리로 여러 운영 데이터베이스를 가리키는 것이 안전한가요?

이는 여기에서 실행하는 다른 모든 쿼리와 동일한 보안 모델을 사용합니다. 각 데이터는 암호화된 아웃바운드 연결 하나를 통해 자체 네트워크 에이전트를 거쳐 전송됩니다. 인바운드 포트, VPN, 방화벽 변경이 필요 없으며 데이터베이스 자격 증명은 네트워크를 벗어나지 않습니다. 모든 데이터는 읽기 전용으로 검사됩니다.선택, 와 함께, 설명하다연합 쿼리는 아무 곳에도 쓰기 작업을 할 수 없으며, 각 데이터베이스는 사용자가 지정한 열에만 접근하는 쿼리를 보게 됩니다.

이 제품은 Trino, Presto 또는 Denodo와 어떻게 다른가요?

Trino와 Presto가 대중화시킨 것과 같은 아이디어입니다. 하나의 SQL 문을 여러 소스에 푸시하는 것이죠. 차이점은 실행하고 학습해야 하는 방식에 있습니다. Trino와 Presto는 클러스터를 배포하고 튜닝하고 네트워크에 연결해야 합니다. 데이터 가상화 플랫폼은 모델링 레이어와 그에 맞는 라이선스를 추가합니다. 반면, 저희 솔루션은 팀에서 이미 사용하고 있는 쿼리 도구 내에서 동일한 기능을 제공하고, 기존에 설정해 놓은 연결에 접근할 수 있도록 하며, 별도의 서버를 운영할 필요가 없습니다.

또 다른 차이점은 우리가 거부한다는 것입니다. 데이터베이스 간에 수치를 변경할 수 있는 불일치가 발생하면, 그럴듯한 값을 반환하는 대신 처리할 수 없었던 표현식을 명시하고 처리를 중단합니다.

그 결과를 어떻게 활용할 수 있을까요?

저장된 쿼리를 가지고 할 수 있는 모든 작업이 가능합니다. 저장하고, 팀과 공유하고, 필터를 적용하고, Slack이나 이메일로 보고서로 예약 전송하고, REST 엔드포인트로 게시하고, 결과를 Excel이나 Google Sheets로 가져올 수 있습니다. 또한 Nova는 스키마를 읽어 쿼리문을 자동으로 생성해 주기 때문에, 조인을 직접 작성하는 대신 질문을 설명하는 것이 더 편리할 수 있습니다.

또한 살펴보세요

쿼리 빌더 Nova AI 보고서 및 알림 API 커넥터 Excel 및 시트

데이터베이스는 원래 위치에 그대로 있습니다. 이제 더 이상 중요하지 않습니다.

두 개의 연결을 지정하고, 하나의 명령문을 작성하고, 실행하기 전에 실행 계획을 읽으세요. 파이프라인, 데이터 웨어하우스, 방화벽 티켓은 필요 없습니다.

무료 티어 체험하기 팀 요금제

Federated queries are on every plan, including Free