Share via

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ń w partycji 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 dla elementu 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 do elementu 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 pojedynczej 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 zostać rozsyłany do wszystkich partycji 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 w usłudze Azure Cosmos DB opóźnienie zapytań zwykle jest skalowane, a system dodaje partycje fizyczne. Jednak opłaty za jednostki RU znacznie rosną 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ą dostawy, który musi dostarczać pakiety do różnych kompleksów mieszkalnych. Każdy kompleks apartamentowy ma listę lokali, 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 właściwy kompleks mieszkalny (partycja fizyczna), może natychmiast przejść do właściwego budynku. Kierowca może sprawdzić listę jednostek mieszkańców (indeks) kompleksu mieszkalnego 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 (partycji fizycznej), musi jechać do każdego pojedynczego budynku mieszkalnego i sprawdzić listę ze wszystkimi numerami jednostek mieszkańców (indeksem). Po przybyciu kierowcy do każdego kompleksu mieszkalnego nadal mogą korzystać z listy adresów każdego rezydenta. Muszą jednak sprawdzić listę każdego kompleksu mieszkalnego, czy wszyscy adresaci pakietów tam mieszkają, 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ą jeździć do każdego pojedynczego. Podczas jazdy do kilku kompleksów mieszkalnych nadal wymaga więcej pracy niż zwiedzanie tylko jednego budynku, kierowca dostawy nadal oszczędza znaczący czas i wysiłek. Jeśli zapytanie ma klucz partycji w swoim filtrze za pomocą słowa kluczowego IN , sprawdza tylko odpowiednie indeksy partycji fizycznej dla danych.

Unikanie 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 między partycjami, 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ń między partycjami fizycznymi.

W przypadku większości scenariuszy z dużą liczbą operacji 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 liczbą aprowizowania jednostek RU. Każda partycja fizyczna umożliwia do 10 000 aprowizowania 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.

Jeśli obciążenie spełnia następujące kryteria, należy unikać zapytań obejmujących wiele partycji:

  • 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: