비고
이 기능은 현재 공개 미리 보기로 제공됩니다. 이 미리 보기는 서비스 수준 계약 없이 제공되며 프로덕션 워크로드에는 사용하지 않는 것이 좋습니다. 특정 기능이 지원되지 않거나 기능이 제한될 수 있습니다. 자세한 내용은 Supplemental Terms for Microsoft Azure Previews 참조하세요.
이 문서에서는 Microsoft Fabric에서 그래프로 작업할 때 예측 및 효율적으로 수행하는 GQL(그래프 쿼리 언어) 쿼리를 작성하기 위한 지침을 제공합니다. 권장 사항은 현재 플랫폼 동작 및 문서화된 제약 조건을 기반으로 합니다.
그래프 크기, 결과 크기 및 쿼리 시간 제한에 대한 하드 제한은 현재 제한을 참조하세요.
초기 단계에서 패턴 필터링
그래프 패턴 내에 필터를 배치하고 나중에 사용하는 문에서는 하지 마십시오. 패턴 수준 WHERE 절은 조인 및 후속 문을 실행하기 전에 중간 결과의 수를 줄여 전체 실행 비용을 낮춥니다.
권장: 패턴 일치 중에 필터링합니다.
-- Pattern-level WHERE reduces intermediate results
MATCH (p:Person WHERE p.birthday < 19940101)-[:workAt]->(c:Company WHERE c.id > 1000)
RETURN p.firstName, p.lastName, c.name
피하십시오: 별도의 FILTER 문으로 늦게 필터링하는 것을.
-- Statement-level filter runs after all pattern matches are produced
MATCH (p:Person)-[:workAt]->(c:Company)
FILTER p.birthday < 19940101 AND c.id > 1000
RETURN p.firstName, p.lastName, c.name
두 쿼리 모두 동일한 결과를 반환하지만 첫 번째 버전을 사용하면 쿼리 엔진이 평가 프로세스의 앞부분에서 행을 정리할 수 있습니다.
팁 (조언)
패턴 수준을 WHERE SQL JOIN ... ON 조건과 유사하다고 생각합니다. 전체 결과 집합을 사후 필터링하는 대신 평가 지점에서 일치 항목을 제한합니다.
필요한 속성만 반환합니다.
시나리오에 필요한 노드 및 에지 속성만 반환합니다. 전체 노드를 반환하거나 속성의 하위 집합만 필요한 경우에는 RETURN *을 사용하지 마십시오.
그래프에서 OneLake는 노드 속성을 뒤로 테이블합니다. 불필요한 속성을 선택하면 데이터 읽기, serialization 비용 및 응답 크기가 증가합니다. 그래프 모델링 중에 원본 테이블의 모든 열은 제거하지 않는 한 기본적으로 속성으로 추가됩니다.
권장: 좁은 프로젝션.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, p.lastName, c.name
피하기 위해: 전체 노드를 반환합니다.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN *
비고
각 속성 옆에 있는 휴지통 아이콘을 선택하여 그래프 모델링 중에 사용되지 않는 속성을 제거합니다. 노드당 속성이 적어도 storage 및 쿼리 오버헤드가 모두 줄어듭니다.
결과 집합 크기 제한
카디널리티가 높을 수 있는 노드 또는 관계를 쿼리할 때 LIMIT 또는 다른 경계 조건을 적용하세요. 바인딩되지 않은 그래프 일치는 플랫폼 제한에 접근하는 매우 큰 결과 집합을 생성할 수 있습니다.
권장: 제한된 결과입니다.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
피할 것: 제한 없는 높은 카디널리티 일치.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
중요합니다
그래프는 응답을 64MB보다 크게 자르며 결과가 128MB를 초과하면 집계 성능이 불안정할 수 있습니다. 를 FILTERLIMIT 사용하고 GROUP BY결과를 이러한 범위 내에 유지합니다. 자세한 내용은 현재 제한 사항을 참조하세요.
탐색을 간단하고 집중적으로 유지하세요.
깊이 중첩되거나 매우 복잡한 그래프 패턴을 사용하지 않습니다. 특정 질문에 직접 답변하는 간단하고 타겟팅된 순회를 선호합니다. 가변 길이 패턴의 각 추가 홉은 특히 조밀하게 연결된 그래프에서 엔진이 평가하는 경로 수를 기하급수적으로 늘릴 수 있습니다.
권장: 엄격한 제한.
-- Use the narrowest hop range that answers your question
MATCH (p:Person)-[:knows]->{1,3}(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
피하기: 명확한 필요 없이 최대 깊이 탐색.
-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *
중요합니다
그래프는 가변 길이 패턴에서 최대 8개의 홉 을 지원합니다. 그럼에도 불구하고 시나리오에서 허용하는 가장 엄격한 범위를 사용합니다. 이 예제에서 {1,3} 패턴은 동일한 그래프에서 {1,8} 패턴보다 더 저렴합니다.
TRAIL을 사용하여 중복 순회 방지
경로 모드를 사용하여 TRAIL 쿼리 엔진이 동일한 에지를 다시 방문하지 못하도록 합니다. 조밀한 그래프에서 사이클은 지수적인 경로 폭발을 일으킬 수 있습니다.
TRAIL 에서 각 경로에서 에지를 최대 한 번만 방문함으로써, 정확성과 성능 모두 향상됩니다.
-- TRAIL prevents revisiting the same :knows edge
MATCH TRAIL (src:Person)-[:knows]->{1,4}(dst:Person)
WHERE src.firstName = 'Alice' AND dst.firstName = 'Bob'
RETURN count(*) AS numPaths
없으면 TRAIL순환 그래프에서 동일한 쿼리가 훨씬 더 크고 종종 중복된 결과 집합을 생성할 수 있습니다.
효율적인 조인을 위해 공유 변수 사용
쿼리에 여러 관계의 데이터가 필요한 경우 공유 변수를 사용하여 동일한 엔터티의 패턴을 조인합니다. 공유 변수가 없으면 패턴은 두 패턴의 모든 일치 항목 조합인 카티전 제품을 생성하여 훨씬 더 큰 결과 집합을 생성할 수 있습니다.
권장: 공유 변수 p 는 패턴을 조인합니다.
-- Single shared variable ensures an efficient join
MATCH (p:Person)-[:workAt]->(c:Company),
(p)-[:isLocatedIn]->(city:City)
RETURN p.firstName, c.name AS company, city.name AS city
LIMIT 1000
피하기: 공유 변수가 없는 독립 패턴.
-- Without a shared variable, this produces a cartesian product
MATCH (p1:Person)-[:workAt]->(c:Company),
(p2:Person)-[:isLocatedIn]->(city:City)
RETURN p1.firstName, c.name, p2.firstName, city.name
카티지아 제품은 한 패턴의 모든 결과와 다른 패턴의 모든 결과를 쌍으로 만듭니다. 1,000개의 행과 일치하고 500개의 행과 Person-workAt->Company 일치하는 경우 Person-isLocatedIn->City 쿼리는 1,000개 × 500 = 500,000개의 행을 반환합니다. 공유 변수를 추가하면 조인이 제한되므로 일치하는 쌍만 반환됩니다.
노드에서 키 제약 조건 정의
그래프 형식에서 노드 키 제약 조건을 정의합니다. 키 제약 조건을 사용하면 시스템에서 관계형 데이터베이스의 기본 키 인덱스와 유사하게 키 속성으로 특정 노드를 조회하는 쿼리를 최적화할 수 있습니다.
예를 들어, 그래프 유형이 id를 Person 노드의 키로 정의하는 경우:
CONSTRAINT person_pk
FOR (n:Person) REQUIRE n.id IS KEY
그런 다음 id에서 필터링하는 쿼리는 해당 키를 통해 직접 조회를 수행할 수 있습니다.
-- Fast: the engine can look up person 12345 directly using the key
MATCH (p:Person WHERE p.id = 12345)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
키 속성에 대한 필터가 없으면 엔진은 모든 Person 노드를 검색해야 합니다.
-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
팁 (조언)
특정 노드가 필요한 경우, MATCH 패턴의 키 속성을 기준으로 필터링하여 정의된 제약 조건을 활용하세요.
적절한 데이터 형식 선택
그래프 모델링 중에 각 속성에 대해 가장 구체적인 데이터 형식을 선택합니다. 올바른 형식을 선택하는 것은 storage 효율성과 쿼리 성능 모두에 중요합니다. 예를 들어 속성에 대한 INT 숫자 비교는 해당 STRING 값에 대한 문자열 비교보다 빠릅니다.
지원되는 데이터 형식은 현재 제한 사항(데이터 형식 및 지원되는 속성 형식)을 참조하세요.
관련 순회를 단일 쿼리로 결합
가능한 경우 동일한 가장자리를 독립적으로 트래버스하는 별도의 쿼리를 실행하는 대신 단일 그래프 패턴으로 관련 엔터티를 검색합니다. 순회를 결합하면 중복 패턴 일치가 방지되고 N+1 쿼리 문제가 방지됩니다. 여기서 하나의 초기 쿼리는 각 결과 행에 대해 별도의 쿼리를 트리거합니다.
권장: 단일 결합 패턴입니다.
MATCH (c:Customer)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000
피하기: 동일한 가장자리를 트래버스하는 두 개의 별도 쿼리.
-- Query 1: fetch 100 orders
MATCH (c:Customer)-[:purchased]->(o:Order)
RETURN c.id, o.id
-- Query 2: run once per order to get products (N+1 problem)
MATCH (o:Order)-[:contains]->(product:Product)
RETURN o.id, product.name
실제 데이터 볼륨에 대한 쿼리 테스트
작은 데이터 세트에 대해 잘 수행되는 쿼리는 선형적으로 확장되지 않을 수 있습니다. 예상 프로덕션 워크로드를 나타내는 데이터 볼륨으로 쿼리를 테스트합니다.
- 필터 및 제한을 포함하는 보수적인 쿼리 셰이프를 선호합니다.
- 큰 그래프에 대해 예비 "모든 항목 반환" 쿼리를 사용하지 않습니다.
- 20분 제한 시간을 기준으로 쿼리 기간을 모니터링합니다.