Aracılığıyla paylaş

Kusto Sorgu Dili sorguları için en iyi yöntemler

  • Makale

Şunlar için geçerlidir: ✅Microsoft Fabric✅Azure Veri Gezgini✅ Azure İzleyici✅Microsoft Sentinel

Sorgunuzun daha hızlı çalışmasını sağlamak için izleyebileceğiniz birkaç en iyi yöntem aşağıdadır.

Kısaca

Eylem Kullanma Kullanmayın Notlar
Sorgulanan veri miktarını azaltma İşlenen veri miktarını azaltmak için işleç gibi where mekanizmalar kullanın. İşlenen veri miktarını azaltmanın verimli yolları hakkında daha fazla bilgi için bkz . İşlenen veri miktarını azaltma.
Yedekli nitelenmiş başvurular kullanmaktan kaçının Yerel varlıklara başvururken nitelenmemiş adı kullanın. Daha fazla bilgi için bkz . Yedekli nitelenmiş başvuruları kullanmaktan kaçınma.
datetime Sütun datetime Veri türünü kullanın. Veri türünü kullanmayın long . Sorgularda, gibi unixtime_milliseconds_todatetime()Unix zaman dönüştürme işlevlerini kullanmayın. Bunun yerine, unix süresini alma sırasında veri türüne datetime dönüştürmek için güncelleştirme ilkelerini kullanın.
Dize işleçleri has işlecini kullanma. Kullanmayın contains Tam belirteçleri ararken alt has dizeleri aramadığından daha iyi çalışır.
Büyük/küçük harfe duyarlı işleçler == adresini kullanın. =~ kullanmayın. Mümkün olduğunda büyük/küçük harfe duyarlı işleçler kullanın.
in adresini kullanın. in~ kullanmayın.
contains_cs adresini kullanın. contains kullanmayın. kullanmak has/has_cs için contains/contains_cstercih edilir.
Metin arama Belirli bir sütuna bakın. * kullanmayın. * tüm sütunlarda tam metin araması yapar.
Milyonlarca satırda dinamik nesnelerden alan ayıklama Sorgularınızın çoğu milyonlarca satırdaki dinamik nesnelerden alan ayıklarsa, sütununuzu alım zamanında gerçekleştirin. Bu yöntemle sütun ayıklama için yalnızca bir kez ödemeniz gerekir.
Dinamik nesnelerdeki nadir anahtarlar/değerler için arama MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value" adresini kullanın. MyTable | where DynamicColumn.SomeKey == "Rare value" kullanmayın. Bu yöntemle çoğu kaydı filtreler ve yalnızca kalan kayıtlarda JSON ayrıştırma yaparsınız.
let birden çok kez kullandığınız bir değere sahip deyimi materialize() işlevini kullanın. kullanma materialize()hakkında daha fazla bilgi için bkz . materialize(). Daha fazla bilgi için bkz . Adlandırılmış ifadeleri kullanan sorguları iyileştirme.
Bir milyardan fazla kayıtta tür dönüştürmeleri uygulama Dönüştürmeye beslenen veri miktarını azaltmak için sorgunuzu yeniden şekillendirin. Önlenebilirse büyük miktarda veriyi dönüştürmeyin.
Yeni sorgular veya count sonunda kullanınlimit [small number]. Bilinmeyen veri kümeleri üzerinde ilişkisiz sorgular çalıştırmak gigabaytlar halinde sonuç döndürerek yavaş yanıt ve meşgul bir ortam elde edebilir.
Büyük/küçük harfe duyarlı olmayan karşılaştırmalar Col =~ "lowercasestring" adresini kullanın. tolower(Col) == "lowercasestring" kullanmayın.
Verileri küçük harfle (veya büyük harfle) karşılaştırın Col == "lowercasestring" (veya Col == "UPPERCASESTRING"). Büyük/küçük harfe duyarsız karşılaştırmalar kullanmaktan kaçının.
Sütunlara göre filtreleme Tablo sütununa filtre uygulama. Hesaplanmış bir sütuna filtre uygulamayın.
T | where predicate(*Expression*) komutunu kullanma Kullanmayın T | extend _value = *Expression* | where predicate(_value)
summarize işleci işleci yüksek kardinaliteye sahip olduğunda summarize group by keys hint.shufflekey=<key> kullanın. Yüksek kardinalite ideal olarak bir milyondan fazladır.
join işleci İlk satır olarak en az satır içeren tabloyu seçin (sorguda en soldaki).
Tek bir sütuna göre filtrelemek için sol yarı join yerine kullanınin.
Kümeler arasında birleştirme Sorguyu birleştirmenin "sağ" tarafında, verilerin çoğunun bulunduğu kümeler veya Eventhouse'lar gibi uzak ortamlarda çalıştırın.
Sol taraf küçük ve sağ taraf büyük olduğunda birleştirme hint.strategy=broadcast kullanın. Küçük, en fazla 100 megabayt (MB) veri anlamına gelir.
Sağ taraf küçük ve sol taraf büyük olduğunda birleştirme İşleç yerine arama işlecini join kullanın Aramanın sağ tarafı onlarca MB'tan büyükse sorgu başarısız olur.
her iki taraf da çok büyük olduğunda birleştirme hint.shufflekey=<key> kullanın. Birleştirme anahtarının kardinalitesi yüksek olduğunda kullanın.
Aynı biçimi veya deseni paylaşan dizelerle sütundaki değerleri ayıklama Ayrıştırma işlecini kullanın. Birkaç extract() deyim kullanmayın. Örneğin, gibi "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ...."değerler.
extract() işlevi Ayrıştırılan dizelerin tümü aynı biçime veya desene uymadığında kullanın. REGEX kullanarak gerekli değerleri ayıklayın.
materialize() işlevi Gerçekleştirilmiş veri kümesini azaltan ve sorgunun semantiğini kullanmaya devam eden tüm olası işleçleri gönderme. Örneğin, filtreler veya proje için yalnızca gerekli sütunlar. Daha fazla bilgi için bkz . Adlandırılmış ifadeleri kullanan sorguları iyileştirme.
Gerçekleştirilmiş görünümleri kullanma Yaygın olarak kullanılan toplamaları depolamak için gerçekleştirilmiş görünümler kullanın. Yalnızca gerçekleştirilmiş bölümü sorgulamak için işlevini kullanmayı materialized_view() tercih edin. materialized_view('MV')

İşlenen veri miktarını azaltma

Sorgunun performansı doğrudan işlemesi gereken veri miktarına bağlıdır. Ne kadar az veri işlenirse sorgu o kadar hızlı olur (ve o kadar az kaynak tüketir). Bu nedenle en önemli en iyi yöntem, sorguyu işlenen veri miktarını azaltacak şekilde yapılandırmaktır.

Not

Aşağıdaki tartışmada, filtre seçiciliği kavramını göz önünde bulundurmak önemlidir. Seçicilik, bir koşula göre filtrelendiğinde kayıtların yüzdesinin filtrelendiği değerdir. Yüksek oranda seçmeli koşul, koşul uygulandıktan sonra yalnızca birkaç kaydın kalması ve daha sonra etkili bir şekilde işlenmesi gereken veri miktarının azaltılması anlamına gelir.

Önem sırasına göre:

  • Yalnızca verileri sorgu tarafından gerekli olan tablolara başvurur. Örneğin, işleci joker tablo başvuruları ile kullanırken union , tüm tablolara başvurmak için joker karakter (*) kullanmak ve ardından kaynak tablo adında bir koşul kullanarak verileri filtrelemek yerine performans açısından yalnızca birkaç tabloya başvurmak daha iyidir.

  • Sorgu yalnızca belirli bir kapsam için uygunsa tablonun veri kapsamından yararlanın. table() işlevi, önbelleğe alma ilkesine (DataScope parametresi) göre kapsamına alarak verileri ortadan kaldırmak için verimli bir yol sağlar.

  • Tablo başvurularının where hemen ardından sorgu işlecini uygulayın.

  • Sorgu işlecini where kullanırken, tek where bir işleç veya ardışık where birden çok işleç kullanmanız fark etmeksizin, koşullarını yerleştirme sırasının sorgu performansı üzerinde önemli bir etkisi olabilir.

  • Önce tam parça koşullarını uygulayın. Bu, önce extent_id() işlevini ve extent_tags() işlevini kullanan koşulların uygulanması gerektiği anlamına gelir. Ayrıca, verileri belirli bölümlere daraltan seçmeli koşullarınız varsa, önce bunların uygulanması gerekir.

  • Ardından tablo sütunlarına göre datetime hareket eden koşullar uygulayın. Kusto, bu tür sütunlar üzerinde verimli bir dizin içerir ve genellikle bu parçalara erişmeye gerek kalmadan tüm veri parçalarını tamamen ortadan kaldırır.

  • Ardından, özellikle terim düzeyinde geçerli olan bu tür koşullar üzerinde ve sütunlara string dynamic göre hareket eden koşullar uygulayın. Koşullarını seçiciliğe göre sıralar. Örneğin, milyonlarca kullanıcı olduğunda bir kullanıcı kimliği aramak yüksek oranda seçmelidir ve genellikle dizinin çok verimli olduğu bir terim araması içerir.

  • Ardından, seçmeli ve sayısal sütunları temel alan koşullar uygulayın.

  • Son olarak, bir tablo sütununun verilerini tarayen sorgular için (örneğin, terimleri contains "@!@!"olmayan ve dizin oluşturmadan yararlanan gibi koşullar için), sütunları daha az veriyle tarayanın önce olması koşulu sıralar. Bunun yapılması, büyük sütunların sıkıştırmasını açma ve tarama gereksinimini azaltır.

Yedekli nitelenmiş başvurular kullanmaktan kaçının

Tablolar ve gerçekleştirilmiş görünümler gibi varlıklara ada göre başvuruda bulunur.

Örneğin, tabloya basitçe (nitelenmemiş ad) veya bir veritabanı niteleyicisi kullanılarak (örneğin, database("DB").T tablo adlı DBbir veritabanında olduğunda) veya tam ad (örneğin) cluster("<serviceURL>").database("DB").Tkullanılarak başvurulabilir.T T

Örneğin, tabloya basitçe (nitelenmemiş ad) veya bir veritabanı niteleyicisi kullanılarak (örneğin, database("DB").T tablo adlı DBbir veritabanında olduğunda) veya tam ad (örneğin) cluster("X.Y.kusto.windows.net").database("DB").Tkullanılarak başvurulabilir.T T

Aşağıdaki nedenlerle, yedekli olduklarında ad niteliklerini kullanmaktan kaçınmak en iyi yöntemdir:

  1. Nitelenmemiş adların (bir insan okuyucu için) kapsamdaki veritabanına ait olduğunu belirlemek daha kolaydır.

  2. Kapsam içindeki veritabanı varlıklarına başvurmak her zaman en az en hızlı ve bazı durumlarda çok daha hızlıdır ve ardından diğer veritabanlarına ait varlıklardır.

Bu durum özellikle bu veritabanları farklı bir kümede olduğunda geçerlidir.

Bu durum özellikle bu veritabanları farklı bir Eventhouse'da olduğunda geçerlidir.

Nitelikli adlardan kaçınmak, okuyucunun doğru şeyi yapması için yardımcı olur.

Not

Bu, nitelenmiş adların performans açısından kötü olduğu anlamına gelmez. Aslında Kusto, çoğu durumda tam adın kapsamın içindeki veritabanına ait bir varlığa ne zaman başvurduğunu ve kümeler arası sorgu olarak kabul edilmemesi için sorguyu "kısa devre" belirleyebilir. Ancak, gerekli olmadığında buna güvenmenizi önermeyiz.

Not

Bu, nitelenmiş adların performans açısından kötü olduğu anlamına gelmez. Aslında Kusto çoğu durumda tam adın kapsamdaki veritabanına ait bir varlığa ne zaman başvurduğunda bunu belirleyebilir. Ancak, gerekli olmadığında buna güvenmenizi önermeyiz.