Azure Cosmos DB kullanırken karşılaşılan sorgu sorunlarını giderme
UYGULANANLAR: 
NOSQL
Bu makalede, Azure Cosmos DB'de sorgu sorunlarını gidermek için önerilen genel bir yaklaşım açıklanmaktadır. Bu makalede açıklanan adımları olası sorgu sorunlarına karşı eksiksiz bir savunma olarak değerlendirmemeniz gerekir, ancak en yaygın performans ipuçlarını buraya ekledik. NoSQL için Azure Cosmos DB'de yavaş veya pahalı sorguların sorunlarını gidermek için bu makaleyi başlangıç noktası olarak kullanmalısınız. Ayrıca yavaş çalışan veya önemli miktarda aktarım hızı kullanan sorguları belirlemek için tanılama günlüklerini de kullanabilirsiniz. MongoDB için Azure Cosmos DB API'sini kullanıyorsanız MongoDB için Azure Cosmos DB API'sini kullanmanız gerekir sorgu sorun giderme kılavuzu
Azure Cosmos DB'deki sorgu iyileştirmeleri genel olarak aşağıdaki gibi kategorilere ayrılır:
- Sorgunun İstek Birimi (RU) ücretini azaltan iyileştirmeler
- Yalnızca gecikme süresini azaltan iyileştirmeler
Sorgunun RU ücretini azaltırsanız genellikle gecikme süresini de azaltırsınız.
Bu makalede , beslenme veri kümesini kullanarak yeniden oluşturabileceğiniz örnekler sağlanır.
Yaygın SDK sorunları
Bu kılavuzu okumadan önce, sorgu altyapısıyla ilgili olmayan yaygın SDK sorunlarını göz önünde bulundurmanız yararlı olur.
- Sorgu için şu SDK Performansı ipuçlarını izleyin.
- Bazen sorgularda, sonraki bir sayfada sonuçlar olsa bile boş sayfalar bulunabiliyor. Bunun nedenleri:
- SDK birden çok ağ çağrısı yapıyor olabilir.
- Sorgunun belgeleri alması uzun zaman alıyor olabilir.
- Tüm sorgularda, sorgunun devam etmesine olanak tanıyan devamlılık belirteci vardır. Sorguyu tamamen boşalttığınızdan emin olun. Birden çok sonuç sayfasını işleme hakkında daha fazla bilgi edinin
Sorgu ölçümlerini alma
Azure Cosmos DB'de bir sorguyu iyileştirdiğinizde, ilk adım her zaman sorgunuz için sorgu ölçümlerini almaktır . Bu ölçümler Azure portal aracılığıyla da kullanılabilir. Sorgunuzu Veri Gezgini çalıştırdığınızda sorgu ölçümleri Sonuçlar sekmesinin yanında görünür:
Sorgu ölçümlerini aldıktan sonra, sorgunuzun Alınan Belge Sayısı'nı Çıkış Belgesi Sayısı ile karşılaştırın. Bu makalede gözden geçirecek ilgili bölümleri belirlemek için bu karşılaştırmayı kullanın.
Alınan Belge Sayısı, sorgu altyapısının yüklenmesi gereken belge sayısıdır. Çıktı Belge Sayısı, sorgunun sonuçları için gereken belge sayısıdır. Alınan Belge SayısıÇıktı Belge Sayısı'nın önemli ölçüde üstündeyse, sorgunuzun dizin kullanamayan ve tarama yapması gereken en az bir bölümü vardı.
Senaryonuz için ilgili sorgu iyileştirmelerini anlamak için aşağıdaki bölümlere bakın.
Sorgu'nun RU ücreti çok yüksek
Alınan Belge Sayısı, Çıktı Belge Sayısından oldukça fazla
Alınan Belge Sayısı, Çıktı Belge Sayısı'na yaklaşık olarak eşittir
Birden çok özellik üzerinde filtresi olan sorguları iyileştirin.
Hem filtre hem de ORDER BY yan tümcesine sahip sorguları iyileştirin.
Sorgu'nun RU ücreti kabul edilebilir ancak gecikme süresi hala çok yüksek
Alınan Belge Sayısı'nın Çıktı Belge Sayısını aştığı sorgular
Alınan Belge Sayısı, sorgu altyapısının yüklenmesi gereken belge sayısıdır. Çıktı Belge Sayısı, sorgu tarafından döndürülen belge sayısıdır. Alınan Belge SayısıÇıktı Belge Sayısı'nın önemli ölçüde üstündeyse, sorgunuzun dizin kullanamayan ve tarama yapması gereken en az bir bölümü vardı.
Aşağıda, dizin tarafından tam olarak sunulmamış bir tarama sorgusu örneği verilmiştir:
Sorgu:
SELECT VALUE c.description
FROM c
WHERE UPPER(c.description) = "BABYFOOD, DESSERT, FRUIT DESSERT, WITHOUT ASCORBIC ACID, JUNIOR"
Sorgu ölçümleri:
Retrieved Document Count : 60,951
Retrieved Document Size : 399,998,938 bytes
Output Document Count : 7
Output Document Size : 510 bytes
Index Utilization : 0.00 %
Total Query Execution Time : 4,500.34 milliseconds
Query Preparation Times
Query Compilation Time : 0.09 milliseconds
Logical Plan Build Time : 0.05 milliseconds
Physical Plan Build Time : 0.04 milliseconds
Query Optimization Time : 0.01 milliseconds
Index Lookup Time : 0.01 milliseconds
Document Load Time : 4,177.66 milliseconds
Runtime Execution Times
Query Engine Times : 322.16 milliseconds
System Function Execution Time : 85.74 milliseconds
User-defined Function Execution Time : 0.00 milliseconds
Document Write Time : 0.01 milliseconds
Client Side Metrics
Retry Count : 0
Request Charge : 4,059.95 RUs
Alınan Belge Sayısı (60.951) Çıktı Belge Sayısı'nın (7) çok daha yüksek olduğundan, bu sorgunun belge taramasına neden olduğu anlamına gelir. Bu durumda, UPPER() sistem işlevi dizin kullanmaz.
Dizin oluşturma ilkesine gerekli yolları ekleme
Dizin oluşturma ilkeniz yan tümceler, yan tümcelerJOIN, ORDER BY ve çoğu sistem işlevinde WHERE bulunan tüm özellikleri kapsamalıdır. Dizin ilkesinde belirtilmiş istenen yollar JSON belgelerindeki özelliklerle eşleşmelidir.
Not
Azure Cosmos DB dizin oluşturma ilkesindeki özellikler büyük/küçük harfe duyarlıdır
Beslenme veri kümesinde aşağıdaki basit sorguyu çalıştırırsanız, yan tümcesindeki WHERE özellik dizine eklendiğinde çok daha düşük bir RU ücreti gözlemlersiniz:
Özgün
Sorgu:
SELECT *
FROM c
WHERE c.description = "Malabar spinach, cooked"
Dizin oluşturma ilkesi:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/description/*"
}
]
}
RU ücreti: 409,51 RU
İyileştirilmiş
Güncelleştirilmiş dizin oluşturma ilkesi:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": []
}
RU ücreti: 2,98 RU
Dizin oluşturma ilkesine istediğiniz zaman yazma veya okuma kullanılabilirliği üzerinde hiçbir etkisi olmadan özellikler ekleyebilirsiniz. Dizin dönüştürme ilerleme durumunu izleyebilirsiniz.
Hangi sistem işlevlerinin dizini kullandığını anlama
Çoğu sistem işlevi dizinleri kullanır. Dizinleri kullanan bazı yaygın dize işlevlerinin listesi aşağıdadır:
- StartsWith
- Contains
- RegexMatch
- Sol
- Alt dize - ancak yalnızca ilk num_expr 0 olduğunda
Aşağıda, dizini kullanmayan ve yan WHERE tümcesinde kullanıldığında her belgeyi yüklemesi gereken bazı yaygın sistem işlevleri yer alır:
| Sistem işlevi | İyileştirme fikirleri |
|---|---|
| Üst/Alt | Karşılaştırmalar için verileri normalleştirmek için sistem işlevini kullanmak yerine, eklemeden sonra büyük/küçük harfi normalleştirin. gibi SELECT * FROM c WHERE UPPER(c.name) = 'BOB' bir sorgu olur SELECT * FROM c WHERE c.name = 'BOB'. |
| GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks | Sorgu yürütmeden önceki geçerli saati hesaplayın ve yan tümcesinde WHERE bu dize değerini kullanın. |
| Matematiksel işlevler (toplama olmayan) | Sorgunuzda bir değeri sık sık hesaplamanız gerekiyorsa, değeri JSON belgenizde bir özellik olarak depolamayı göz önünde bulundurun. |
Bu sistem işlevleri, toplamaları olan sorgularda kullanıldığı durumlar dışında dizinleri kullanabilir:
| Sistem işlevi | İyileştirme fikirleri |
|---|---|
| Uzamsal sistem işlevleri | Sorgu sonucunu gerçek zamanlı bir görünümde depolama |
yan tümcesinde SELECT kullanıldığında, verimsiz sistem işlevleri sorguların dizinleri nasıl kullanabileceğini etkilemez.
Dize sistemi işlev yürütmesini geliştirme
Dizinleri kullanan bazı sistem işlevleri için sorguya bir ORDER BY yan tümce ekleyerek sorgu yürütmeyi geliştirebilirsiniz.
Daha açık belirtmek gerekirse, özelliğin kardinalitesi arttıkça RU ücreti artan tüm sistem işlevleri sorguda olmasından ORDER BY yararlanabilir. Bu sorgular dizin taraması yapar, bu nedenle sorgu sonuçlarının sıralanmış olması sorguyu daha verimli hale getirir.
Bu iyileştirme, aşağıdaki sistem işlevleri için yürütmeyi geliştirebilir:
- StartsWith (burada büyük/küçük harfe duyarsız = true)
- StringEquals (burada büyük/küçük harfe duyarsız = true)
- Contains
- RegexMatch
- EndsWith
Örneğin, ile CONTAINSaşağıdaki sorguyu göz önünde bulundurun. CONTAINS dizinleri kullanır, ancak bazen ilgili dizini ekledikten sonra bile aşağıdaki sorguyu çalıştırırken çok yüksek RU ücreti gözlemleyebilirsiniz.
Özgün sorgu:
SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
Ekleyerek ORDER BYsorgu yürütmeyi geliştirebilirsiniz:
SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
ORDER BY c.town
Aynı iyileştirme, ek filtreler içeren sorgularda yardımcı olabilir. Bu durumda, yan tümcesine eşitlik filtrelerine ORDER BY sahip özellikleri de eklemek en iyisidir.
Özgün sorgu:
SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
(c.name, c.town) için ve bileşik dizini ekleyerek ORDER BY sorgu yürütmeyi geliştirebilirsiniz:
SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
ORDER BY c.name, c.town
Hangi toplama sorgularının dizini kullandığını anlama
Çoğu durumda Azure Cosmos DB'deki toplu sistem işlevleri dizini kullanır. Ancak, bir toplama sorgusundaki filtrelere veya ek yan tümcelere bağlı olarak, sorgu altyapısının çok sayıda belge yüklemesi gerekebilir. Genellikle sorgu altyapısı önce eşitlik ve aralık filtreleri uygular. Bu filtreleri uyguladıktan sonra sorgu altyapısı ek filtreleri değerlendirebilir ve gerekirse toplama işlemini hesaplamak için kalan belgeleri yüklemeye başvurabilir.
Örneğin, bu iki örnek sorgu göz önüne alındığında, hem eşitlik CONTAINS hem de sistem işlevi filtresi olan sorgu genellikle yalnızca CONTAINS sistem işlev filtresi olan bir sorgudan daha verimli olacaktır. Bunun nedeni, önce eşitlik filtresinin uygulanması ve daha pahalı CONTAINS filtre için belgelerin yüklenmesi gerekmeden önce dizini kullanmasıdır.
Yalnızca CONTAINS filtre içeren sorgu - daha yüksek RU ücreti:
SELECT COUNT(1)
FROM c
WHERE CONTAINS(c.description, "spinach")
Hem eşitlik filtresi CONTAINS hem de filtresi olan sorgu - daha düşük RU ücreti:
SELECT AVG(c._ts)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats" AND CONTAINS(c.description, "spinach")
Dizini tam olarak kullanmayacak toplama sorgularının ek örnekleri aşağıda verilmiştir:
Dizini kullanmayan sistem işlevlerine sahip sorgular
Dizini kullanıp kullanmadiğini görmek için ilgili sistem işlevinin sayfasına başvurmalısınız.
SELECT MAX(c._ts)
FROM c
WHERE CONTAINS(c.description, "spinach")
Kullanıcı tanımlı işlevlerle (UDF'ler) sorguları toplama
SELECT AVG(c._ts)
FROM c
WHERE udf.MyUDF("Sausages and Luncheon Meats")
GROUP BY ile sorgular
yan tümcesindeki özelliklerin GROUP BY kardinalitesi arttıkça ile GROUP BY sorguların RU ücreti artar. Örneğin aşağıdaki sorguda, benzersiz açıklama sayısı arttıkça sorgunun RU ücreti artacaktır.
Yan tümcesi olan GROUP BY bir toplama işlevinin RU ücreti, yalnızca toplama işlevinin RU ücretinden daha yüksek olacaktır. Bu örnekte sorgu altyapısının filtreyle eşleşen her belgeyi c.foodGroup = "Sausages and Luncheon Meats" yüklemesi gerekir, bu nedenle RU ücretinin yüksek olması beklenir.
SELECT COUNT(1)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats"
GROUP BY c.description
Aynı toplama sorgularını sık sık çalıştırmayı planlıyorsanız Azure Cosmos DB değişiklik akışıyla gerçek zamanlı gerçekleştirilmiş bir görünüm oluşturmak, tek tek sorguları çalıştırmaktan daha verimli olabilir.
Hem filtre hem de ORDER BY yan tümcesine sahip sorguları iyileştirme
Filtre ve ORDER BY yan tümcesi olan sorgular normalde aralık dizini kullansa da bileşik dizinden hizmet verebiliyorlarsa daha verimli olur. Dizin oluşturma ilkesini değiştirmenin yanı sıra bileşik dizindeki tüm özellikleri yan tümcesine ORDER BY eklemeniz gerekir. Sorguda yapılan bu değişiklik bileşik dizini kullandığından emin olmayı sağlar. Beslenme veri kümesinde bir sorgu çalıştırarak bu etkiyi gözlemleyebilirsiniz:
Özgün
Sorgu:
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c._ts ASC
Dizin oluşturma ilkesi:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[]
}
RU ücreti: 44,28 RU
İyileştirilmiş
Sorgu güncelleştirildi (yan tümcesinde ORDER BY her iki özelliği de içerir):
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c.foodGroup, c._ts ASC
Güncelleştirilmiş dizin oluşturma ilkesi:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[],
"compositeIndexes":[
[
{
"path":"/foodGroup",
"order":"ascending"
},
{
"path":"/_ts",
"order":"ascending"
}
]
]
}
RU ücreti: 8,86 RU
Alt sorgu kullanarak JOIN ifadelerini iyileştirme
Çok değerli alt sorgular, yan tümcedeki WHERE tüm çapraz birleşimlerden sonra değil, her select-many ifadesinden sonra koşul göndererek ifadeleri iyileştirebilirJOIN.
Şu sorguyu göz önünde bulundurun:
SELECT Count(1) AS Count
FROM c
JOIN t IN c.tags
JOIN n IN c.nutrients
JOIN s IN c.servings
WHERE t.name = 'infant formula' AND (n.nutritionValue > 0
AND n.nutritionValue < 10) AND s.amount > 1
RU ücreti: 167,62 RU
Bu sorgu için dizin, 0'dan büyük ve amount 1'den büyük adlı infant formulanutritionValue etiketi olan tüm belgelerle eşleşecek. JOIN Buradaki ifade, herhangi bir filtre uygulanmadan önce eşleşen her belge için tüm etiket öğelerinin, besin öğelerinin ve sunum dizilerinin çapraz çarpımını gerçekleştirir. Yan WHERE tümcesi her tanımlama grubuna <c, t, n, s> filtre koşulunu uygular.
Örneğin, eşleşen bir belgenin üç dizinin her birinde 10 öğe varsa, 1 x 10 x 10 x 10 (yani 1.000) tanımlama grubuna genişletilir. Burada alt sorgular kullanılması, bir sonraki ifadeyle birleştirmeden önce birleştirilmiş dizi öğelerini filtrelemeye yardımcı olabilir.
Bu sorgu, önceki sorguyla eşdeğerdir ancak alt sorgular kullanır:
SELECT Count(1) AS Count
FROM c
JOIN (SELECT VALUE t FROM t IN c.tags WHERE t.name = 'infant formula')
JOIN (SELECT VALUE n FROM n IN c.nutrients WHERE n.nutritionValue > 0 AND n.nutritionValue < 10)
JOIN (SELECT VALUE s FROM s IN c.servings WHERE s.amount > 1)
RU ücreti: 22,17 RU
Etiketler dizisindeki yalnızca bir öğenin filtreyle eşleşdiğini ve hem besin öğeleri hem de sunum dizileri için beş öğe olduğunu varsayalım. İfadeler JOIN , ilk sorgudaki 1.000 öğenin aksine 1 x 1 x 5 x 5 = 25 öğeye genişletilir.
Alınan Belge Sayısının Çıkış Belge Sayısı ile eşit olduğu sorgular
Alınan Belge Sayısı ile Çıkış Belge Sayısı hemen hemen eşit olduğunda, sorgu altyapısının birçok gereksiz belgeyi taraması gerekmez. Anahtar sözcüğünü kullananlar gibi birçok sorguda TOP, Alınan Belge SayısıÇıktı Belge Sayısı'nı 1 aşabilir. Bu konuda endişelenmeniz gerekmez.
Bölümler arası sorguları en aza indirin
Azure Cosmos DB, İstek Birimi ve veri depolama gereksinimleri arttıkça kapsayıcıları tek tek ölçeklendirmek için bölümleme kullanır. Her fiziksel bölümün ayrı ve bağımsız bir dizini vardır. Sorgunuzda kapsayıcınızın bölüm anahtarıyla eşleşen bir eşitlik filtresi varsa yalnızca ilgili bölümün dizinini denetlemeniz gerekir. Bu iyileştirme sorguya gereken toplam RU sayısını azaltır.
Çok sayıda sağlanan RU'nuz (30.000'den fazla) veya depolanan büyük miktarda veriniz (yaklaşık 100 GB'tan fazla) varsa, sorgu RU ücretlerinde önemli bir azalma görmek için büyük olasılıkla yeterince büyük bir kapsayıcınız vardır.
Örneğin, bölüm anahtarı foodGroup ile bir kapsayıcı oluşturursanız, aşağıdaki sorguların yalnızca tek bir fiziksel bölümü denetlemesi gerekir:
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"
Bölüm anahtarına sahip bir IN filtreye sahip sorgular yalnızca ilgili fiziksel bölümleri denetler ve "yayılmaz":
SELECT *
FROM c
WHERE c.foodGroup IN("Soups, Sauces, and Gravies", "Vegetables and Vegetable Products") and c.description = "Mushroom, oyster, raw"
Bölüm anahtarında aralık filtrelerine sahip olan veya bölüm anahtarında filtre olmayan sorguların "yayılarak" ve sonuçlar için her fiziksel bölümün dizinini denetlemesi gerekir:
SELECT *
FROM c
WHERE c.description = "Mushroom, oyster, raw"
SELECT *
FROM c
WHERE c.foodGroup > "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"
Birden çok özellikte filtreleri olan sorguları iyileştirme
Birden çok özellik üzerinde filtresi olan sorgular normalde bir aralık dizini kullansa da, bileşik dizinden hizmet verebiliyorlarsa daha verimli olur. Az miktarda veri için bu iyileştirmenin önemli bir etkisi olmaz. Öte yandan büyük miktardaki veri için kullanışlı olabilir. Bileşik dizin başına en fazla bir eşitlik dışı filtreyi iyileştirebilirsiniz. Sorgunuzda birden çok eşitlik dışı filtre varsa, aralarından bileşik dizini kullanacak birini seçin. Kalanlar aralık dizinlerini kullanmaya devam eder. Eşitlik dışı filtre bileşik dizinde en son tanımlanmalıdır. Bileşik dizinler hakkında daha fazla bilgi edinin.
Bileşik dizinle iyileştirilebilen bazı sorgu örnekleri aşağıda verilmiştir:
SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts = 1575503264
SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts > 1575503264
İlgili bileşik dizin şu şekildedir:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[],
"compositeIndexes":[
[
{
"path":"/foodGroup",
"order":"ascending"
},
{
"path":"/_ts",
"order":"ascending"
}
]
]
}
Sorgu gecikme süresini azaltan iyileştirmeler
Çoğu durumda, sorgu gecikmesi hala çok yüksek olduğunda RU ücreti kabul edilebilir. Aşağıdaki bölümlerde, sorgu gecikme süresini azaltmaya yönelik ipuçlarına genel bir bakış verilmiştir. Aynı sorguyu aynı veri kümesinde birden çok kez çalıştırırsanız, genellikle her seferinde aynı RU ücretine sahip olacaktır. Ancak sorgu gecikme süresi, sorgu yürütmeleri arasında farklılık gösterebilir.
Yakınlığı geliştirme
Azure Cosmos DB hesabından farklı bir bölgeden çalıştırılan sorgular aynı bölgede çalıştırıldığından daha uzun gecikme süresine sahip olur. Örneğin, masaüstü bilgisayarınızda kod çalıştırıyorsanız, gecikmenin, sorgunun Azure Cosmos DB ile aynı Azure bölgesindeki bir sanal makineden gelmesine kıyasla onlarca veya yüzlerce milisaniye daha yüksek (veya daha fazla) olmasını beklemelisiniz. Verilerinizi uygulamanıza yaklaştırabileceğinizden emin olmak için Azure Cosmos DB'de verileri genel olarak dağıtmak kolaydır.
Sağlanan aktarım hızını artırma
Azure Cosmos DB'de sağlanan aktarım hızınız İstek Birimleri (RU) cinsinden ölçülür. 5 RU aktarım hızı kullanan bir sorgunuz olduğunu varsayın. Örneğin, 1.000 RU sağlarsanız, bu sorguyu saniyede 200 kez çalıştırabilirsiniz. Kullanılabilir yeterli aktarım hızı olmadığında sorguyu çalıştırmayı denediğinizde Azure Cosmos DB bir HTTP 429 hatası döndürür. NoSQL SDK'ları için geçerli API'lerden herhangi biri, kısa bir süre bekledikten sonra bu sorguyu otomatik olarak yeniden dener. Kısıtlanmış istekler daha uzun sürer, bu nedenle sağlanan aktarım hızını artırmak sorgu gecikme süresini iyileştirebilir. Kısıtlanan isteklerin toplam sayısını Azure portal Ölçümler dikey penceresinde gözlemleyebilirsiniz.
MaxConcurrency'i artırma
Paralel sorgular, birden çok bölümü paralel olarak sorgulayarak çalışır. Ancak tek bir bölümlenmiş koleksiyondaki veriler sorguya göre seri olarak getirilir. Bu nedenle, MaxConcurrency'i bölüm sayısına ayarlarsanız, diğer tüm sistem koşullarının aynı kalması koşuluyla en yüksek performansa sahip sorguyu elde etme şansına sahip olursunuz. Bölüm sayısını bilmiyorsanız MaxConcurrency (veya eski SDK sürümlerinde MaxDegreesOfParallelism) değerini yüksek bir sayıya ayarlayabilirsiniz. Sistem, en yüksek paralellik derecesi olarak minimum (bölüm sayısı, kullanıcı tarafından sağlanan giriş) seçer.
MaxBufferedItemCount sayısını artırma
Sorgular, geçerli sonuç toplu işlemi istemci tarafından işlenirken sonuçları önceden getirmek üzere tasarlanmıştır. Önceden getirme, bir sorgunun genel gecikme süresini iyileştirmeye yardımcı olur. MaxBufferedItemCount ayarı, önceden getirilen sonuçların sayısını sınırlar. Bu değeri beklenen sonuç sayısına (veya daha yüksek bir sayıya) ayarlarsanız, sorgu ön getirmeden en iyi şekilde yararlanabilir. Bu değeri -1 olarak ayarlarsanız, sistem arabelleğe alınacak öğe sayısını otomatik olarak belirler.
Sonraki adımlar
Sorgu başına RU'ları ölçme, sorgularınızı ayarlamak için yürütme istatistikleri alma ve daha fazlası hakkında bilgi için aşağıdaki makalelere bakın: