Een query uitvoeren op een Azure Cosmos DB-container

VAN TOEPASSING OP: NoSQL

In dit artikel wordt uitgelegd hoe u query's kunt uitvoeren op containers (collecties, grafieken, tabellen) in Azure Cosmos DB. In het bijzonder wordt beschreven hoe query's in partities en query's tussen partities werken in Azure Cosmos DB.

In-partitiequery

Wanneer u gegevens uit containers opvraagt en voor de query een partitiesleutelfilter is opgegeven, wordt de query automatisch geoptimaliseerd in Azure Cosmos DB. De query wordt gerouteerd naar de fysieke partities die overeenkomen met de partitiesleutelwaarden die zijn opgegeven in het filter.

Bekijk bijvoorbeeld de onderstaande query met een gelijkheidsfilter op DeviceId. Als we deze query uitvoeren op een container die is gepartitioneerd op DeviceId, wordt deze query gefilterd op één fysieke partitie.

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

Net als in het eerdere voorbeeld filtert deze query ook op één partitie. Als u het filter toevoegt aan Location , wordt de volgende query niet gewijzigd:

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

Hier volgt een query met een bereikfilter op de partitiesleutel en die niet wordt beperkt tot één fysieke partitie. Als u een partitiequery wilt zijn, moet de query een gelijkheidsfilter hebben dat de partitiesleutel bevat:

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

Partitieoverkoepelende query

De volgende query heeft geen filter op de partitiesleutel (DeviceId). Daarom moet het uitwaaieren naar alle fysieke partities waar het wordt uitgevoerd op de index van elke partitie:

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

Elke fysieke partitie heeft een eigen index. Wanneer u daarom een query voor meerdere partities uitvoert op een container, voert u in feite één query uit per fysieke partitie. Azure Cosmos DB voegt automatisch resultaten samen tussen verschillende fysieke partities.

De indexen in verschillende fysieke partities zijn onafhankelijk van elkaar. Er is geen globale index in Azure Cosmos DB.

Parallelle partitieoverkoepelende query

De Cosmos DB-SDK's 1.9.0 en hoger bieden ondersteuning voor opties voor parallelle query-uitvoering. Met parallelle partitieoverkoepelende query's kunt u query's met lage latentie uitvoeren op meerdere partities.

U kunt parallelle queryuitvoering beheren door de volgende parameters af te stemmen:

• MaxConcurrency: hiermee stelt u het maximum aantal gelijktijdige netwerkverbindingen met de partities van de container in. Als u deze eigenschap instelt op -1, beheert de SDK de mate van parallelle uitvoering. Als de MaxConcurrency is ingesteld op 0, is er één netwerkverbinding met de partities van de container.

• MaxBufferedItemCount: hiermee wordt de latentie van de query ingewisseld voor het geheugengebruik aan de clientzijde. Als deze optie wordt weggelaten of ingesteld op -1, wordt het aantal items dat in de buffer opgeslagen tijdens parallelle query-uitvoering, beheerd door de SDK.

Vanwege de mogelijkheid van Azure Cosmos DB om query's voor meerdere partities te parallelliseren, wordt querylatentie over het algemeen goed geschaald en voegt het systeem fysieke partities toe. Ru-kosten nemen echter aanzienlijk toe naarmate het totale aantal fysieke partities toeneemt.

Wanneer u een partitieoverschrijdende query uitvoert, voert u in feite een afzonderlijke query uit per afzonderlijke fysieke partitie. Hoewel query's voor meerdere partities gebruikmaken van de index, zijn ze, indien beschikbaar, nog steeds lang niet zo efficiënt als query's in partities.

Nuttig voorbeeld

Hier volgt een analogie om query's voor meerdere partities beter uit te leggen:

Stel dat u een bezorger bent die pakketten naar verschillende appartementencomplexen moet afleveren. Elk appartementencomplex heeft een lijst op het terrein met alle eenheidsnummers van de bewoners. We kunnen elk appartementencomplex vergelijken met een fysieke partitie en elke lijst met de index van de fysieke partitie.

We kunnen query's in partities en tussen partities vergelijken met behulp van dit voorbeeld:

Query in partitie (voorbeeld)

Als de bezorger het juiste appartementencomplex (fysieke partitie) kent, kan deze direct naar het juiste gebouw rijden. De chauffeur kan de lijst van de wooneenheden van de bewoners (de index) van het appartementencomplex controleren en snel de juiste pakketten afleveren. In dit geval verspilt de chauffeur geen tijd of moeite met het rijden naar een appartementencomplex om te controleren of er pakketontvangers wonen.

Query voor meerdere partities (uitwaaieren)

Als de bezorger het juiste appartementencomplex (fysieke partitie) niet kent, moet hij naar elk appartementsgebouw rijden en de lijst met alle eenheidsnummers van de bewoners (de index) controleren. Zodra de chauffeur bij elk appartementencomplex aankomt, kunnen ze nog steeds de lijst met de adressen van elke bewoner gebruiken. Ze moeten echter de lijst van elk appartementencomplex controleren, ongeacht of er pakketontvangers wonen of niet. In dit voorbeeld ziet u hoe query's voor meerdere partities werken. Hoewel ze de index kunnen gebruiken (wat betekent dat ze niet op elke deur hoeven te kloppen), moeten ze de index voor elke fysieke partitie afzonderlijk controleren.

Query voor meerdere partities (beperkt tot slechts enkele fysieke partities)

Als de bezorger weet dat alle pakketontvangers binnen een aantal appartementencomplexen wonen, hoeven ze niet naar elke appartement te rijden. Terwijl het rijden naar een paar appartementencomplexen nog steeds meer werk kost dan het bezoeken van slechts één gebouw, bespaart de bezorger nog steeds veel tijd en moeite. Als een query de partitiesleutel in het filter met het IN trefwoord heeft, worden alleen de indexen van de relevante fysieke partitie gecontroleerd op gegevens.

Query's tussen partities vermijden

Voor de meeste containers is het onvermijdelijk om een aantal query's voor meerdere partities uit te voeren. Dat is geen probleem. Bijna alle querybewerkingen worden ondersteund op meerdere partities, zowel voor logische partitiesleutels als fysieke partities. Azure Cosmos DB heeft ook veel optimalisaties in de query-engine en client-SDK's om de uitvoering van query's op fysieke partities te parallelliseren.

Voor de meeste leesintensieve scenario's raden we u aan de meest voorkomende eigenschap in uw queryfilters te selecteren. U moet er ook voor zorgen dat uw partitiesleutel voldoet aan andere aanbevolen procedures voor het selecteren van partitiesleutels.

Het vermijden van query's tussen partities is meestal alleen van belang bij grote containers. Er worden minimaal ongeveer 2,5 RU's in rekening gebracht telkens wanneer u de index van een fysieke partitie controleert op resultaten, zelfs als er geen items in de fysieke partitie overeenkomen met het filter van de query. Als u dus slechts één (of slechts enkele) fysieke partities hebt, verbruiken query's voor meerdere partities niet aanzienlijk meer RU's dan query's in partities.

Het aantal fysieke partities is gekoppeld aan de hoeveelheid ingerichte RU's. Elke fysieke partitie staat maximaal 10.000 ingerichte RU's toe en kan maximaal 50 GB aan gegevens opslaan. Met Azure Cosmos DB worden fysieke partities automatisch voor u beheerd. Het aantal fysieke partities in uw container is afhankelijk van uw ingerichte doorvoer en verbruikte opslag.

Probeer query's tussen partities te vermijden als uw workload voldoet aan de volgende criteria:

• U bent van plan om meer dan 30.000 RU's te hebben ingericht
• U wilt meer dan 100 GB aan gegevens opslaan

Volgende stappen

Zie de volgende artikelen voor meer informatie over partitionering in Azure Cosmos DB:

• Partitionering en horizontaal schalen in Azure Cosmos DB
• Een synthetische partitiesleutel maken in Azure Cosmos DB