Udostępnij za pośrednictwem

Wykonywanie zapytań względem kontenera usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

W tym artykule wyjaśniono, jak wykonywać zapytania dla kontenera (kolekcji, grafu lub tabeli) w usłudze Azure Cosmos DB. W szczególności obejmuje ona sposób działania zapytań między partycjami i między partycjami w usłudze Azure Cosmos DB.

Zapytanie wewnątrz partycji

W przypadku wykonywania zapytań dotyczących danych z kontenerów, jeśli zapytanie ma określony filtr klucza partycji, usługa Azure Cosmos DB automatycznie optymalizuje zapytanie. Kieruje zapytanie do partycji fizycznych odpowiadających wartościom klucza partycji określonym w filtrze.

Rozważmy na przykład poniższe zapytanie z filtrem równości w pliku DeviceId. Jeśli uruchomimy to zapytanie w kontenerze podzielonym na partycje w systemie DeviceId, to zapytanie filtruje do pojedynczej partycji fizycznej.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Podobnie jak w przypadku wcześniejszego przykładu, to zapytanie również filtruje do pojedynczej partycji. Dodanie filtru w poleceniu Location nie powoduje zmiany następującego zapytania:

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'

Oto zapytanie, które ma filtr zakresu klucza partycji i nie będzie mieć zakresu do jednej partycji fizycznej. Aby można było utworzyć zapytanie w partycji, zapytanie musi mieć filtr równości zawierający klucz partycji:

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Zapytanie obejmujące wiele partycji

Następujące zapytanie nie ma filtru klucza partycji (DeviceId). W związku z tym musi on być uruchamiany na wszystkich partycjach fizycznych, w których jest uruchamiany względem indeksu każdej partycji:

SELECT * FROM c WHERE c.Location = 'Seattle`

Każda partycja fizyczna ma własny indeks. W związku z tym po uruchomieniu zapytania obejmującego wiele partycji w kontenerze efektywnie uruchamiasz jedno zapytanie na partycję fizyczną. Usługa Azure Cosmos DB automatycznie agreguje wyniki w różnych partycjach fizycznych.

Indeksy w różnych partycjach fizycznych są niezależne od siebie. W usłudze Azure Cosmos DB nie ma indeksu globalnego.

Zapytanie równoległe obejmujące wiele partycji

Zestawy Azure Cosmos DB SDK w wersji 1.9.0 i nowszych obsługują opcje równoległego wykonywania zapytań. Zapytania równoległe obejmujące wiele partycji umożliwiają wykonywanie zapytań o wiele partycji z małym opóźnieniem.

Możesz zarządzać równoległym wykonywaniem zapytań przez dostrojenie następujących parametrów:

  • MaxConcurrency: ustawia maksymalną liczbę równoczesnych połączeń sieciowych z partycjami kontenera. Jeśli ustawisz tę właściwość na -1, zestaw SDK zarządza stopniem równoległości. MaxConcurrency Jeśli parametr ma wartość 0, istnieje jedno połączenie sieciowe z partycjami kontenera.

  • MaxBufferedItemCount: wyznacza kompromis między wykorzystaniem pamięci po stronie klienta i opóźnieniem zapytań. Jeśli ta opcja zostanie pominięta lub ustawiona na wartość -1, zestaw SDK będzie zarządzać liczbą elementów buforowanych podczas równoległego wykonywania zapytań.

Ze względu na możliwość równoległego przetwarzania zapytań między partycjami usługa Azure Cosmos DB zwykle skaluje opóźnienia zapytań, a system dodaje partycje fizyczne. Jednak opłata za jednostkę RU znacznie wzrasta wraz ze wzrostem całkowitej liczby partycji fizycznych.

Po uruchomieniu zapytania obejmującego wiele partycji zasadniczo wykonujesz oddzielne zapytanie na pojedynczą partycję fizyczną. Chociaż zapytania obejmujące wiele partycji używają indeksu, jeśli są dostępne, nadal nie są one tak wydajne, jak zapytania w partycjach.

Przydatny przykład

Oto analogia, aby lepiej wyjaśnić zapytania między partycjami:

Wyobraź sobie, że jesteś kierowcą dostawcy, który musi dostarczać pakiety do różnych kompleksów mieszkalnych. Każdy kompleks apartamentów ma listę na terenie, w których znajdują się wszystkie numery jednostek mieszkańców. Możemy porównać każdy kompleks apartamentów z partycją fizyczną i każdą z nich do indeksu partycji fizycznej.

