Dlaczego zapytania usługi Azure Cosmos mają wyższe jednostki RU podczas określania klucza partycji?
Mam pytanie podobne do tego . Zasadniczo testowałem różne sposoby korzystania z klucza partycji i zauważyłem, że w dowolnym momencie im więcej odwołań do klucza partycji w zapytaniu, tym wyższa liczba jednostek RU. Jest to dość spójne i nie ma nawet znaczenia, w jaki sposób używany jest klucz partycji. Więc zawęziłem to do podstawowych zapytań do testu.
Na początek ta baza danych zawiera około 850 tys. Dokumentów, wszystkie o rozmiarze ponad 1 KB. Klucz partycji jest w zasadzie 100 modułem identyfikatora w postaci liczbowej, jest ustawiony na / partitionKey, a kontener używa domyślnej zasady indeksowania:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
]
}
Oto mój podstawowy test zapytania:
SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.95 RUs
SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.85 RUs
Dokumentacja usługi Azure Cosmos mówi, że bez klucza partycji zapytanie zostanie „ rozłożone ” na wszystkie partycje logiczne. Dlatego w pełni spodziewałbym się, że pierwsze zapytanie będzie skierowane do jednej partycji, a drugie do wszystkich, co oznacza, że pierwsze powinno mieć mniejsze jednostki RU. Przypuszczam, że używam wyników RU jako dowodu na to, czy Cosmos rozkłada i skanuje każdą partycję i porównuje to z tym, co według dokumentacji powinno się wydarzyć.
Wiem, że te wyniki to tylko 0,1 RU różnicy. Chodzi mi jednak o to, że im bardziej złożone zapytanie, tym większa różnica. Na przykład, oto kolejne zapytanie, które jest nieco bardziej złożone:
SELECT c.id, c.partitionKey
FROM c
WHERE (c.partitionKey = 98 OR c.partitionKey = 99) AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 3.05 RUs
Zwróć uwagę, że liczba RU nadal rośnie i oddziela się od braku określenia klucza partycji. Zamiast tego spodziewałbym się, że powyższe zapytanie będzie dotyczyło tylko dwóch partycji, w porównaniu z brakiem sprawdzania klucza partycji, które rzekomo obejmuje wszystkie partycje.
Zaczynam podejrzewać, że sprawdzanie klucza partycji odbywa się po innych filtrach (lub w ramach każdego skanowania partycji). Na przykład, wracając do pierwszego zapytania, ale zmieniając id na coś, co nie istnieje:
SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs
SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs
Zwróć uwagę, że jednostki RU są dokładnie takie same, a oba (w tym ten z filtrem partycji) mają mniej jednostek RU niż wtedy, gdy istnieje dokument. Wygląda na to, że byłby to objaw wykonywania filtru partycji na wynikach, a nie ograniczania fan-out. Ale to nie jest to, co mówi dokumentacja.
Dlaczego Cosmos ma wyższe jednostki RU, gdy określono klucz partycji?
Odpowiedzi
tak jak komentarz określa, czy testujesz przez portal (lub przez kod, ale z podanym zapytaniem) stanie się droższy, ponieważ nie odpytujesz określonej partycji, ale raczej odpytujesz wszystko, a następnie wprowadzasz inny filtr, który jest droższy.
co powinieneś zrobić zamiast tego - to użyć właściwego sposobu w kodzie, aby przekazać klucz partycji. mój wynik był całkiem imponujący: 3 ru \ s z PK i 20.000 ru \ s bez PK, więc jestem całkiem pewny, że w pracy (miałem naprawdę duży zbiór danych)