AWS Solutions Architect · Oppitunti

Globaalit ja paikalliset toissijaiset indeksit

Lisäätte GSI- ja LSI-indeksejä vaihtoehtoisten kyselymallien tukemiseksi ilman taulujen monistamista.

Oppitunti 3/413 vaihetta

Globaalit ja paikalliset toissijaiset indeksit on ilmainen AWS Solutions Architect-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea tästä oppimispolusta kokonaan mitkä tahansa 3 oppituntia ilmaiseksi — sen jälkeen CoddyKit PRO avaa kaikki oppitunnit sekä käytännön harjoittelun sisäänrakennetulla koodieditorilla ja ympäri vuorokauden toimivalla tekoälytuutorilla. Oppitunti kuuluu AWS Solutions Architect-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. AWS Solutions Architect-kurssilla on yhteensä 4 oppituntia.

Miksi toissijaiset indeksit ovat olemassa

DynamoDB:n pääavain määrittää taulun ainoan tehokkaan kyselypolun. Jos kohteita on voitava hakea jonkin muun attribuutin perusteella – esimerkiksi kaikki tuotetunnukseen liittyvät tilaukset, kun taulun osioavain on CustomerId – ilman toissijaista indeksiä jouduttaisiin suorittamaan kallis Scan-operaatio.

Toissijaiset indeksit ratkaisevat tämän ongelman ylläpitämällä datasta erillistä, automaattisesti päivittyvää kopiota, joka on järjestetty eri avaimen ympärille. DynamoDB tarjoaa kaksi tyyppiä: Global Secondary Indexes (GSI) ja Local Secondary Indexes (LSI), joilla on erilaiset kompromissit.

Global Secondary Index (GSI) -perusteet

Global Secondary Index mahdollistaa kokonaan eri osioavaimen ja valinnaisen lajitteluavaimen määrittämisen kuin perustaulussa. GSI on aidosti globaali: se kattaa kaikki perustaulun osiot. GSI:stä voidaan tehdä kyselyjä kaikkien niiden attribuuttien perusteella, jotka on määritetty GSI:n osioavaimeksi.

GSI-indekseillä on oma varattu läpimenonsa, tai ne perivät On-Demand-tilan, perustaulusta riippumatta. Taulua kohden voi luoda enintään 20 GSI-indeksiä, ja GSI-indeksejä voi lisätä tai poistaa milloin tahansa myös olemassa olevasta taulusta.

# Create a table with a GSI on ProductId
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=OrderId,AttributeType=S \
    AttributeName=ProductId,AttributeType=S \
    AttributeName=OrderDate,AttributeType=S \
  --key-schema AttributeName=OrderId,KeyType=HASH \
  --global-secondary-indexes '[
    {
      "IndexName": "ProductId-OrderDate-index",
      "KeySchema": [
        {"AttributeName": "ProductId", "KeyType": "HASH"},
        {"AttributeName": "OrderDate", "KeyType": "RANGE"}
      ],
      "Projection": {"ProjectionType": "ALL"},
      "ProvisionedThroughput": {"ReadCapacityUnits": 10, "WriteCapacityUnits": 5}
    }
  ]' \
  --provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=5

Local Secondary Index (LSI) -perusteet

Local Secondary Index käyttää samaa osioavainta kuin perust aulu, mutta eri lajitteluavainta. LSI:t ovat paikallisia, koska niillä voi tehdä kyselyjä vain yhden osion sisältä, eli niiden kohteiden joukosta, joilla on sama osioavain. Siksi LSI:t sopivat ihanteellisesti tietyn asiakkaan tilausten kyselyyn eri attribuuttien mukaan lajiteltuina.

LSI:t on määritettävä taulua luotaessa, eikä niitä voi lisätä tai poistaa myöhemmin. Taulussa voi olla enintään 5 LSI-indeksiä. LSI:t jakavat perustaulun varatun kapasiteetin (erillistä läpimenoa ei ole), ja niihin sovelletaan 10 GB:n osiokohtaista tallennusrajoitusta, joka koskee perustaulun ja LSI-datan yhdistelmää.

# Create a table with an LSI (at creation time only)
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=CustomerId,AttributeType=S \
    AttributeName=OrderDate,AttributeType=S \
    AttributeName=TotalAmount,AttributeType=N \
  --key-schema \
    AttributeName=CustomerId,KeyType=HASH \
    AttributeName=OrderDate,KeyType=RANGE \
  --local-secondary-indexes '[{
    "IndexName": "TotalAmount-index",
    "KeySchema": [
      {"AttributeName": "CustomerId", "KeyType": "HASH"},
      {"AttributeName": "TotalAmount", "KeyType": "RANGE"}
    ],
    "Projection": {"ProjectionType": "ALL"}
  }]' \
  --billing-mode PAY_PER_REQUEST

GSI:n ja LSI:n keskeiset erot

Tässä on selkeyden vuoksi rinnakkainen vertailu kokeeseen valmistautumista varten:

Partition key: GSI voi poiketa perustaulun avaimesta, mutta LSI:n on vastattava perustaulun avainta
Sort key: molemmat tukevat perustaulun avaimesta poikkeavaa sort key -avainta
Luontiajankohta: GSI voidaan luoda milloin tahansa, LSI vain taulun luonnin yhteydessä
Suorituskyky: GSI:llä on oma suorituskykynsä, kun taas LSI käyttää perustaulun suorituskykyä
Johdonmukaisuus: GSI-lukemissa käytetään vain eventual consistency -johdonmukaisuutta, kun taas LSI-lukemissa voidaan käyttää strong consistency -johdonmukaisuutta
Rajoitukset: enintään 20 GSI:tä ja enintään 5 LSI:tä taulua kohden

Projektioiden tyypit

Kun luotte indeksin, valitsette, mitkä attribuutit projisoidaan (kopioidaan) siihen:

KEYS_ONLY: vain perustaulun primary key ja indeksin avain – pienin indeksi, joka edellyttää ylimääräisiä GetItem-kutsuja muita kuin avainattribuutteja varten
INCLUDE: avainattribuutit sekä erikseen nimeämänne lisäattribuutit – tasapainottaa koon ja käyttötavan
ALL: kaikki attribuutit projisoidaan indeksiin – joustavin vaihtoehto, mutta storage- ja write-kustannukset ovat suuremmat

Valitkaa projektiotyyppi sen perusteella, mitä attribuutteja kyselyt todella tarvitsevat. Liiallinen projektio tuhlaa WCUs-yksiköitä jokaisella kirjoituksella, kun taas liian vähäinen projektio pakottaa tekemään ylimääräisiä GetItem-kutsuja indeksistä puuttuvien attribuuttien hakemiseksi.

GSI:n kyselyt

GSI:n kyselyssä käytetään samaa Query-ohjelmointirajapintaa, mutta määritetään --index-name-parametri. Kysely suoritetaan GSI:n avainrakenteen eikä perustaulun avainrakenteen perusteella. GSI-kyselyissä käytetään aina eventual consistency -johdonmukaisuutta – GSI päivitetään asynkronisesti perustauluun tehtyjen kirjoitusten jälkeen, joten päivityksissä on pieni viive.

Jos perustaulun itemillä ei ole GSI:n partition key -attribuuttia, itemiä ei sisällytetä GSI:hin lainkaan (sparse index -malli). Tämä on tehokas tapa indeksoida vain osa itemeistä, kuten kaikki tilauksen, joiden status on PENDING, jos GSI:n partition key on Status.

# Query the GSI for all orders for a product in 2026
aws dynamodb query \
  --table-name Orders \
  --index-name ProductId-OrderDate-index \
  --key-condition-expression 'ProductId = :pid AND OrderDate BETWEEN :start AND :end' \
  --expression-attribute-values \
    '{":pid":{"S":"prod-abc"},":start":{"S":"2026-01-01"},":end":{"S":"2026-12-31"}}'

Sparse index -malli

Sparse index hyödyntää sitä, että DynamoDB projisoi itemin GSI:hin vain, jos itemillä on arvo GSI:n partition key -attribuutille. Kun määritätte GSI:n partition keyksi attribuutin, joka on vain joillakin itemeillä, luotte indeksin, joka sisältää vain kyseisen osajoukon.

Esimerkki: Orders-taulussa vain lähettämättömillä tilauksilla on PendingShipmentDate-attribuutti. PendingShipmentDate-attribuutin perusteella luotu GSI sisältää luonnostaan vain lähettämättömät tilaukset, joten se on erittäin tehokas tapa hakea kaikki odottavat tilaukset ilman koko taulun skannaamista.

Kirjoitusten sharding GSI:n overloading-tekniikalla

GSI overloading on edistynyt single-table design -tekniikka, jossa eri entiteettityypit tallennetaan samaan tauluun ja käytetään yleiskäyttöistä GSI-avainattribuuttia (esimerkiksi GSI1PK ja GSI1SK), jonka arvot muodostetaan eri tavoin itemin tyypin mukaan. Näin kukin entiteettityyppi saa oman tehokkaan kyselypolkunsa yhden GSI:n kautta.

Esimerkki: määrittäkää User-itemeille GSI1PK = 'COUNTRY#US' ja GSI1SK = username; määrittäkää Order-itemeille GSI1PK = 'STATUS#PENDING' ja GSI1SK = orderDate. Kun GSI:stä kysellään oikealla etuliitteellä, kohteena oleva entiteettityyppi voidaan hakea tehokkaasti.

Indeksin throttling ja kapasiteetti

GSI:n throttling tapahtuu perustaulusta riippumatta. Jos GSI:n varatut WCU-yksiköt ovat liian vähäiset, GSI:hin projisoituvien itemien kirjoituksia rajoitetaan, vaikka perustaululla olisi runsaasti kapasiteettia. Seuratkaa kunkin GSI:n ConsumedWriteCapacityUnits- ja ThrottledRequests-arvoja erikseen.

Yleinen sudenkuoppa on määrittää GSI:lle perustaulua pienempi kapasiteetti ja kohdata sitten throttling, kun kirjoitusmalli kasvattaa äkillisesti GSI:n kirjoitusnopeutta. Käyttäkää GSI:ssä Auto Scaling -ominaisuutta tai valitkaa On-Demand-tila tämän välttämiseksi.

Milloin käyttää GSI:tä, LSI:tä tai uudelleensuunnittelua

Toimintaohjeet SAA-C03-koetta varten:

Teidän on tehtävä kysely täysin eri attribuutin perusteella → GSI
Teidän on tehtävä kysely saman partitionin sisällä eri järjestyksessä ja tiedätte tämän jo luonnin yhteydessä → LSI
Tarvitsette strong consistency -lukemista vaihtoehtoisella sort key -avaimella → LSI (ainoa vaihtoehto, koska GSI:t käyttävät eventual consistency -johdonmukaisuutta)
Teillä on vähintään kymmenen erillistä kyselymallia → harkitkaa single-table design -ratkaisua GSI overloading -tekniikalla useiden erillisten taulujen sijaan
Tarvitsette vain kaikkien itemien noutamista analyysiä varten → harkitkaa uudelleen, onko DynamoDB oikea tietokanta

GSI:en poistaminen ja backfill

Voitte poistaa GSI:n milloin tahansa vaikuttamatta perustauluun. Kun lisäätte uuden GSI:n olemassa olevaan tauluun, DynamoDB täyttää indeksin taaksepäin asynkronisesti skannaamalla perustaulun – suurissa tauluissa tähän voi kulua minuuteista tunteihin. Backfillin aikana perustaulu on täysin käytettävissä sekä luku- että kirjoitusoperaatioihin.

Voitte seurata backfillin edistymistä konsolissa tai DescribeTable-ohjelmointirajapinnan kautta tarkistamalla indeksin IndexStatus-kentän. Sen arvo on backfillin aikana CREATING ja valmistumisen jälkeen ACTIVE. Älkää tehkö kyselyitä GSI:hin ennen kuin sen tila on ACTIVE.

# Check GSI status during backfill
aws dynamodb describe-table \
  --table-name Orders \
  --query 'Table.GlobalSecondaryIndexes[*].{Name:IndexName,Status:IndexStatus}'

Pikatarkistus

Testatkaa tämän oppitunnin AWS Solutions Architect (SAA-C03) -käsitteiden ymmärtämistänne.

Vastaa interaktiivisessa oppitunnissa

Oppitunnin yhteenveto

Tässä oppitunnissa opitte, että GSI:t tarjoavat vaihtoehtoiset partition key -avaimet ja ne voidaan lisätä milloin tahansa, LSI:t käyttävät samaa partition key -avainta kuin perustaulu ja ne on määritettävä taulun luonnin yhteydessä ja projektiotyypit määrittävät, mitkä attribuutit kopioidaan indeksiin. GSI:t tukevat sparse index- ja overloading-malleja, jotka mahdollistavat joustavat kyselyt edistyneissä käyttötapauksissa. Seuraavaksi tutustumme DynamoDB Streamsiin ja Global Tables -ominaisuuteen.

Aloita maksutta

Opi AWS Solutions Architect tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit: 30
Oppitunnit: 120

Aloita opiskelu maksutta Näytä koko kurssi

Usein kysytyt kysymykset

Onko oppitunti ”Globaalit ja paikalliset toissijaiset indeksit” ilmainen?

Kyllä — voit lukea täällä verkossa kokonaan ilmaiseksi mitkä tahansa AWS Solutions Architect-oppimispolun 3 oppituntia, myös oppitunnin “Globaalit ja paikalliset toissijaiset indeksit”. Sen jälkeen CoddyKit PRO avaa kaikki oppitunnit sekä interaktiiviset harjoitukset sisäänrakennetulla koodieditorilla ja ympäri vuorokauden toimivalla tekoälytuutorilla. AWS Solutions Architect-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Globaalit ja paikalliset toissijaiset indeksit”?

Lisäätte GSI- ja LSI-indeksejä vaihtoehtoisten kyselymallien tukemiseksi ilman taulujen monistamista. Harjoittelet AWS Solutions Architect-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni AWS Solutions Architect-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin AWS Solutions Architect-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.

Kuinka kauan ”Globaalit ja paikalliset toissijaiset indeksit”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä AWS Solutions Architect-oppitunnilla?

Kyllä. Jokainen AWS Solutions Architect-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

Taulut, alkiot ja pääavaimet
Varattu ja On-Demand-kapasiteetti
Globaalit ja paikalliset toissijaiset indeksit
DynamoDB Streams ja Global Tables

← Takaisin: AWS Solutions Architect