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 query's uitvoert op gegevens uit containers en de query een partitiesleutelfilter heeft opgegeven, optimaliseert Azure Cosmos DB de query automatisch. Hiermee wordt de query 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 vorige voorbeeld filtert deze query ook op één partitie. Als u het filter toevoegt 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 deze worden uitgewaaierd naar alle fysieke partities waar deze worden 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 per fysieke partitie uit. Azure Cosmos DB voegt automatisch resultaten samen voor 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 -1instelt op, beheert de SDK de mate van parallelle uitvoering. Als de MaxConcurrency optie is ingesteld 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 tussen partities te parallelliseren, schaalt querylatentie over het algemeen op en voegt het systeem fysieke partities toe. Ru-kosten nemen echter aanzienlijk toe naarmate het totale aantal fysieke partities toeneemt.

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

Nuttig voorbeeld

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

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

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

Query in partitie (voorbeeld)

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

Query voor meerdere partities (fan-out)

Als de bezorger het juiste appartementscomplex (fysieke partitie) niet kent, moeten ze naar elk appartementsgebouw rijden en de lijst controleren met alle eenheden van de bewoners (de index). Zodra de chauffeur bij elk appartementencomplex aankomt, kunnen ze nog steeds de lijst met adressen van elke inwoner gebruiken. Ze moeten echter de lijst van alle appartementencomplexen controleren, ongeacht of er pakketontvangers aanwezig zijn of niet. In dit voorbeeld werken query's voor meerdere partities. 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 in een bepaald aantal appartementencomplexen wonen, hoeven ze niet naar elke complex te rijden. Terwijl het rijden naar een paar appartementencomplexen nog steeds meer werk vereist dan een bezoek aan 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, controleert deze alleen de indexen van de relevante fysieke partitie op gegevens.

Vermijd query's tussen partities

Voor de meeste containers is het onvermijdelijk dat u een aantal query's voor meerdere partities hebt, wat in orde is. Bijna alle querybewerkingen worden ondersteund tussen 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 in fysieke partities te parallelliseren.

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

Het vermijden van query's tussen partities is doorgaans alleen van belang bij grote containers. Er worden minimaal 2,5 RU's in rekening gebracht 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 fysieke partitie (of slechts een paar) fysieke partities hebt, verbruiken query's tussen 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 biedt maximaal 10.000 ingerichte RU's en kan maximaal 50 GB aan gegevens opslaan. Azure Cosmos DB beheert automatisch fysieke partities voor u. Het aantal fysieke partities in uw container is afhankelijk van uw ingerichte doorvoer en verbruikte opslag.

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

• U wilt meer dan 30.000 RU's inrichten
• 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