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 dahil ettik. 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 aşağıda gösterildiği gibi geniş bir kategoriye 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ğlanmaktadı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 sorgunuzun sorgu ölçümlerini almaktır. Bu ölçümler Azure portalı üzerinden de 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ı Belgesi Sayısı, sorgunun sonuçları için gereken belge sayısıdır. Alınan Belge Sayısı Çıktı Belge Sayısı'danönemli ölçüde yüksekse, sorgunuzun dizin kullanamayan ve tarama yapması gereken en az bir bölümü vardı.
Senaryonuza yönelik ilgili sorgu iyileştirmelerini anlamak için aşağıdaki bölümlere bakın.
Sorguya ait 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
Sorguya ait RU ücreti kabul edilebilir ancak gecikme süresi yine de ç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ı Belgesi Sayısı, sorgu tarafından döndürülen belge sayısıdır. Alınan Belge Sayısı Çıktı Belge Sayısı'danönemli ölçüde yüksekse, 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ı'na (7) göre önemli ölçüde yüksektir ve bu da bu sorgunun belge taramasıyla sonuçlandığını gösterir. Bu durumda, UPPER() sistem işlevi dizin kullanmaz.
Dizin oluşturma ilkesine gerekli yolları ekleme
Dizin oluşturma ilkeniz yan tümcelere, ORDER BY
yan tümcelere JOIN
ve çoğu sistem işlevine WHERE
dahil olan ö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ğini etkilemeden ö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
- Left
- 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 harf sayısını 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ı gerçekleştirilmiş 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
Dizin 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, özellik 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 duyarlı değil = true)
- Contains
- RegexMatch
- EndsWith
Örneğin, ile CONTAINS
aş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 olduğunu görebilirsiniz.
Özgün sorgu:
SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
Ekleyerek ORDER BY
sorgu 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 da yardımcı olabilir. Bu durumda, yan tümcesine eşitlik filtrelerine ORDER BY
sahip özellikler 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 bileşik dizin 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ünde bulundurulduğunda, hem eşitlik hem CONTAINS
de sistem işlevi filtresine sahip sorgu genellikle yalnızca CONTAINS
sistem işlev filtresine sahip 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 bir toplama işlevinin RU ücretinden daha yüksek olacaktır. Bu örnekte sorgu altyapısının filtreyle c.foodGroup = "Sausages and Luncheon Meats"
eşleşen tüm belgeleri 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 kullanır, ancak bileşik dizinden sunulabiliyorsa 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ümesi üzerinde 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 etikete infant formula
nutritionValue
sahip tüm belgelerle eşleşecektir. Buradaki JOIN
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 belgede üç dizinin her birinde 10 öğe varsa, 1 x 10 x 10 x 10 (yani 1.000) tanımlama gruplarına genişletilir. Burada alt sorgular kullanılması, sonraki ifadeyle birleştirmeden önce birleştirilmiş dizi öğelerini filtrelemeye yardımcı olabilir.
Bu sorgu, önceki sorguya 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 öğe yerine 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 sorgudaTOP
, 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 indirme
Azure Cosmos DB, İstek Birimi ve veri depolama gereksinimleri arttıkça ayrı kapsayıcıları ö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, foodGroup bölüm anahtarıyla 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 filtreleri olan veya bölüm anahtarında herhangi bir filtre olmayan sorguların "yayma" 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 filtre içeren sorgular normalde bir aralık dizini kullansa da, bileşik dizinden sunulabiliyorsa 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 aşağıdadır:
{
"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 yüksek 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ırabilmeniz 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ı denediyseniz 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. Azaltılan isteklerin toplam sayısını Azure portalının Ölçümler dikey penceresinde görebilirsiniz.
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 en düşük (bölüm sayısı, kullanıcı tarafından sağlanan giriş) seçer.
MaxBufferedItemCount sayısını artırın
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, döndürülen 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:
Geri Bildirim
https://aka.ms/ContentUserFeedback.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz.Gönderin ve geri bildirimi görüntüleyin