Sorgu sınırları

Şunlar için geçerlidir: ✅Microsoft Fabric✅

Kusto, büyük veri kümelerini barındıran ve tüm ilgili verileri bellek içinde tutarak sorguları karşılamaya çalışan geçici bir sorgu altyapısıdır. Sorguların hizmet kaynaklarını sınır olmadan tekeline alma riski vardır. 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 isteklere uygulanan 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.
• varsayılan değer, iş yükü grubunun istek hızı sınırı ilkesidefaultdeğiştirilebilir.
  • Veritabanında eşzamanlı olarak çalışabilen isteklerin gerçek sayısı çeşitli faktörlere bağlıdır. En baskın faktörler veritabanı SKU'su, veritabanının kullanılabilir kaynakları ve kullanım desenleridir. İlke, üretim benzeri kullanım desenlerinde gerçekleştirilen yük testlerine göre yapılandırılabilir.

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

Sonuç kesilmesi , sorgu tarafından döndürülen sonuç kümesinde varsayılan olarak ayarlanan 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ı, şu 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 olur:

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 hatayla başa çıkmak için çeşitli stratejiler vardır.

• 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. Strateji, sorgu çıktısının başka bir işleme sistemine beslendiği ve ardından 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ğıda listelenen deyimleri veya istemci isteği özelliklerindeki setbayrakları kullanarak hizmete bu sorgu sınırını gizlemesini bildirin.

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

• Özetle işleç grubunu kullanın ve sorgu çıkışındaki benzer kayıtlar üzerinde toplama yapı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

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 denetim sahibi olmak da mümkündür. Örneğin, aşağıdaki sorgu sonuç kesme işleminin 1.105 kayıtta veya 1 MB(hangisi aşılırsa) gerçekleşmesini ayarlar.

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

Birden çok sonuç kesme özelliğini ayarlama

Deyimler kullanılırken set ve/veya istemci isteği özelliklerinde bayraklar belirtilirken aşağıdakiler geçerlidir.

• ayarlandıysa ve herhangi biri notruncation, truncationmaxsizeveya truncationmaxrecords da ayarlandıysa query_take_max_records - notruncation yoksayılır.
• ve/veya truncationmaxsize birden çok kez ayarlanırsatruncationmaxrecords, query_take_max_records değer uygulanır.

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

Kusto, "runaway" sorgularına karşı korumak için her sorgu işlecinin kullanabileceği belleği sınırlar. Bu sınıra, bellekte önemli veriler tutarak çalışan ve joingibi summarize bazı sorgu işleçleri ulaşabilir. Varsayılan olarak sınır 5 GB'tır (düğüm başına) ve istek seçeneği maxmemoryconsumptionperiteratorayarlanarak artırılabilir:

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

Bu sınıra ulaşıldığında, metnini E_RUNAWAY_QUERYiçeren bir iletiyle kısmi sorgu hatası gönderilir.

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

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

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

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

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

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

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

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

Birden çok kez ayarlanırsa maxmemoryconsumptionperiterator , örneğin hem istemci isteği özelliklerinde hem de bir set deyimi kullanıldığında, daha düşük değer uygulanır.

Bu istek seçeneği için desteklenen en yüksek değer 32212254720 (30 GB).

Kısmi sorgu hatasını tetikleyebilecek ek bir E_RUNAWAY_QUERY sınır, tek bir işleç tarafından tutulan dizelerin en büyük birikmiş boyutu üzerindeki bir sınırdır. Bu sınır yukarıdaki istek seçeneği tarafından geçersiz kılınamaz:

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ştirmeniz gerekir. (Bu, sorgunun performansını da artırabilir.)

her durumda E_RUNAWAY_QUERYek 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. Aşağıdaki 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 | ...

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

Düğüm başına sorgu başına maksimum bellek, "kaçak" sorgulara karşı koruma sağlamak için kullanılan bir diğer sınırdır. İstek seçeneğiyle max_memory_consumption_per_query_per_nodegösterilen bu sınır, belirli bir sorgu için tek bir düğümde kullanılabilecek bellek miktarına bir üst sınır ayarlar.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Birden çok kez ayarlanırsa max_memory_consumption_per_query_per_node , örneğin hem istemci isteği özelliklerinde hem de bir set deyimi kullanıldığında, 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ı , tüm isteklere uygulanan bir hizmet tarafı zaman aşımıdır. Kusto'da birden çok noktada çalışan isteklerde (sorgular ve yönetim komutları) zaman aşımı uygulanır:

• 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ğer artırılabilir (bir saatte eşlenir).

• Ç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çlar>*>> 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 bu, türünde bir değer ayarlanarak bir System.TimeSpan aracılığıyla gerçekleştirilir.

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ırmanıza ve veritabanındaki tüm kullanılabilir CPU kaynaklarını kullanmanıza olanak tanır. Birden fazla çalıştırılıyorsa sorgular arasında adil bir hepsini bir kez deneme gerçekleştirmeyi 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 belirli bir sorgu için başka bir değere azaltılabilir.

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

İkinci query_fanout_nodes_percent, alt sorgu dağıtım işlemi başına kaç sorgu düğümünün kullanılacağını denetler. Benzer şekilde çalışır.

Veya query_fanout_nodes_percent birden çok kez ayarlanırsaquery_fanout_threads_percent, örneğin, hem istemci isteği özelliklerinde hem de bir set deyimi kullanıldığında, 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şlenmek için çok karmaşık kabul edilir 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.

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

• birlikte 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")

• çok geniş şema analizi çalıştıran bir birleşim işlecine sahip olan sorgu, özellikle de birleşimin varsayılan çeşidinin "dış" birleşim şeması döndürmek olduğunu (yani, bu çıktının temel alınan tablonun tüm sütunlarını içereceği anlamına gelir).

Bu durumda öneri, sorguyu gözden geçirmek ve sorgu tarafından kullanılan sütunları azaltmaktır.

İlgili içerik

• En iyi sorgu yöntemleri