Dlaczego zapytania usługi Azure Cosmos mają wyższe jednostki RU podczas określania klucza partycji?

Jan 03 2021

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

3 4c74356b41 Jan 03 2021 at 15:39

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)