Przy użyciu tego przykładu możemy porównać zapytania w partycji i między partycjami:

Zapytanie w partycji (przykład)

Jeśli kierowca dostawy zna prawidłowy kompleks apartamentowy (partycja fizyczna), może natychmiast przejść do właściwego budynku. Kierowca może sprawdzić listę jednostek mieszkańców (indeks) i szybko dostarczyć odpowiednie pakiety. W takim przypadku kierowca nie traci czasu ani wysiłku, aby sprawdzić i sprawdzić, czy istnieją tam odbiorcy pakietów.

Zapytanie obejmujące wiele partycji (fan-out)

Jeśli kierowca dostawy nie zna prawidłowego kompleksu mieszkalnego (partycja fizyczna), musi jechać do każdego budynku mieszkalnego i sprawdzić listę ze wszystkimi numerami jednostek mieszkańców (indeksem). Gdy kierowca przybywa do każdego kompleksu mieszkalnego, nadal jest w stanie użyć listy adresów każdego rezydenta. Muszą jednak sprawdzić listę każdego kompleksu mieszkalnego, czy każdy odbiorca pakietu tam mieszka, czy nie. W tym przykładzie działają zapytania obejmujące wiele partycji. Chociaż mogą używać indeksu (co oznacza, że nie muszą zapukać do wszystkich drzwi), muszą oddzielnie sprawdzić indeks dla każdej partycji fizycznej.

Zapytanie obejmujące wiele partycji (z zakresem tylko kilku partycji fizycznych)

Jeśli kierowca dostawy wie, że wszyscy odbiorcy pakietów mieszkają w kilku kompleksach mieszkalnych, nie muszą jechać do każdego z nich. Podczas jazdy do kilku kompleksów mieszkalnych nadal wymaga więcej pracy niż zwiedzanie tylko jednego budynku, kierowca dostawy nadal oszczędza dużo czasu i wysiłku. Jeśli zapytanie ma klucz partycji w swoim filtrze za pomocą słowa kluczowego IN , sprawdza tylko odpowiednie indeksy partycji fizycznej dla danych.

Unikaj zapytań obejmujących wiele partycji

W przypadku większości kontenerów nieuniknione jest posiadanie niektórych zapytań obejmujących wiele partycji, co jest w porządku! Prawie wszystkie operacje zapytań są obsługiwane w różnych partycjach, zarówno dla kluczy partycji logicznych, jak i partycji fizycznych. Usługa Azure Cosmos DB ma również wiele optymalizacji w a aparatze zapytań i zestawach SDK klienta w celu równoległego wykonywania zapytań w partycjach fizycznych.

W przypadku większości scenariuszy z dużym obciążeniem do odczytu zalecamy wybranie najbardziej typowej właściwości w filtrach zapytań. Należy również upewnić się, że klucz partycji jest zgodny z innymi najlepszymi rozwiązaniami dotyczącymi wyboru klucza partycji.

Unikanie zapytań obejmujących wiele partycji zwykle ma znaczenie tylko w przypadku dużych kontenerów. Opłaty są naliczane co najmniej około 2,5 RU za każdym razem, gdy sprawdzasz indeks partycji fizycznej pod kątem wyników, nawet jeśli żadne elementy w partycji fizycznej nie pasują do filtru zapytania. W związku z tym, jeśli masz tylko jedną (lub tylko kilka) partycji fizycznych, zapytania obejmujące wiele partycji nie zużywają znacznie więcej jednostek RU niż zapytania w partycjach.

Liczba partycji fizycznych jest powiązana z ilością aprowizowanych jednostek RU. Każda partycja fizyczna umożliwia do 10 000 aprowizowanych jednostek RU i może przechowywać do 50 GB danych. Usługa Azure Cosmos DB automatycznie zarządza partycjami fizycznymi. Liczba partycji fizycznych w kontenerze zależy od aprowizowanej przepływności i używanego magazynu.

Należy spróbować uniknąć zapytań obejmujących wiele partycji, jeśli obciążenie spełnia następujące kryteria:

  • Planujesz aprowizować ponad 30 000 jednostek RU
  • Planujesz przechowywać ponad 100 GB danych

Następne kroki

Zobacz następujące artykuły, aby dowiedzieć się więcej na temat partycjonowania w usłudze Azure Cosmos DB: