Azure Cosmos DB-tároló lekérdezése

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Ez a cikk bemutatja, hogyan kérdezhet le egy tárolót (gyűjteményt, grafikont vagy táblát) az Azure Cosmos DB-ben. Különösen a partíción belüli és a partíciók közötti lekérdezések működését ismerteti az Azure Cosmos DB-ben.

Partíción belüli lekérdezés

Amikor adatokat kérdez le a tárolókból, ha a lekérdezéshez meg van adva egy partíciókulcs-szűrő, az Azure Cosmos DB automatikusan optimalizálja a lekérdezést. A lekérdezést a szűrőben megadott partíciókulcs-értékeknek megfelelő fizikai partíciókhoz irányítja.

Vegyük például az alábbi lekérdezést egyenlőségi szűrővel a következőn: DeviceId. Ha ezt a lekérdezést egy tárolón futtatjuk, amelyen particionált DeviceId, ez a lekérdezés egyetlen fizikai partícióra szűr.

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

A korábbi példához hasonlóan ez a lekérdezés egyetlen partícióra is szűr. A szűrő Location hozzáadása nem módosítja a következő lekérdezést:

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

Íme egy lekérdezés, amely tartományszűrővel rendelkezik a partíciókulcson, és nem lesz egyetlen fizikai partícióra korlátozva. Ahhoz, hogy partíción belüli lekérdezés legyen, a lekérdezésnek rendelkeznie kell egy egyenlőségszűrővel, amely tartalmazza a partíciókulcsot:

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

Többpartíciós kiterjedő lekérdezés

Az alábbi lekérdezés nem rendelkezik szűrővel a partíciókulcson (DeviceId). Ezért minden olyan fizikai partícióra ki kell indulnia, ahol az egyes partíciók indexén fut:

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

Minden fizikai partíciónak saját indexe van. Ezért amikor partíciók közötti lekérdezést futtat egy tárolón, fizikai partíciónként hatékonyan futtat egy lekérdezést. Az Azure Cosmos DB automatikusan összesíti a különböző fizikai partíciók eredményeit.

A különböző fizikai partíciók indexei függetlenek egymástól. Az Azure Cosmos DB-ben nincs globális index.

Párhuzamos többpartíciós lekérdezés

Az Azure Cosmos DB SDK-k 1.9.0-s és újabb verziói támogatják a párhuzamos lekérdezés-végrehajtási beállításokat. A párhuzamos többpartíciós lekérdezésekkel kis késésű többpartíciós lekérdezések hajthatók végre.

A lekérdezések párhuzamos végrehajtását az alábbi paraméterek beállításával kezelheti:

  • MaxConcurrency: Beállítja az egyidejű hálózati kapcsolatok maximális számát a tároló partícióira. Ha ezt a tulajdonságot értékre -1állítja, az SDK kezeli a párhuzamosság mértékét. Ha a MaxConcurrency értékre van állítva 0, egyetlen hálózati kapcsolat van a tároló partícióihoz.

  • MaxBufferedItemCount: kompromisszumot alakít ki a lekérdezések késése és az ügyféloldali memóriahasználat között. Ha ez a beállítás nincs megadva, vagy -1 értékre van állítva, az SDK kezeli a párhuzamos lekérdezés végrehajtása során pufferelt elemek számát.

Mivel az Azure Cosmos DB képes párhuzamosítani a partíciók közötti lekérdezéseket, a lekérdezések késése általában skálázható, és a rendszer fizikai partíciókat ad hozzá. A kérelemegység-díj azonban jelentősen nő a fizikai partíciók teljes számának növekedésével.

Partíciók közötti lekérdezések futtatásakor lényegében külön lekérdezést hajt végre az egyes fizikai partíciókon. Bár a partíciók közötti lekérdezések az indexet használják, ha vannak, még mindig nem olyan hatékonyak, mint a partíción belüli lekérdezések.

Hasznos példa

Íme egy analógia a partíciók közötti lekérdezések jobb magyarázatához:

Tegyük fel, hogy ön egy kézbesítő sofőr, akinek csomagokat kell kézbesítenie a különböző lakáskomplexumokhoz. Minden apartman komplexum rendelkezik egy listával a helyszínen, amely tartalmazza a lakók összes egységszámát. Összehasonlíthatjuk az egyes apartman-komplexumokat egy fizikai partícióval, és mindegyik listát a fizikai partíció indexével.

A partíción belüli és a partíciók közötti lekérdezéseket az alábbi példával hasonlíthatjuk össze:

Partíción belüli lekérdezés (példa)

Ha a kézbesítő ismeri a megfelelő lakáskomplexumot (fizikai partíciót), akkor azonnal a megfelelő épülethez vezethet. A sofőr ellenőrizheti a lakóegységek számát (az indexet), és gyorsan kézbesítheti a megfelelő csomagokat. Ebben az esetben a sofőr nem pazarol időt vagy energiát arra, hogy egy apartman komplexumba vezessen, hogy ellenőrizze és ellenőrizze, hogy a csomag címzettjei ott élnek-e.

Partíciók közötti lekérdezés (ki-ki)

Ha a kézbesítő nem ismeri a megfelelő lakáskomplexumot (fizikai partíciót), akkor minden egyes lakásépülethez kell vezetnie, és ellenőriznie kell a listát a lakók összes egységszámával (az indexkel). Miután a sofőr megérkezik minden lakáskomplexumba, továbbra is használhatja az egyes lakók címlistáját. Azonban ellenőrizniük kell minden apartman komplexum listáját, függetlenül attól, hogy a csomag címzettjei ott élnek-e vagy sem. Ez a példa a partíciók közötti lekérdezések működését mutatja be. Bár használhatják az indexet (ami azt jelenti, hogy nem kell minden ajtón kopogniuk), külön kell ellenőrizniük az indexet minden fizikai partíción.

Partíciók közötti lekérdezés (csak néhány fizikai partícióra terjed ki)

Ha a kézbesítési sofőr tudja, hogy az összes csomag címzettje egy bizonyos néhány apartman-komplexumban él, nem kell minden egyeshöz vezetnie. Miközben néhány apartman komplexumba vezet, még mindig több munkát igényel, mint egyetlen épület meglátogatása, a kézbesítő továbbra is jelentős időt és energiát takarít meg. Ha egy lekérdezésben a partíciókulcs a kulcsszóval együtt szerepel a IN szűrőben, akkor csak a megfelelő fizikai partíció indexeit ellenőrzi az adatokhoz.

A partíciók közötti lekérdezések elkerülése

A legtöbb tároló esetében elkerülhetetlen a partíciók közötti lekérdezések némelyike, ami rendben van! Szinte minden lekérdezési művelet támogatott a partíciók között, mind a logikai partíciókulcsok, mind a fizikai partíciók esetében. Az Azure Cosmos DB számos optimalizálást is biztosít a lekérdezési motorban és az ügyféloldali SDK-kban a lekérdezések fizikai partíciók közötti párhuzamosításához.

A legtöbb olvasási igényű forgatókönyv esetén javasoljuk, hogy válassza ki a lekérdezésszűrők leggyakoribb tulajdonságát. Azt is meg kell győződnie, hogy a partíciókulcs megfelel a partíciókulcs egyéb ajánlott eljárásainak.

A partíciók közötti lekérdezések elkerülése általában csak a nagy tárolóknál számít. A fizikai partíció indexének minden egyes ellenőrzésekor legalább 2,5 RU-t kell fizetnie, még akkor is, ha a fizikai partíció egyetlen eleme sem felel meg a lekérdezés szűrőjének. Így ha csak egy (vagy csak néhány) fizikai partícióval rendelkezik, a partíciók közötti lekérdezések nem használnak lényegesen több ru-t, mint a partíción belüli lekérdezések.

A fizikai partíciók száma a kiépített ru-k mennyiségéhez van kötve. Minden fizikai partíció legfeljebb 10 000 kiépített ru-t tesz lehetővé, és akár 50 GB adatot is tárolhat. Az Azure Cosmos DB automatikusan kezeli a fizikai partíciókat. A tárolóban lévő fizikai partíciók száma a kiosztott átviteli sebességtől és a felhasznált tárolótól függ.

Próbálja meg elkerülni a partíciók közötti lekérdezéseket, ha a számítási feladat megfelel a következő feltételeknek:

  • Azt tervezi, hogy több mint 30 000 ru van kiépítve
  • Több mint 100 GB adat tárolását tervezi

Következő lépések

Az Azure Cosmos DB particionálásával kapcsolatos további információkért tekintse meg az alábbi cikkeket: