Partíciókulcs választása
Ne feledje, hogy a JSON-dokumentumokban lévő adatok olyan Tárolókon belüli Azure Cosmos DB-adatbázisokban vannak tárolva, amelyek a fizikai partíciók között vannak elosztva, és ahol az adatok a partíciókulcs értéke alapján a megfelelő fizikai partícióra lesznek irányítva.
A partíciókulcs egy szükséges dokumentumtulajdonság, amely biztosítja az azonos partíciókulcs-értékkel rendelkező dokumentumok átirányítását és tárolását egy adott fizikai partíción belül. A fizikai partíciók rögzített maximális tárterület- és átviteli sebességet (RU/s) támogatnak. Az Azure Cosmos DB automatikusan elosztja a logikai partíciókat a rendelkezésre álló fizikai partíciók között, és a partíciókulcs értékével ezt kiszámítható módon teszi meg.
Ebben a leckében többet tudhat meg a logikai partíciókról és a gyakori elérésű partíciók elkerüléséről. Ezek az információk segítenek kiválasztani a megfelelő partíciókulcsot az ügyféladatokhoz a forgatókönyvünkben.
Az Azure Cosmos DB-ben több fizikai partíció hozzáadásával növelheti a tárterületet és az átviteli sebességet az adatok eléréséhez és tárolásához. A fizikai partíció maximális tárolási mérete 50 GB, a maximális átviteli sebesség pedig 10 000 RU/s.
Logikai partíciók az Azure Cosmos DB-ben
A logikai partíció a mögöttes fizikai partíciók fölötti absztrakció. Több logikai partíció tárolható egyetlen fizikai partíción belül. A tárolók korlátlan számú logikai partícióval rendelkezhetnek. Az egyes logikai partíciók az új fizikai partíciókra kerülnek a méretük növekedésének megfelelően, így biztosítva az optimális tárolási kihasználtságot és növekedést. A logikai partíciók egységként való áthelyezése biztosítja, hogy a benne lévő összes dokumentum ugyanazon a fizikai partíción legyen. A logikai partíciók maximális mérete 20 GB. A magas számosságú partíciókulcsok használatával elkerülheti ezt a 20 GB-os korlátot azáltal, hogy nagyobb számú logikai partícióra terjeszti az adatokat. A korlát elkerülése érdekében hierarchikus partíciókulcsokat is használhat, amelyek rendszerezik a partíciókulcsok értékeit a hierarchiában. Ezeket egy másik képzési terv ismerteti.
A partíciókulcsok módot nyújtanak a logikai partíciók adatainak átirányítására. Ez egy tulajdonság, amely a tároló minden dokumentumában megtalálható, amely átirányítja az adatokat. A tároló egy másik absztrakció az azonos partíciókulccsal tárolt összes adathoz. A partíciókulcs tároló létrehozásakor van definiálva.
Az alábbi példában a tárolónak van egy partíciókulcsa /username.
Gyakori elérésű partíciók elkerülése
Amikor adatokat modellez az Azure Cosmos DB-hez, kritikus fontosságú, hogy a választott partíciókulcs egyenletes adat- és kéréselosztást eredményez a tároló fizikai partíciói között logikai és bővítményenkénti eloszlásban. Ez különösen akkor igaz, ha a tárolók nagyobbak, és egyre több fizikai partícióval rendelkeznek.
Ha nem teszteli az adatbázis tervezését a fejlesztés során, előfordulhat, hogy a partíciókulcs rossz választását nem fedi fel, amíg az alkalmazás éles környezetben nem működik, és a jelentős adatok már meg vannak írva.
Ha az adatok nincsenek megfelelően particionálva, az gyakori partíciókat eredményezhet. A gyakori elérésű partíciók megakadályozzák az alkalmazás számítási feladatainak skálázását, és mind a tárterületen, mind az átviteli sebességen előfordulhatnak.
Gyakori tárolási partíciók
A tárolóban gyakori partíció akkor fordul elő, ha olyan partíciókulcsot alkalmaz, amely magas aszimmetrikus tárolási mintákat eredményez. Példaként tekintsünk egy több-bérlős alkalmazást, amely a TenantId-et használja partíciókulcsként hat bérlővel: A–F. A B,C,E és F bérlők nagyon kicsik, a D bérlőnek egy kicsit több adata van. Az A bérlő azonban hatalmas, és gyorsan eléri a partíció 20 GB-os korlátját. Ebben a forgatókönyvben ki kell választanunk egy másik partíciókulcsot, amely elterjeszti a tárolót több logikai partíció között.
Átviteli sebesség gyakori partíciók
Az átviteli sebesség akkor szenvedhet gyakori partícióktól, ha a legtöbb vagy az összes kérés ugyanarra a logikai partícióra kerül.
Fontos tisztában lenni az alkalmazás hozzáférési mintáival, hogy a kérések a lehető leg egyenletesen oszlanak el a partíciókulcs-értékek között. Ha az átviteli sebesség ki van építve egy tárolóhoz az Azure Cosmos DB-ben, az egyenlően van lefoglalva a tároló összes fizikai partícióján.
Ha például 30 000 RU/s tárolóval rendelkezik, ez a számítási feladat a korábban említett hat bérlő három fizikai partícióján oszlik el. Így minden fizikai partíció 10 000 RU/s-t kap. Ha a D bérlő az összes 10 000 RU/s-t felhasználja, a sebesség korlátozott lesz, mert nem tudja felhasználni a többi partícióhoz lefoglalt átviteli sebességet. Ez gyenge teljesítményt eredményez a C és D bérlő esetében, és a nem használt számítási kapacitást a többi fizikai partícióban és a fennmaradó bérlőkben hagyja. Végső soron ez a partíciókulcs olyan adatbázis-kialakítást eredményez, amelyben az alkalmazás számítási feladatai nem méretezhetők.
Ha az adatok és a kérések egyenletesen oszlanak el, az adatbázis úgy nőhet, hogy teljes mértékben kihasználja a tárterületet és az átviteli sebességet is. Az eredmény a lehető legjobb teljesítmény és a legnagyobb hatékonyság lesz. Röviden: az adatbázis-tervezés méretezni fog.
Olvasások és írások megfontolása
Partíciókulcs kiválasztásakor azt is figyelembe kell vennie, hogy az adatok írási vagy olvasási nehézkesek-e. Az írási kérelmeket nagy számosságú partíciókulcsgal kell terjeszteni.
Írásvédett számítási feladatok esetén gondoskodnia kell arról, hogy a lekérdezéseket egy vagy korlátozott számú partíció WHERE dolgozza fel egy olyan záradékkal, amely egyenlőségi szűrőt tartalmaz a partíciókulcson, vagy egy IN operátort a partíciókulcs értékeinek egy részhalmazán a lekérdezésekben.
Olyan helyzetekben, ahol az alkalmazás számítási feladatai nagy írási és olvasási terhelést is igényelnek, van megoldás. Ezt a következő modulban fogjuk megvizsgálni.
Az alábbi ábrán egy felhasználónév által particionált tároló látható. Ez a lekérdezés csak egyetlen logikai partíciót fog érinteni, így a teljesítménye mindig jó lesz.
Egy olyan lekérdezés, amely egy másik tulajdonságra szűr, például favoriteColora tároló összes partíciójára "ki van kapcsolva". Ezt keresztpartíciós lekérdezésnek is nevezik. Az ilyen lekérdezés a várt módon fog teljesíteni, ha a tároló kicsi, és csak egyetlen partíciót foglal el. A tároló növekedésével és a fizikai partíciók számának növekedésével azonban ez a lekérdezés lassabbá és drágábbá válik, mivel minden partíciót ellenőriznie kell az eredmények lekéréséhez, hogy a fizikai partíció tartalmaz-e a lekérdezéshez kapcsolódó adatokat.
Partíciókulcs kiválasztása az ügyfelek számára
Most, hogy megismerte a particionálást az Azure Cosmos DB-ben, eldönthetjük az ügyféladatok partíciókulcsát. Ahogy korábban említettük, három műveletet hajtunk végre az ügyfeleken: hozzunk létre egy ügyfelet, frissítsünk egy ügyfelet, és lekérjük az ügyfelet. Ebben az esetben az ügyfelet az azonosítójuk alapján fogjuk lekérni. Mivel ez a művelet lesz a leginkább meghívva, érdemes az ügyfél azonosítóját a tároló partíciókulcsává tenni.
Előfordulhat, hogy az azonosító partíciókulcsként való megadása azt jelenti, hogy annyi logikai partíciónk lesz, mint az ügyfeleknek, és mindegyik logikai partíció csak egyetlen dokumentumot tartalmaz. Több millió ügyfél több millió logikai partíciót eredményezne.
De ez teljesen rendben van! A logikai partíciók virtuális fogalmak, és nincs korlátozva, hogy hány logikai partícióval rendelkezhet. Az Azure Cosmos DB több logikai partíciót fog összegyűjteni ugyanazon a fizikai partíción. A logikai partíciók számának vagy méretének növekedéséhez a Cosmos DB szükség esetén új fizikai partíciókra helyezi át őket.