Cloud & IT Cert Prep · Lekcja

Globalne i lokalne indeksy pomocnicze

Dodadzą GSI i LSI, aby obsłużyć alternatywne schematy zapytań bez duplikowania tabel.

Globalne i lokalne indeksy pomocnicze to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Dlaczego istnieją indeksy dodatkowe

Klucz główny DynamoDB definiuje jedyną wydajną ścieżkę wykonywania zapytań w tabeli. Jeśli potrzebują Państwo wyszukiwać elementy według innego atrybutu — na przykład znaleźć wszystkie zamówienia dla identyfikatora produktu, gdy kluczem partycji tabeli jest CustomerId — bez indeksu dodatkowego konieczne byłoby wykonanie kosztownej operacji Scan.

Indeksy dodatkowe rozwiązują ten problem, utrzymując oddzielną, automatycznie aktualizowaną kopię danych uporządkowaną według innego klucza. DynamoDB oferuje dwa typy: Global Secondary Indexes (GSI) i Local Secondary Indexes (LSI), które wiążą się z różnymi kompromisami.

Podstawy Global Secondary Index (GSI)

Global Secondary Index umożliwia zdefiniowanie zupełnie innego klucza partycji (i opcjonalnie klucza sortowania) niż w tabeli bazowej. GSI jest rzeczywiście globalny — obejmuje wszystkie partycje tabeli bazowej. Za pomocą GSI można wyszukiwać elementy według dowolnego atrybutu zdefiniowanego jako klucz partycji GSI.

Indeksy GSI mają własną przepustowość provisioned (albo dziedziczą tryb on-demand), niezależną od tabeli bazowej. W jednej tabeli można utworzyć do 20 indeksów GSI, a indeksy GSI można dodawać lub usuwać w dowolnym momencie w istniejącej tabeli.

# 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

Podstawy Local Secondary Index (LSI)

Local Secondary Index używa tego samego klucza partycji co tabela bazowa, ale innego klucza sortowania. Indeksy LSI są „lokalne”, ponieważ umożliwiają wykonywanie zapytań tylko w obrębie jednej partycji (elementów z tym samym kluczem partycji). Dzięki temu indeksy LSI idealnie nadają się do wyszukiwania zamówień konkretnego klienta i sortowania ich według różnych atrybutów.

Indeksy LSI należy zdefiniować podczas tworzenia tabeli — później nie można ich dodawać ani usuwać. Każda tabela może mieć maksymalnie 5 indeksów LSI. Indeksy LSI współdzielą przepustowość provisioned tabeli bazowej (bez oddzielnej przepustowości) i podlegają limitowi 10 GB na klucz partycji dla łącznego rozmiaru danych tabeli bazowej i indeksu LSI.

# 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 a LSI: najważniejsze różnice

Oto zestawienie obok siebie ułatwiające przygotowanie do egzaminu:

Klucz partycji: w GSI może różnić się od klucza tabeli bazowej; w LSI musi być taki sam jak w tabeli bazowej
Klucz sortowania: oba indeksy obsługują klucz sortowania inny niż w tabeli bazowej
Kiedy są tworzone: GSI w dowolnym momencie; LSI tylko podczas tworzenia tabeli
Przepustowość: GSI ma własną; LSI współdzieli przepustowość tabeli bazowej
Spójność: odczyty z GSI są wyłącznie eventually consistent; odczyty z LSI mogą być strongly consistent
Limity: maksymalnie 20 GSI; maksymalnie 5 LSI na tabelę

Typy projekcji

Podczas tworzenia indeksu należy wybrać, które atrybuty są projektowane (kopiowane) do indeksu:

KEYS_ONLY: tylko klucz główny tabeli bazowej i klucz indeksu — najmniejszy indeks, wymagający dodatkowych wywołań GetItem dla atrybutów niebędących kluczami
INCLUDE: atrybuty kluczy oraz określona lista dodatkowych atrybutów — kompromis między rozmiarem a sposobem dostępu
ALL: wszystkie atrybuty są projektowane do indeksu — największa elastyczność, ale wyższy koszt przechowywania i zapisu

Typ projekcji należy wybrać na podstawie atrybutów rzeczywiście potrzebnych zapytaniom. Nadmiarowa projekcja marnuje WCU przy każdym zapisie, a zbyt ograniczona projekcja wymusza dodatkowe wywołania GetItem w celu pobrania atrybutów, których nie ma w indeksie.

Wykonywanie zapytań w GSI

Wykonywanie zapytania w GSI odbywa się za pomocą tego samego interfejsu API Query, ale wymaga podania parametru --index-name. Zapytanie jest wykonywane względem schematu kluczy GSI, a nie tabeli bazowej. Zapytania w GSI są zawsze eventually consistent — GSI jest aktualizowany asynchronicznie po zapisach w tabeli bazowej, dlatego występuje krótkie opóźnienie.

Jeśli element w tabeli bazowej nie ma atrybutu klucza partycji GSI, w ogóle nie jest uwzględniany w GSI (wzorzec indeksu rzadkiego). To skuteczna technika indeksowania tylko podzbioru elementów, na przykład wszystkich zamówień ze statusem PENDING, jeśli kluczem partycji GSI jest 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"}}'

Wzorzec indeksu rzadkiego

Indeks rzadki wykorzystuje fakt, że DynamoDB umieszcza elementy w GSI tylko wtedy, gdy mają one wartość dla klucza partycji GSI. Zdefiniowanie klucza partycji GSI na atrybucie występującym tylko w części elementów pozwala utworzyć indeks obejmujący wyłącznie ten podzbiór.

Przykład: w tabeli Orders tylko niewysłane zamówienia mają atrybut PendingShipmentDate. GSI oparty na PendingShipmentDate będzie więc naturalnie zawierał tylko niewysłane zamówienia, zapewniając bardzo wydajny sposób wyszukiwania wszystkich oczekujących zamówień bez skanowania całej tabeli.

Fragmentowanie zapisów z przeciążeniem GSI

Przeciążenie GSI to zaawansowana technika projektowania pojedynczej tabeli, w której przechowuje się różne typy encji w jednej tabeli i używa ogólnego atrybutu klucza GSI (np. GSI1PK i GSI1SK), wypełnianego różnymi wzorcami zależnie od typu elementu. Dzięki temu każdy typ encji ma własną wydajną ścieżkę zapytań za pośrednictwem jednego GSI.

Przykład: dla elementów User ustawiamy GSI1PK = 'COUNTRY#US' i GSI1SK = username; dla elementów Order ustawiamy GSI1PK = 'STATUS#PENDING' i GSI1SK = orderDate. Wykonanie zapytania w GSI z odpowiednim prefiksem pozwala wydajnie pobrać elementy docelowego typu.

Ograniczanie przepustowości indeksu i pojemność

Ograniczanie przepustowości GSI występuje niezależnie od tabeli bazowej. Jeśli przydzielona liczba WCU dla GSI jest zbyt mała, zapisy elementów projektowanych do GSI będą ograniczane — nawet jeśli tabela bazowa ma dużo wolnej pojemności. Należy osobno monitorować wartości ConsumedWriteCapacityUnits i ThrottledRequests dla każdego GSI.

Częstym błędem jest przydzielenie GSI mniejszej pojemności niż tabeli bazowej, a następnie wystąpienie ograniczeń, gdy wzorzec zapisów nagle zwiększy częstotliwość zapisów w GSI. Aby tego uniknąć, należy użyć Auto Scaling dla GSI albo wybrać tryb On-Demand.

Kiedy użyć GSI, LSI lub przeprojektować rozwiązanie

Wskazówki decyzyjne dotyczące egzaminu SAA-C03:

Potrzebują Państwo wykonywać zapytania według zupełnie innego atrybutu → GSI
Potrzebują Państwo wykonywać zapytania w obrębie tej samej partycji, ale z innym sortowaniem, i wiedzą o tym podczas tworzenia tabeli → LSI
Potrzebują Państwo strongly consistent odczytów z alternatywnego klucza sortowania → LSI (jedyna opcja, ponieważ GSI zapewnia wyłącznie eventual consistency)
Mają Państwo dziesięć lub więcej różnych wzorców zapytań → należy rozważyć projektowanie pojedynczej tabeli z przeciążeniem GSI zamiast wielu osobnych tabel
Potrzebują Państwo tylko pobierać wszystkie elementy do analizy → warto ponownie rozważyć, czy DynamoDB jest odpowiednią bazą danych

Usuwanie i uzupełnianie danych w GSI

GSI można usunąć w dowolnym momencie bez wpływu na tabelę bazową. Po dodaniu nowego GSI do istniejącej tabeli DynamoDB asynchronicznie uzupełnia indeks, skanując tabelę bazową — w przypadku dużych tabel może to potrwać od kilku minut do kilku godzin. Podczas uzupełniania tabela bazowa pozostaje w pełni dostępna do odczytu i zapisu.

Postęp uzupełniania można monitorować w konsoli lub za pośrednictwem interfejsu API DescribeTable, sprawdzając pole IndexStatus indeksu — podczas uzupełniania będzie miało wartość CREATING, a po zakończeniu ACTIVE. Nie należy wykonywać zapytań w GSI, dopóki jego status nie zmieni się na ACTIVE.

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

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji dowiedzieli się Państwo, że: GSI zapewniają alternatywne klucze partycji i można je dodawać w dowolnym momencie, LSI współdzielą klucz partycji tabeli bazowej i muszą być zdefiniowane podczas jej tworzenia, a typy projekcji określają, które atrybuty są kopiowane do indeksu. GSI obsługują wzorce indeksów rzadkich i przeciążenia, zapewniając zaawansowaną elastyczność zapytań. Następnie omówimy DynamoDB Streams i Global Tables.

Często zadawane pytania

Czy lekcja „Globalne i lokalne indeksy pomocnicze” jest bezpłatna?

Tak — pełny tekst „Globalne i lokalne indeksy pomocnicze” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Globalne i lokalne indeksy pomocnicze”?

Dodadzą GSI i LSI, aby obsłużyć alternatywne schematy zapytań bez duplikowania tabel. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?

Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Globalne i lokalne indeksy pomocnicze”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?

Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Cloud & IT Cert Prep