Azure Cosmos DB-tároló lekérdezése
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ázatot) az Azure Cosmos DB-ben. Ez különösen azt ismerteti, hogyan működnek a particionáláson belüli és a többpartíciós lekérdezések 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 partíciókulcs-szűrő van megadva, 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, amelyen egyenlőségi szűrő van bekapcsolva DeviceId. Ha ezt a lekérdezést egy particionált tárolón DeviceIdfuttatjuk, 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 is egyetlen partícióra szűr. A szűrő Location hozzáadása nem változtatja meg a következő lekérdezést:
SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'
Az alábbi lekérdezés tartományszűrővel rendelkezik a partíciókulcson, és nem lesz hatóköre egyetlen fizikai partícióra. A partíción belüli lekérdezéshez 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ót ki kell használnia, 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 ha többpartíciós 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 az eredményeket különböző fizikai partíciókon.
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: Az egyidejű hálózati kapcsolatok maximális számát állítja be a tároló partícióihoz. Ha ezt a tulajdonságot
-1állítja be, az SDK kezeli a párhuzamosság mértékét. Ha aMaxConcurrencybeállítás0értéke, 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á. Az RU-díjak azonban jelentősen megnőnek a fizikai partíciók teljes számának növekedésével.
Partíciók közötti lekérdezés 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özi 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
Az alábbiakban egy hasonlatot talál 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 különböző lakáskomplexumokhoz. Minden apartmankomplexum rendelkezik egy listával a helyszínen, amely tartalmazza az összes lakóegység számát. Összehasonlíthatjuk az egyes lakáskomplexumokat 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ési vezető ismeri a megfelelő lakáskomplexumot (fizikai partíciót), akkor azonnal a megfelelő épülethez vezethetnek. A sofőr ellenőrizheti a lakótelep lakóegységeinek listáját (az indexet), és gyorsan kézbesítheti a megfelelő csomagokat. Ebben az esetben a sofőr nem pazarolja az időt vagy erőfeszítést 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), minden egyes apartmanházhoz kell vezetnie, és ellenőriznie kell a listát az összes lakóegység-számmal (az indexkel). Miután a sofőr megérkezik az egyes lakáskomplexumokhoz, továbbra is használhatják az egyes lakók címlistáját. Azonban ellenőrizniük kell minden apartmankomplexum listáját, 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 (vagyis nem kell minden ajtót kopogtatniuk), 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 apartmankomplexumban é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ő még mindig jelentős időt és erőfeszítést takarít meg. Ha egy lekérdezés szűrőjében szerepel a partíciókulcs a IN kulcsszóval, akkor csak a megfelelő fizikai partíció indexeit ellenőrzi az adatokhoz.
Partícióközi lekérdezések elkerülése
A legtöbb tároló esetében elkerülhetetlen néhány keresztpartíciós lekérdezés, ami rendben van! Szinte minden lekérdezési művelet támogatott a partíciókon, mind a logikai partíciókulcsok, mind a fizikai partíciók esetében. Az Azure Cosmos DB számos optimalizálást is nyújt a lekérdezési motorban és az ügyféloldali SDK-kban a lekérdezések fizikai partíciók közötti párhuzamos végrehajtásához.
A legtöbb írásvédett forgatókönyv esetében azt 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 az ajánlott partíciókulcs-kiválasztási eljárásoknak.
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. Legalább 2,5 RU-t kell fizetnie minden alkalommal, amikor ellenőrzi a fizikai partíció indexét az eredményekért, 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özi lekérdezések nem használnak jelentősen több RU-t, mint a partíción belüli lekérdezések.
A fizikai partíciók száma a kiosztott 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-os 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 az alábbi feltételeknek:
- Több mint 30 000 RU üzembe helyezését tervezi
- 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: