Microsoft Fabric'da graf için GQL sorgu performansını iyileştirme

Uyarı

Bu özellik şu anda genel önizlemededir. Bu önizleme, hizmet düzeyi sözleşmesi olmadan sağlanır ve üretim iş yükleri için önerilmez. Bazı özellikler desteklenmiyor olabileceği gibi özellikleri sınırlandırılmış da olabilir. Daha fazla bilgi için bkz. Microsoft Azure Önizlemeleri için Uygun Kullanım Koşulları.

Bu makalede, Microsoft Fabric'de grafla çalışırken tahmin edilebilir ve verimli bir şekilde performans gösteren GQL (Graph Sorgu Dili) sorguları yazmaya yönelik yönergeler sağlanır. Öneriler, geçerli platform davranışına ve belgelenmiş kısıtlamalara dayanır.

Grafik boyutu, sonuç boyutu ve sorgu zaman aşımıyla ilgili sabit sınırlar için bkz . Geçerli sınırlamalar. Bu makaledeki çeşitli öneriler, grafik şemanızı nasıl tasarladığınızla da ilgilidir. Daha fazla bilgi için bkz . Grafik şeması tasarlama.

Desenlerin erken aşamalarında filtreleme

Filtreleri sonraki ifadeler yerine graf desenlerinin içine yerleştirin. Şablon düzeyi WHERE yan tümceleri, birleştirmeler ve sonraki deyimler çalıştırılmadan önce ara sonuçların sayısını azaltır ve bu da genel yürütme maliyetini düşürür.

Önerilen: Desen eşleştirme sırasında filtreleyin.

-- 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

Kaçının: Ayrı bir FILTER deyimiyle geç aşamada filtreleme.

-- 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

Her iki sorgu da aynı sonuçları döndürür, ancak ilk sürüm sorgu altyapısının değerlendirme işleminin önceki bölümlerinde satırları ayıklamasına olanak tanır.

Tavsiye

Desen düzeyini WHERE sql JOIN ... ON koşuluna benzer olarak düşünün. Değerlendirme noktasında eşleşmeleri kısıtlayarak tam sonuç kümesini sonradan filtrelemekten kaçınır.

Yalnızca ihtiyacınız olan özellikleri döndürme

Yalnızca senaryonuzun gerektirdiği düğüm ve kenar özelliklerini döndürür. Özelliklerin yalnızca bir alt kümesine ihtiyacınız olduğunda tam düğümleri döndürmekten veya RETURN * kullanmaktan kaçının.

Grafikte, OneLake tabloları geri düğüm özelliklerini destekler. Gereksiz özelliklerin seçilmesi veri okuma, serileştirme maliyeti ve yanıt boyutunu artırır. Graf modellemesi sırasında, siz kaldırmadığınız sürece kaynak tablodaki tüm sütunlar varsayılan olarak düğüm türü özellikleri olarak eklenir.

Önerilen: Dar projeksiyon.

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, p.lastName, c.name

Kaçının: Tam düğümleri döndürmekten.

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN *

Uyarı

Her özelliğin yanındaki çöp kutusu simgesini seçerek grafik modellemesi sırasında kullanılmayan düğüm türü özelliklerini kaldırın. Düğüm başına daha az özellik hem depolama hem de sorgu ek yükünü azaltır.

Sonuç kümesi boyutunu sınırla

Yüksek kardinaliteye sahip olabilecek düğümleri veya ilişkileri sorgularken LIMIT veya diğer sınırlayıcı koşulları uygulayın. İlişkisiz grafik eşleşmeleri, platform sınırlarına yaklaşan çok büyük sonuç kümeleri oluşturabilir.

Önerilen: Sınırlanmış sonuçlar.

MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000

Önle: İlişkisiz yüksek kardinalite eşleşmesi.

MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName

Önemli

Graf 64 MB'tan büyük yanıtları kesebilir ve sonuçlar 128 MB'ı aştığında toplama performansı kararsız olabilir. Sonuçları bu sınırlar içinde tutmak için , FILTERve LIMIT kullanınGROUP BY. Daha fazla bilgi için bkz . Geçerli sınırlamalar.

Geçişleri kısa ve hedefli tutun

İç içe veya son derece karmaşık grafik desenlerinden kaçının. Belirli bir soruyu doğrudan yanıtlayan basit, hedeflenen dolaşmaları kullanın. Değişken uzunlukta bir desendeki her ek atlama, özellikle yoğun bağlantılı grafiklerde motorun değerlendirdiği yol sayısını üstel şekilde artırabilir.

Önerilen: Sıkı sınırlar.

-- Use the narrowest hop range that answers your question
MATCH (p:Person)-[:knows]->{1,3}(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000

Kaçının: Gerek duymadan maksimum derinlikli dolaşma.

-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *

Önemli

Graph, değişken uzunluktaki desenlerde en fazla sekiz atlama destekler. Yine de senaryonuzun izin verdiği en sıkı sınırları kullanın. Örnekte, {1,3} deseni aynı grafikteki {1,8} deseninden önemli ölçüde daha ucuzdur.

Gereksiz dolaşmaları önlemek için TRAIL kullanma

Sorgu motorunun aynı kenarı yeniden ziyaret etmesini önlemek için TRAIL yol modunu kullanın. Yoğun graflarda döngüler üstel yol patlamasına neden olabilir. TRAIL her kenarın yol başına en fazla bir kez ziyaret edilmesini sağlar ve bu da hem doğruluğu hem de performansı artırır.

-- 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

olmadan TRAIL, döngüsel bir grafta aynı sorgu çok daha büyük (ve genellikle yedekli) bir sonuç kümesi oluşturabilir.

Verimli birleşimler için paylaşılan değişkenleri kullanma

Bir sorgu birden çok ilişkiden veri gerektirdiğinde, aynı varlık üzerindeki desenleri birleştirmek için paylaşılan bir değişken kullanın. Paylaşılan değişken olmadan desenler, her iki desendeki eşleşmelerin her birleşimi olan kartezyen bir ürün üretebilir ve bu da çok daha büyük bir sonuç kümesine yol açar.

Önerilen: Paylaşılan değişken p desenleri birleştirir.

-- 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

Kaçının: Paylaşılan değişken içermeyen bağımsız örüntüler.

-- 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

Kartezyen ürün, bir desenden elde edilen her sonucu diğerinden elde edilen her sonuçla eşleştirir. 1.000 satırla eşleşiyorsa Person-workAt->Company ve Person-isLocatedIn->City 500 satırla eşleşiyorsa, sorgu 1.000 × 500 = 500.000 satır döndürür. Paylaşılan değişken eklemek birleştirmeyi kısıtlar, böylece yalnızca eşleşen çiftler döndürülür.

Düğümlerde anahtar kısıtlamalarını tanımlama

Grafik türünüzde düğüm anahtarı kısıtlamaları tanımlayın. Anahtar kısıtlamaları, sistemin ilişkisel veritabanlarındaki birincil anahtar dizinlerine benzer şekilde belirli düğümleri anahtar özelliklerine göre arayan sorguları iyileştirmesini sağlar.

Örneğin, grafik türünüz, id'yi Person düğümlerinin anahtarı olarak tanımlıyorsa:

CONSTRAINT person_pk
  FOR (n:Person) REQUIRE n.id IS KEY

Ardından, id üzerinde filtreleme yapan sorgular bu anahtarı doğrudan sorgulama için kullanabilir:

-- 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

Anahtar özelliğinde filtre olmadan, motorun her Person düğümünü taraması gerekir.

-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name

Tavsiye

Belirli bir düğüme ihtiyacınız olduğunda, tanımladığınız kısıtlamadan yararlanmak için desendeki MATCH anahtar özelliğine filtre uygulayın.

Uygun veri türlerini seçin

Graf modelleme sırasında her özellik için en özel veri türünü seçin. Doğru türlerin seçilmesi hem storage verimliliği hem de sorgu performansı açısından önemlidir. Örneğin, özelliklerdeki INT sayısal karşılaştırmalar, eşdeğer STRING değerlerdeki dize karşılaştırmalarından daha hızlıdır.

Desteklenen veri türleri için bkz . Geçerli sınırlamalar — Veri türleri ve Desteklenen özellik türleri.

Mümkün olduğunda, aynı kenarlardan bağımsız olarak geçen ayrı sorgular oluşturmak yerine tek bir grafik düzeninde ilgili varlıkları alın. Çapraz geçişlerin birleştirilmesi, yedekli desen eşleştirmeyi önler ve bir ilk sorgunun her sonuç satırı için ayrı bir sorgu tetiklediği N+1 sorgu sorununu önler.

Önerilen: Tek birleştirilmiş desen.

MATCH (c:Customer)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000

Önle: Aynı Customer → Order kenardan geçen iki ayrı sorgu.

-- 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

Gerçekçi veri hacimlerinde sorguları test etme

Küçük veri kümelerinde iyi performans gösteren sorgular doğrusal olarak ölçeklendirilmeyebilir. Sorgularınızı beklenen üretim iş yükünüzü temsil eden veri birimleriyle test edin.

  • Filtreler ve sınırlar içeren muhafazakar sorgu şekillerini tercih edin.
  • Büyük grafiklerde keşif "tüm verileri geri döndürme" sorgularından kaçının.
  • 20 dakikalık zaman aşımı sınırına göre sorgu süresini izleyin.

İlgili içerik

  • Last updated on