Sorgu sınırları

Sürüm açılan listesini kullanarak hizmetler arasında geçiş yapın. Gezinti hakkında daha fazla bilgi edinin.
Şunlar için geçerlidir: ✅ Microsoft Fabric ✅ Azure Veri Gezgini ✅ Azure İzleyici ✅ Microsoft Sentinel

Kusto, büyük veri kümelerini barındıran ve tüm ilgili verileri bellekte tutarak sorguları karşılamaya çalışan geçici bir sorgu altyapısıdır. Sorguların hizmet kaynaklarını sınır olmadan tekeline alması doğal bir risktir. Kusto, varsayılan sorgu sınırları biçiminde birkaç yerleşik koruma sağlar. Bu sınırları kaldırmayı düşünüyorsanız, önce bunu yaparak gerçekten değer kazanıp kazanmadığınızı belirleyin.

İstek eşzamanlılığı sınırı

İstek eşzamanlılığı , aynı anda çalışan çeşitli istekler için bir sınırdır.

• Sınırın varsayılan değeri, veritabanının üzerinde çalıştığı SKU'ya bağlıdır ve şu şekilde hesaplanır: Cores-Per-Node x 10.
  • Örneğin, her makinenin 16 sanal çekirdeğinin bulunduğu D14v2 SKU'da ayarlanmış bir veritabanı için varsayılan sınırdır 16 cores x10 = 160.
• İş yükü grubunun istek hızı sınırı ilkesinidefault yapılandırarak varsayılan değeri değiştirebilirsiniz.
  • Veritabanında eşzamanlı olarak çalışabilen isteklerin gerçek sayısını çeşitli faktörler etkiler. En baskın faktörler veritabanı SKU'su, veritabanının kullanılabilir kaynakları ve kullanım desenleridir. İlkeyi üretim benzeri kullanım desenleri üzerinde gerçekleştirilen yük testlerine göre yapılandırın.

Sonuç kümesi boyutu sınırı (sonuç kesilmesi)

Sonuç kesilmesi , sorgu tarafından döndürülen sonuç kümesinde varsayılan bir sınırdır. Kusto, istemciye döndürülen kayıt sayısını 500.000 ile ve bu kayıtların genel veri boyutunu 64 MB ile sınırlar. Bu sınırlardan biri aşıldığında, sorgu "kısmi sorgu hatası" ile başarısız olur. Genel veri boyutunun aşılması aşağıdaki iletiyle bir özel durum oluşturur:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

Kayıt sayısının aşılması şu özel durumla başarısız oluyor:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Bu hatayı çözmek için çeşitli stratejiler kullanabilirsiniz.

• Sorguyu yalnızca ilginç veriler döndürecek şekilde değiştirerek sonuç kümesi boyutunu küçültün. İlk başarısız sorgu çok "geniş" olduğunda bu strateji kullanışlıdır. Örneğin, sorgu gerekli olmayan veri sütunlarını yansıtmaz.
• Toplamalar gibi sorgu sonrası işlemeyi sorgunun kendisine kaydırarak sonuç kümesi boyutunu azaltın. Bu strateji, sorgu çıktısının başka bir işleme sistemine beslendiği ve bu sistemin daha sonra başka toplamalar yaptığı senaryolarda kullanışlıdır.
• Hizmetten büyük veri kümelerini dışarı aktarmak istediğinizde sorgulardan veri dışarı aktarmayı kullanmaya geçin.
• Aşağıdaki bölümde listelenen deyimleri veya set bayrakları kullanarak hizmete bu sorgu sınırını gizlemesini bildirin.

Sorgu tarafından üretilen sonuç kümesi boyutunu küçültme yöntemleri şunlardır:

• Sorgu çıkışındaki benzer kayıtları gruplandırmak ve toplamak için summarize işlecini kullanın. take_any toplama işlevini kullanarak bazı sütunları örnekle.
• Sorgu çıkışını örneklemek için bir take işleci kullanın.
• Geniş serbest metin sütunlarını kırpmak için alt dize işlevini kullanın.
• Sonuç kümesinden herhangi bir ilgi çekici sütunu bırakmak için proje işlecini kullanın.

İstek seçeneğini kullanarak sonuç kesilmesini notruncation devre dışı bırakabilirsiniz. Bir tür sınırlamanın hala geçerli olması önerilir.

Örneğin:

set notruncation;
MyTable | take 1000000

Ayrıca değerini (bayt cinsinden en fazla veri boyutu, varsayılan değer 64 MB) ve truncationmaxsize (en fazla kayıt sayısı, varsayılan değer 500.000) ayarlayarak truncationmaxrecords sonuç kesilmesi üzerinde daha iyi denetime sahip olabilirsiniz. Örneğin, aşağıdaki sorgu kümeleri sonuç kesme işleminin 1.105 kayıtta veya 1 MB'de (hangisi aşılırsa) gerçekleşmesini sağlar.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Sonuç kesme sınırının kaldırılması, toplu verileri Kusto dışına taşımayı düşündüğünüz anlamına gelir.

Sonuç kesme sınırını, komutunu kullanarak .export dışarı aktarma amacıyla veya daha sonra toplama amacıyla kaldırabilirsiniz. Daha sonra toplamayı seçerseniz Kusto kullanarak toplamayı göz önünde bulundurun.

Kusto, "sonsuz büyük" sonuçları çağırana akışla aktararak işleyebilen birçok istemci kitaplığı sağlar. Bu kitaplıklardan birini kullanın ve akış moduna yapılandırın. Örneğin, .NET Framework istemcisini (Microsoft.Azure.Kusto.Data) kullanın ve bağlantı dizesi akış özelliğini true olarak ayarlayın veya sonuçları her zaman akışa alan ExecuteQueryV2Async() çağrısını kullanın. ExecuteQueryV2Async() kullanma örneği için helloKustoV2 uygulamasına bakın.

C# akış alımı örnek uygulamasını da yararlı bulabilirsiniz.

Sonuç kesilmesi yalnızca istemciye döndürülen sonuç akışına değil varsayılan olarak uygulanır.

Ayrıca, bir Eventhouse'un benzer efektlere sahip bir Çapraz Eventhouse sorgusunda başka bir Eventhouse'a verdiği tüm alt sorgulara varsayılan olarak uygulanır.

Birden çok sonuç kesme özelliğini ayarlama

İstemci set deyimler kullandığınızda veya bayraklar belirttiğinizde aşağıdaki kurallar geçerlidir.

• , , notruncationveya da ayarlarsanıztruncationmaxsizetruncationmaxrecords, hizmet öğesini yoksayarquery_take_max_recordsnotruncation.
• , truncationmaxsizeveya truncationmaxrecords birden çok kez ayarlarsanızquery_take_max_records, hizmet her özellik için daha düşük değeri kullanır.

Sorgu işleçleri tarafından kullanılan bellek sınırı

Her sorgu işlecinin düğüm başına tükettiği bellek miktarını denetlemek için Yineleyici başına en fazla bellek tüketimi sınırını yapılandırabilirsiniz. ve joingibi summarize bazı sorgu işleçleri bellekte önemli verileri tutar. İstek seçeneğinin maxmemoryconsumptionperiteratorvarsayılan değerini artırarak, işleç başına daha fazla bellek gerektiren sorgular çalıştırabilirsiniz.

Bu istek seçeneği için desteklenen en yüksek değer 32.212.254.720 'dir (30 GB). hem istemci isteği özelliklerinde hem de deyimini set kullanarak birden çok kez ayarlarsanızmaxmemoryconsumptionperiterator, daha düşük değer uygulanır.

Sorgu, işleç başına yapılandırılan bellek sınırına ulaştığında, kısmi bir sorgu hata iletisi görüntülenir ve metnini E_RUNAWAY_QUERYiçerir.

Örneğin:

The ClusterBy operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

Örneğin, bu sorgu yineleyici başına en fazla bellek tüketimini 15 GB olarak belirler:

set maxmemoryconsumptionperiterator=16106127360;
MyTable | summarize count() by Use

Kısmi sorgu hatasını tetikleyebilecek bir diğer sınır, tek bir E_RUNAWAY_QUERY işleç tarafından tutulan dizelerin en büyük birikmiş boyutudur. Daha önce açıklanan istek seçeneği bu sınırı geçersiz kılamaz.

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Bu sınır aşıldığında, büyük olasılıkla ilgili sorgu işleci bir join, summarizeveya make-seriesolacaktır.

Sınırı geçici olarak çözmek için sorguyu karıştır sorgu stratejisini kullanacak şekilde değiştirin. Bu değişikliğin sorgunun performansını artırma olasılığı da yüksektir.

her durumda E_RUNAWAY_QUERY, başka bir seçenek (istek seçeneğini ayarlayarak ve sorguyu karıştırma stratejisi kullanacak şekilde değiştirerek sınırı artırmanın ötesinde) örneklemeye geçmektir. Örnekleme, sorgu tarafından işlenen veri miktarını azaltır ve bu nedenle sorgu işleçleri üzerindeki bellek baskısını azaltır.

Bu iki sorgu örneklemenin nasıl yapılacağını gösterir. İlk sorgu, rastgele bir sayı oluşturucu kullanan istatistiksel örneklemedir. İkinci sorgu, veri kümesindeki bir sütunun (genellikle bir kimlik) karması yapılarak yapılan belirleyici örneklemedir.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

hem joinhem de summarize gibi hint.shufflekey mekanizmaları kullanma hakkında daha fazla bilgi için bkz. Kusto Sorgu Dili sorguları için en iyi yöntemler.

Düğüm başına bellek sınırı

Düğüm başına sorgu başına maksimum bellek , kaçak sorgulara karşı koruma sağlayan bir diğer sınırdır. İstek seçeneği max_memory_consumption_per_query_per_node , tek bir düğümün belirli bir sorgu için kullanabileceği bellek miktarına bir üst sınır ayarlar.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Hem istemci isteği özelliklerinde hem de deyiminde set olduğu gibi birden çok kez ayarlarsanızmax_memory_consumption_per_query_per_node, daha düşük değer uygulanır.

Sorguda , summarizeveya işleçleri kullanılıyorsajoin, tek bir makinedeki bellek baskısını make-series stratejisini kullanabilirsiniz.

Yürütme zaman aşımını sınırla

Sunucu zaman aşımı , hizmetin tüm istekler için geçerli olduğu bir hizmet tarafı zaman aşımıdır. Kusto, birden çok noktada çalışan isteklerde (sorgular ve yönetim komutları) zaman aşımı uygular:

• istemci kitaplığı (kullanılıyorsa)
• isteği kabul eden hizmet uç noktası
• isteği işleyen hizmet altyapısı

Varsayılan olarak, zaman aşımı sorgular için dört dakika ve yönetim komutları için 10 dakika olarak ayarlanır. Gerekirse bu değeri bir saate kadar artırabilirsiniz.

• Çeşitli istemci araçları, genel veya bağlantı başına ayarlarının bir parçası olarak zaman aşımını değiştirmeyi destekler. Örneğin Kusto.Explorer'da Araç>Seçenekleri>Bağlantıları>Sorgu Sunucusu Zaman Aşımı'nı kullanın.
• Program aracılığıyla SDK'lar özelliğinde zaman aşımının ayarlanmasını servertimeout destekler. Örneğin, .NET SDK'sında, türünde bir değer System.TimeSpanayarlayarak bu özelliği bir istemci isteği özelliği aracılığıyla ayarlayın.

Zaman aşımları hakkında notlar

• İstemci tarafında, zaman aşımı, yanıt istemciye gelmeye başlayana kadar oluşturulan istekten uygulanır. İstemcideki yükün okunma süresi zaman aşımının bir parçası olarak değerlendirilmez. Çağıranın verileri akıştan ne kadar hızlı çektiğine bağlıdır.
• Ayrıca istemci tarafında, kullanılan gerçek zaman aşımı değeri, kullanıcı tarafından istenen sunucu zaman aşımı değerinden biraz daha yüksektir. Bu fark, ağ gecikme sürelerine izin vermektir.
• İzin verilen istek zaman aşımı üst sınırını otomatik olarak kullanmak için istemci isteği özelliğini norequesttimeout olarak trueayarlayın.

Sorgu CPU kaynağı kullanımı sınırı

Kusto sorguları çalıştırır ve veritabanındaki tüm kullanılabilir CPU kaynaklarını kullanır. Birden fazla sorgu çalışıyorsa, sorgular arasında adil bir hepsini bir kez deneme yapmayı dener. Bu yöntem sorgu tanımlı işlevler için en iyi performansı verir. Diğer durumlarda, belirli bir sorgu için kullanılan CPU kaynaklarını sınırlamak isteyebilirsiniz. Örneğin bir arka plan işi çalıştırırsanız, sistem eşzamanlı satır içi sorgulara yüksek öncelik vermek için daha yüksek gecikme sürelerini tolere edebilir.

Kusto, sorgu çalıştırırken iki istek özelliği belirtmeyi destekler. Özellikler query_fanout_threads_percent ve query_fanout_nodes_percent. Her iki özellik de varsayılan olarak en yüksek değere (100) sahip tamsayılardır, ancak bunları belirli bir sorgu için azaltabilirsiniz.

İlk özellik olan query_fanout_threads_percent, iş parçacığı kullanımı için fanout faktörünü denetler. Bu özelliği 100%olarak ayarladığınızda, sorgu her düğümdeki tüm CPU'ları kullanır. Örneğin, Azure D14 düğümlerine dağıtılan 16 CPU. Bu özelliği 50%olarak ayarladığınızda sorgu CPU'ların yarısını kullanır ve bu şekilde devam eder. Sayılar bir CPU'nun tamamına yuvarlandığından özellik değerini 0 olarak ayarlamak güvenlidir.

İkinci özellik olan query_fanout_nodes_percent, alt sorgu dağıtım işlemi başına kullanılacak sorgu düğümlerinin sayısını denetler. Benzer şekilde çalışır.

Örneğin, hem istemci isteği özelliklerinde hem de deyimini set kullanarak veya birden çok kez ayarlarsanız query_fanout_nodes_percentquery_fanout_threads_percent, her özellik için daha düşük değer uygulanır.

Sorgu karmaşıklığı sınırı

Sorgu yürütme sırasında, sorgu metni sorguyu temsil eden ilişkisel işleçler ağacına dönüştürülür. Ağaç derinliği iç eşiği aşarsa, sorgu işlenemeyecek kadar karmaşıktır ve hata koduyla başarısız olur. Hata, ilişkisel işleç ağacının sınırlarını aştığını gösterir.

Sorgu karmaşıklığı aşıldı

Sorgu, altyapının derleyemeyecek kadar karmaşık. Bu karmaşıklık genellikle sorgu planı oluşturma işlemi çok fazla kaynak tükettiğinde oluşur. Yaygın nedenler şunlardır:

• Büyük bir veritabanında kullanma union * gibi birçok tablo arasında büyük birleşimler.
• İç içe alt sorgular.
• Birbirine başvuran birçok deyim düzeyi let .

Sorgu planı boyutu veya karmaşıklığı belirlenen sınırları aşıyor

Sorgu, işlenemeyecek kadar büyük bir sorgu planı oluşturur. Yaygın nedenler şunlardır:

• Yayın birleştirmenin sol tarafı çok fazla veri üretir.
• tarafından toscalar() döndürülen sonuçlar çok büyük.
• İfadenin in() içindeki sonuçlar çok büyük. Örneğin, alt sorgunun çok fazla değer döndürdüğü bir in (subquery) yer.

Aşağıdaki örneklerde, sorgunun bu sınırları aşmasına ve başarısız olmasına neden olabilecek yaygın sorgu desenleri gösterilmektedir:

• Birbirine zincirlenmiş ikili işleçlerin uzun bir listesi. Örneğin:

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

Bu özel durum için işlecini kullanarak sorguyu in() yeniden yazın.

T
| where Column in ("value1", "value2".... "valueN")

• Birleşim işleci kullanan ve çok geniş şema analizi çalıştıran bir sorgu. Bu sorun, birleşimin varsayılan çeşidinin "dış" birleşim şeması döndürmesi nedeniyle oluşur. Bu şema, çıktının temel alınan tablonun tüm sütunlarını içerdiği anlamına gelir.

Sorguyu gözden geçirin ve sorgunun kullandığı sütun sayısını azaltın.

İlgili içerik

• En iyi sorgu yöntemleri