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

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

Kısacası

Eylem	Kullanın	Kullanma	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ı için aşağıya bakın.
Yedekli nitelenmiş başvurular kullanmaktan kaçının	Yerel varlıklara başvururken nitelenmemiş adı kullanın.		Konuyla ilgili daha fazla bilgi için aşağıya bakın.
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 zamanını 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	işlecini has kullanma	Kullanma contains	Tam belirteçleri ararken alt has dizeleri aramadığından daha iyi çalışır.
Büyük/küçük harfe duyarlı işleçler	== komutunu kullanma	Kullanma =~	Mümkün olduğunda büyük/küçük harfe duyarlı işleçler kullanın.
	in komutunu kullanma	Kullanma in~
	contains_cs komutunu kullanma	Kullanma contains	kullanabiliyorsanız ve kullanamıyorsanızcontainscontains_cs/, bu daha da iyidir.has/has_cs
Metin arama	Belirli bir sütuna bakma	Kullanma *	* tüm sütunlarda tam metin araması yapar.
Milyonlarca satır arasında dinamik nesnelerden alan ayıklama	Sorgularınızın çoğu milyonlarca satırdaki dinamik nesnelerden alanlar ayıklarsa, alma zamanında sütununuzu gerçekleştirin.		Bu şekilde sütun ayıklama için yalnızca bir kez ödeme yaparsınız.
Dinamik nesnelerdeki nadir anahtarlar/değerler için arama	MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value" komutunu kullanma	Kullanma MyTable | where DynamicColumn.SomeKey == "Rare value"	Bu şekilde, kayıtların çoğunu filtreler ve yalnızca geri kalanları JSON ayrıştırma yaparsınız.
let birden çok kez kullandığınız bir değere sahip deyim	materialize() işlevini kullanma		kullanma materialize()hakkında daha fazla bilgi için bkz . materialize(). Daha fazla bilgi için bkz . Adlandırılmış ifadeler kullanan sorguları iyileştirme.
1 milyardan fazla kayda dönüştürme 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 en sonunda kullanınlimit [small number].		Bilinmeyen veri kümeleri üzerinde ilişkisiz sorgular çalıştırmak, istemciye döndürülecek gb'ler sonuç verebilir ve bu da yavaş bir yanıta ve meşgul bir kümeye neden olabilir.
Büyük/küçük harfe duyarlı olmayan karşılaştırmalar	Col =~ "lowercasestring" komutunu kullanma	Kullanma tolower(Col) == "lowercasestring"
Verileri zaten 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ütunlarda filtreleme	Tablo sütununa göre filtreleyin.	Hesaplanmış sütuna filtre uygulamayın.
	T | where predicate(*Expression*) komutunu kullanma	Kullanma T | extend _value = *Expression* | where predicate(_value)
summarize işleci	Özetleme işleci yüksek kardinaliteye sahip olduğunda group by keyshint.shufflekey=<key> kullanın.		Yüksek kardinalite ideal olarak 1 milyondan fazladır.
join işleci	İlk satır olacak kadar 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	Kümeler arasında, birleştirmenin "sağ" tarafında sorguyu çalıştırın ve verilerin çoğu burada bulunur.
Sol taraf küçük ve sağ taraf büyük olduğunda katıl	hint.strategy=broadcast kullanma		Küçük, 100 MB'a kadar veriyi ifade eder.
Sağ taraf küçük ve sol taraf büyük olduğunda katıl	işleci yerine arama işlecinijoin kullanma		Aramanın sağ tarafı onlarca MB'den büyükse sorgu başarısız olur.
her iki taraf da çok büyük olduğunda katıl	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 kullanma	Birkaç extract() deyim kullanmayın.	Örneğin, şunun gibi değerler: "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ...."
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 azaltacak ve sorgunun semantiğini kullanmaya devam edecek tüm olası işleçleri gönder.		Örneğin, filtreler veya proje için yalnızca gerekli sütunlar. Daha fazla bilgi için bkz . Adlandırılmış ifadeler 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, belirli bir koşula göre filtrelendiğinde kayıtların yüzde kaçının filtrelendiğidir. Yüksek oranda seçmeli bir koşul, koşulu uyguladıktan sonra yalnızca birkaç kaydın kaldığı ve daha sonra etkili bir şekilde işlenmesi gereken veri miktarını azaltacağı anlamına gelir.

Önem sırasına göre:

• Yalnızca verileri sorgu tarafından gerekli olan başvuru tabloları. Ö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 kapsamlarını oluşturarak verileri ortadan kaldırmak için etkili bir yol sağlar.

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

• Sorgu işlecini kullanırken where , koşul sırasının (tek bir işleçte veya ardışık bir dizi işleçle) judicious kullanımı, aşağıda açıklandığı gibi sorgu performansı üzerinde önemli bir etkiye sahip olabilir.

• Önce tüm parça koşullarını uygulayın. Başka bir deyişle , extent_id() işlevini kullanan koşul, extent_tags() işlevini kullanan koşul ve tablonun veri bölümleri (tanımlandıysa) üzerinde çok seçici olan koşullarda olduğu gibi önce uygulanmalıdır.

• Ardından tablo sütunlarına göre datetime hareket eden koşullar uygulayın. Kusto, bu tür sütunlarda çok 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 için ve sütunlarına göre stringdynamic hareket eden koşullar uygulayın. Koşul, seçiciliğe göre sıralanmalıdır (örneğin, milyonlarca kullanıcı olduğunda bir kullanıcı kimliği aramak çok seçicidir ve genellikle dizinin çok verimli olduğu bir terim aramasıdır.)

• 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, koşulları olmayan ve dizin oluşturmadan yararlanılmaması gereken "@!@!" içeren ' gibi koşullar için), sütunları daha az veriyle tarayanların ilk sırada yer alacak şekilde koşulları sıralayın. Bu, 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şvurulur. Örneğin, tabloya T basit T olarak ( nitelenmemiş ad) veya bir veritabanı niteleyicisi kullanılarak (örneğin, database("DB").T tablo adlı DBbir veritabanındayken) veya tam ad (örneğin cluster("X.Y.kusto.windows.net").database("DB").T) kullanılarak başvurulabilir.

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

1. Nitelenmemiş adların (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 diğer veritabanlarına ait varlıklar (özellikle bu veritabanları farklı bir kümede olduğunda). Nitelikli adlardan kaçınmak okuyucunun doğru olanı yapmasını sağlar.

Not

Bu, nitelenmiş adların performans açısından kötü olduğunu söylemek değildir. Aslında Kusto, çoğu durumda tam adın kapsamdaki 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" olarak belirleyebilir. Ancak, yukarıda belirtilen nedenlerle gerekli olmadığında buna güvenmemenizi öneririz.