Amazon DynamoDB migreren naar STACKIT

Een DynamoDB-tabel met een global secondary index

Uit de gepubliceerde run van de AWS Retail Store. Links: de AWS-bron precies zoals AWS die publiceert. Rechts: de resourceblokken die StackToIT schreef; de reviewopmerkingen boven elk blok in het bestand zijn hier weggelaten.

module "dynamodb_carts" {
  source  = "terraform-aws-modules/dynamodb-table/aws"
  version = "3.3.0"

  name     = "${var.environment_name}-carts"
  hash_key = "id"

  attributes = [
    {
      name = "id"
      type = "S"
    },
    {
      name = "customerId"
      type = "S"
    }
  ]

  global_secondary_indexes = [
    {
      name            = "idx_global_customerId"
      hash_key        = "customerId"
      projection_type = "ALL"
    }
  ]

  tags = var.tags
}

resource "stackit_mongodbflex_instance" "dynamodb_tables" {
  project_id = var.project_id
  name       = "dynamodb-tables"
  acl        = var.dynamodb_tables_allowed_cidrs
  version    = var.dynamodb_tables_version
  flavor = {
    cpu = var.dynamodb_tables_cpu
    ram = var.dynamodb_tables_ram
  }
  replicas = 3
  storage = {
    class = var.mongodbflex_storage_class
    size  = var.dynamodb_tables_storage_gb
  }
  backup_schedule = "0 2 * * *"
  options = {
    type                       = "Replica"
    point_in_time_window_hours = var.dynamodb_tables_pitr_hours
  }
}

• Elke tabel wordt een collectie

  De tabel carts wordt de collectie retail-store-ecs-carts op één MongoDB Flex-instance.

• Sleutels en indexen gekoppeld

  De hash key id wordt _id of een unieke index, en de global secondary index op customerId wordt een secundaire index.

• Redundantie binnen de regio behouden

  DynamoDB repliceert over zones; een replica set van drie leden houdt de redundantie binnen de STACKIT-regio in stand.

• Dimensionering en back-up als invoer

  CPU, geheugen, opslag en het point-in-time-venster zijn variabelen, en een dagelijkse back-up is als beginpunt ingesteld.

Waar uw ontwikkelaars rekening mee houden

• Datatoegangslaag

  De DynamoDB-aanroepen van de applicatie worden herschreven voor de MongoDB-API.

• Dataverplaatsing

  Exporteer vanuit DynamoDB naar S3 en importeer daarna met mongoimport. Zo staat het in het plan, omdat niets de data live repliceert.

• Functies die u vervangt

  Capacity modes, DynamoDB Streams en conditional writes worden als niet overgenomen benoemd, met wat u in plaats daarvan gebruikt, zoals change streams of een outbox.

Dataverplaatsing in vijf stappen

Uit het document voor de dataverplaatsing dat de run voor de tabel carts schreef. StackToIT verplaatst zelf geen data: elke stap is voor een persoon.

• 1 · Schrijfstop

  Eigenaar: Migration Owner. Som op wie schrijft, leg de verbindingsinstellingen van elke client vast en stop dan de schrijvers. De bron blijft onaangeroerd, dus voor de weg terug is op de bron niets nodig.

• 2 · Export

  Eigenaar: Data Architect. Exporteer de tabel binnen de schrijfstop naar S3. De export vereist point-in-time recovery en de tabel in de run vermeldt dit niet, dus u schakelt het herstel eerst in. Bewaar manifest-summary.json: de itemCount daaruit is de basis voor de eindvergelijking.

• 3 · Conversie

  Eigenaar: Data Architect. Een eigen script verwijdert de typebeschrijvingen uit de DynamoDB-JSON, zet de waarden om naar BSON en maakt van de sleutel id de _id. Getallen met meer dan 34 significante cijfers passen niet in een decimal128, dus het script bewaart ze als strings of meldt ze.

• 4 · Laatste sync

  Eigenaar: Data Architect. Laad de documenten met mongoimport of een driverscript en bouw daarna de indexen. Het concept maakt de instance leeg aan; de instance-gebruiker en de toegangslijst stelt u zelf in.

• 5 · Reconcile

  Eigenaar: Data Architect. Het aantal documenten moet gelijk zijn aan de itemCount min de items die de conversie meldde, een steekproef van sleutels moet aan beide kanten dezelfde waarden opleveren en de belangrijkste leesactie van de applicatie moet hetzelfde antwoord geven. Daarna legt de eigenaar GO of NO-GO vast.

Waarin de twee opslagsystemen verschillen

• Sets worden arrays

  Sets van strings, getallen en binaire waarden bevatten unieke waarden zonder volgorde. Een array doet dat niet, dus code die op setbewerkingen steunt, verandert.

• Consistentie van indexen

  Een global secondary index is eventually consistent. Een MongoDB-index wordt samen met de schrijfactie bijgewerkt.

• Itemgrootte

  DynamoDB-items zijn maximaal 400 KB en een BSON-document maximaal 16 MiB, dus in deze richting is geen groottecontrole nodig.

• Capaciteit en facturering

  De factureringsmodus pay-per-request en indexprojecties worden niet overgenomen. De grootte van de instance kiest u als CPU, geheugen en opslag.

• Herstelvenster

  Point-in-time recovery van DynamoDB beslaat 1 tot 35 dagen. MongoDB Flex documenteert point-in-time restore voor de laatste 30 uur, en dat is de standaardwaarde 30 van het concept.

• Back-upritme

  MongoDB Flex maakt elke 6, 8, 12 of 24 uur een back-up, met een dagelijkse bewaartermijn voor snapshots van 3 tot 360 dagen.

Vragen van ontwikkelaars

Bronnen

• AWS Docs: What is Amazon DynamoDB?
• STACKIT Docs: MongoDB Flex
• STACKIT Docs: PostgreSQL Flex
• AWS Docs: Enable point-in-time recovery in DynamoDB
• STACKIT Docs: MongoDB Flex, backup, restore and clone