Ez a cikk a DynamoDB-ben történő, adatmodellezésről szóló cikksorozat első része - lesz még folytatás.

A DynamoDB az AWS teljesen menedzselt, gombnyomásra, vagy akár automatikusan skálázódó noSQL-megvalósítása. Teljesen menedzselt alatt azt értjük, hogy nem készítünk alá gépet, nem "telepítjük" sehova a DynamoDB-t, egyszerűen csak használnunk kell. Elérjük a webes felületén, és természetesen az API-ján keresztül is - ha olyan alkalmazást fejlesztünk, ami a DynamoDB-re támaszkodik, akkor alighanem ez érdekel bennünket jobban.

A DynamoDB-ben az elsődleges kulcstól (Primary Key) többminden függ, de elsősorban

• az, hogy mennyire könnyen férünk hozzá az adatainkhoz, ugyanis kevés költséggel csak az elsődleges kulcsra tudunk szűrni (itt nincs olyan flexibilis eszközünk, mint az SQL-megvalósítások WHERE záradéka, a kulcs helyes megválasztása nagyon fontos a "lekérdezések" szempontjából is),
• és hogy győzni fogja-e kiszolgálni a kéréseket a DynamoDB (ez utóbbival akkor kell törődnünk, ha másodpercenként legalább 3000 körüli olvasásra, vagy 1000 körüli írásra számítunk),

érdemes tehát jól megértenünk.

A DynamoDB-ben egy tárolt objektumot "dolognak", azaz itemnek nevezünk. Minden dologról tulajdonságokat (attribútumokat) tárolunk. Ahogy a noSQL-adatbázisokban szokás, nem kell ugyanazokat az attribútumokat tárolnunk egy-egy objektumról, azaz egy táblában, ahol mondjuk felhasználókat tárolunk, lehet, hogy valakinek csak az e-mail-címét tároljuk, valaki másnak meg mondjuk a felhasználónevét és a jelszavát. És, mint minden jól nevelt adatbázisban, a DynamoDB-ben is van elsődleges kulcs. Az elsődleges kulcs lehet egyszerű - ilyenkor csak egy attribútum alkotja - vagy összetett, amikor a kulcsot alkotó attribútumok száma pont kettő. Az elsődleges kulcsnak egyedinek kell lennie, és hogy melyik jellemző a tagja, azt táblaszinten határozzuk meg. Az elsődleges kulcsot alkotó jellemzőknek minden itemben jelen kell lenniük. Így például egy felhasználókat tároló tábla tartalma lehet:

{
  username: "jozsi",
  tel: "12-345",
  password: "titok"
}
{
  username: "johanna",
  password: "nemarulomel",
  email: "johanna@nincsilyen.hu"
}

Ebben a táblában lehet elsődleges kulcs a username jellemző.

Nézzünk egy másik táblát, ahol mondjuk rendeléseket tárolunk egy webshopban:

{
  client: "jozsi",
  ordertime: "20200706080245",
  status: "open"
}
{
  client: "jozsi",
  ordertime: "20200706080244",
  status: "closed"
}
{
  client: "johanna",
  ordertime: "20200706080245",
  status: "closed"
}

Ebben a táblában nyilván nem lehet a client jellemző az elsődleges kulcs, de ha feltételezzük, hogy egy felhasználó egy másodpercben legfeljebb egy rendelést ad le, akkor az ordertime jellemzővel együtt már betölthetik az elsődleges kulcs szerepét.

Mielőtt továbblépnénk, értsük meg a partíció (partition) fogalmát. Ahhoz viszont, hogy ezt igazán értsük, mindig szem előtt kell tartanunk, hogy a DynamDB-ben minden a sebességről szól. Nos, partíció lényegében egy lefoglalt hely a táblánknak, ami az adott AWS-régió (ahol a táblát létrehoztuk) több AZ-jében (adatközpontjában) automatikusan replikálódik. Alaphelyzetben egyetlen partíciónk van, amiből két esetben lesz több:

• ha olyan sok írás-olvasás történik, hogy egyetlen partíció esetén a diszk alrendszer lenne a korlátozó tényező
• ha olyan sok adatot tárolunk, hogy kinőjük a partíciót

Az új partíciók üzembe állításával - lévén a szolgáltatás teljesen menedzselt - egyáltalán nincs dolgunk.

Amikor az elsődleges kulcs egyetlen jellemzőből áll, akkor az elsődleges kulcs egyben partíciókulcs (Partition Key) is. A DynamoDB-ben a Partition Key a paramétere annak a hasítófüggvénynek (hash function), ami alapján a DynamoDB villámgyorsan odatalál a megfelelő partícióra, azon belül pedig megtalálja a megfelelő itemet. Fogalmazhatunk tehát úgy is, hogy végső soron a Partition Key dönti el, hogy egy adat melyik partícióra kerüljön. Ha a Partition Key megfelelően random eloszlású, akkor az adatlekérések is véletlenszerűen terhelik az egyes partíciókat, ami manapság azért érdekes, mert 3000 kérés fölé semmiképp nem mehet az egy partíció által kiszolgált olvasások száma másodpercenként. Ez elég nagy érték, első projektjeinkben talán nem is zavar majd bennünket. Az egyszerű elsődleges kulcs megválasztásánál azoban erősen szem előtt kell tartanunk, hogy - mint már említettük - nincs a relációs adatbázisoknál megszokott WHERE-záradékhoz hasonló eszközünk, lényegében csak az elsődleges kulcs használatával tudjuk kevés költséggel - műveleti és valós, értsd: dollárban számítottt költséggel - szűrni az elemeket.

Amikor összetett elsődleges kulcsunk van, akkor két jellemző együttesen alkotja az elsődleges kulcsot. Az első a már ismert Partition Key, ami ebben az esetben már lehet több itemnél is ugyanaz, feltéve, hogy az elsődleges kulcsot alkotó második jellemző még különbözik. Ez a második jellemző az úgynevezett Sort Key (rendezési kulcs), amit, hogy az egyszeri fejlesztő öröme teljes legyen, néha Range Key-nek is neveznek. Ha van Sort Key-ünk, akkor könnyen van lehetőségünk elkérni a DynamoDB-től azokat a tárolt itemeket, ahol

• azonos a Partition Key
• és valamilyen szűrést végzünk a Sort Key-en

A fenti rendeléses táblánál maradva ha a client jellemző a Partition Key, akkor ennek azonossága miatt "jozsi" rendelései biztosan egy partícióra kerülnek. Amennyiben az ordertime jellemző a Sort Key, lehetőségünk nyílik például "jozsi" 2020. júliusi rendeléseit elkérni a DynamoDB-től. Fordítva mindez nem megy - legalábbis alaphelyzetben -, azaz csak nagyon költségesen lehet megtudni, hogy melyek azok a 2020 júliusában kapott rendelések, amiket "jozsi" küldött be. (erre a problémára későbbi cikkeinkben majd visszatérünk).

Első közelítésben a tanulság tehát a következő:

• ha a kereséseink mindig ismert és egyedi kulcsra történnek, akkor nem kell Sort Key - elég a Partition Key
• ha a kulcsnak kiszemelt jellemző nem egyedi vagy szeretnénk egy másik jellemző alapján intervallumszerű lekérdezéseket írni, akkor összetett kulcsra van szükségünk.