Sorgu sınırları

  • Makale

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 sınır olmadan hizmet kaynaklarını tekeline alması doğal bir risktir. Kusto, varsayılan sorgu sınırları biçiminde çeşitli yerleşik korumalar 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ığı , bir kümenin aynı anda çalışan çeşitli isteklere uyguladığı bir sınırdır.

  • Sınırın varsayılan değeri, kümenin ü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 küme için varsayılan sınır olur 16 cores x10 = 160.
  • Varsayılan değer, iş yükü grubunun istek hızı sınırı ilkesidefault yapılandırılarak değiştirilebilir.
    • Bir kümede eşzamanlı olarak çalışabilen isteklerin gerçek sayısı çeşitli faktörlere bağlıdır. En baskın faktörler küme SKU'su, kümenin 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.

Daha fazla bilgi için bkz. Azure Veri Gezgini ile yüksek eşzamanlılık için iyileştirme.

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 ilgilenmek 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 yararlı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 küçültün. Strateji, sorgu çıktısının başka bir işleme sistemine beslendiği ve ardından başka toplamalar yaptığı senaryolarda yararlı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 bayrakları kullanarak set hizmete bu sorgu sınırını göstermesini bildirin.

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

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

Örnek:

set notruncation;
MyTable | take 1000000

Değerini (bayt cinsinden maksimum veri boyutu, varsayılan değer 64 MB) ve truncationmaxrecords (maksimum kayıt sayısı, varsayılan değer 500.000 olarak) ayarlayarak truncationmaxsize sonuç kesilmesi üzerinde daha iyi denetime sahip olmak da mümkündür. Örneğin, aşağıdaki sorgu sonucun kesilmesini 1.105 kayıtta veya 1 MB(hangisi aşılırsa) olacak şekilde ayarlar.

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

Sonuç kesme sınırını kaldırmak, toplu verileri Kusto'nun dışına taşımayı amaçladığınız anlamına gelir.

Sonuç kesme sınırını, dışarı aktarma amacıyla komutunu kullanarak .export 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 bkz. HelloKustoV2 uygulaması.

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 kümenin benzer efektlerle kümeler arası sorguda başka bir kümeye verdiği alt sorgulara da 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.

  • ayarlanırsa ve herhangi biri truncationmaxsize, truncationmaxrecordsveya query_take_max_records ayarlanmışsa notruncation - notruncation yoksayılır.
  • vetruncationmaxrecords/veya query_take_max_records birden çok kez ayarlanırsatruncationmaxsize, her özellik için daha düşük değer uygulanır.

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

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

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

Bu sınıra ulaşıldığında, metnini E_RUNAWAY_QUERYiçeren bir iletiyle kısmi bir 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.

Kısmi sorgu hatasını tetikleyebilecek ek bir E_RUNAWAY_QUERY sınır, tek bir işleç tarafından tutulan en büyük birikmiş dize boyutu sınırıdı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 , joinsummarizeveya make-seriesşeklindedir. 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ının üst sınırını 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 , joinveya make-series işleçleri kullanılıyorsasummarize, tek bir makinedeki bellek baskısını azaltmak için karıştırma sorgusu stratejisini kullanabilirsiniz.

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

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ın değiştirilmesini destekler. Örneğin, Kusto.Explorer'da Araçlar>Seçenekleri* >Bağlantılar>Sorgu Sunucusu Zaman Aşımı'nı kullanın.
  • SDK'lar program aracılığıyla özelliğin zaman aşımını ayarlamayı servertimeout destekler. Örneğin, .NET SDK'sında bu, türünde System.TimeSpanbir değer ayarlanarak bir istemci isteği özelliği aracılığıyla yapılır.

Zaman aşımları hakkında notlar

  • İstemci tarafında, oluşturulan istekten yanıt istemciye gelmeye başlayana kadar zaman aşımı uygulanır. İstemcide 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.

Not

Azure Veri Gezgini web kullanıcı arabiriminde, Kusto.Explorer'da, Kusto.Cli'da, Power BI'da ve SDK kullanırken zaman aşımlarını ayarlama hakkında adım adım kılavuz için bkz. zaman aşımı sınırlarını ayarlama.

Sorgu CPU kaynak kullanımı sınırı

Kusto, sorguları çalıştırmanıza ve kümenin sahip olduğu kadar CPU kaynağı 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ı sağlar. Diğer zamanlarda, 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, iş parçacığı kullanımı için fanout faktörünü denetler. Bu özellik %100 olarak ayarlandığında, küme her düğümdeki tüm CPU'ları atar. Örneğin, Azure D14 düğümlerine dağıtılan bir kümede 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 kümedeki sorgu düğümlerinden kaç tane kullanılacağını denetler. Benzer şekilde çalışır.

veya query_fanout_threads_percent birden çok kez ayarlanırsaquery_fanout_nodes_percent, örneğin, hem istemci isteği özelliklerinde hem de bir set deyim kullanılarak - her özellik için daha düşük değer geçerlidir.

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şı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:

  • birbirine zincirlenmiş ikili işleçlerin uzun bir listesi. Örnek:
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 bir sorgu, özellikle de birleşimin varsayılan özelliği "dış" birleşim şemasını döndürmektir (yani, bu çıkış temel alınan tablonun tüm sütunlarını içerecektir).

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

İlgili içerik