Oracle NoSQL auf STACKIT: das Datenmodell neu entwerfen

Zwei NoSQL-Tabellen, bewertet

Eine Sessions-Tabelle mit Ablauf und eine Warenkorb-Tabelle, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Eingabe, Zeilen 16 bis 38 der main.tf. Rechts das Ergebnis, ein Auszug aus assessment.json mit den Werten, wie der Lauf sie geschrieben hat. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.

resource "oci_nosql_table" "sessions" {
  compartment_id = var.compartment_id
  name           = "sessions"
  ddl_statement  = "CREATE TABLE IF NOT EXISTS sessions (session_id STRING, user_id STRING, payload JSON, expires_at TIMESTAMP(3), PRIMARY KEY (SHARD(user_id), session_id)) USING TTL 1 DAYS"

  table_limits {
    max_read_units     = 50
    max_write_units    = 50
    max_storage_in_gbs = 10
    capacity_mode      = "PROVISIONED"
  }
}

resource "oci_nosql_table" "carts" {
  compartment_id = var.compartment_id
  name           = "carts"
  ddl_statement  = "CREATE TABLE IF NOT EXISTS carts (cart_id STRING, customer_id STRING, items JSON, PRIMARY KEY (cart_id))"

  table_limits {
    max_storage_in_gbs = 25
    capacity_mode      = "ON_DEMAND"
  }
}

[
  {
    "id": "oci_nosql_table.sessions",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT MongoDB Flex"
      },
      "reason": "OCI NoSQL has its own data model and API. The tables and clients are redesigned for MongoDB Flex."
    }
  },
  {
    "id": "oci_nosql_table.carts",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT MongoDB Flex"
      },
      "reason": "OCI NoSQL has its own data model and API. The tables and clients are redesigned for MongoDB Flex."
    }
  }
]

• REDESIGN, mit Absicht

  Der Lauf hält fest, dass OCI NoSQL ein eigenes Datenmodell und eine eigene API hat und dass Tabellen und Clients für MongoDB Flex neu entworfen werden. Die Klasse ist kein Mangel: Sie sagt, dass die Arbeit im Design liegt, nicht im Kopieren.

• Konfidenz LOW

  Beide Tabellen sind LOW. Der Lauf hält die Machbarkeit als bedingt fest, mit einer Funktionslücke als Hinderniskategorie; die Antwort hängt also davon ab, was Ihre Anwendung nutzt.

• Auch die Clients ändern sich

  Eine DDL-Anweisung, eine SQL-ähnliche Abfrage und ein SDK-Aufruf sind alle Oracle-spezifisch. Das Redesign umfasst den Anwendungscode, der mit der Tabelle spricht.

Der Index, den der Lauf nicht kennt

Der sekundäre Index der Warenkorb-Tabelle ist als eigene Ressource deklariert. Der Lauf behält ihn und sagt klar, dass er ihn nicht bewertet hat. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.

resource "oci_nosql_index" "carts_by_customer" {
  table_name_or_id = oci_nosql_table.carts.id
  compartment_id   = var.compartment_id
  name             = "carts_by_customer"

  keys {
    column_name = "customer_id"
  }
}

[
  {
    "id": "oci_nosql_index.carts_by_customer",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_nosql_index is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• MANUAL_REVIEW für den Index

  Der Indextyp steht nicht im Katalog des Laufs, deshalb wird nichts davon bewertet oder entworfen. Die zugehörige Tabelle trägt eine Warnung, dass der Index verknüpft, aber nicht bewertet ist.

• Wo er im Plan steht

  Der Index liegt in Welle 2, die Tabellen in Welle 1. In der Praxis entwerfen Sie die Indizes zusammen mit den Collections, aus den Abfragen der Anwendung.

Begriff für Begriff: von OCI NoSQL zu MongoDB Flex

Die linke Spalte stützt sich auf die Oracle-Dokumentation, die mittlere auf STACKIT, soweit die Seite es belegt; die rechte nennt die Frage, die Sie im Entwurf beantworten.

Oracle nennt ACID-Transaktionen als unterstützt; die MongoDB-Flex-Seite führt Authentifizierung, rollenbasierte Zugriffskontrolle, Verschlüsselung und Auditing auf. Die konkreten Garantien, die Sie brauchen, bestätigen Sie am Dienst, bevor Sie sich darauf verlassen.

Optionen für das Ziel

Der Lauf schlägt eines vor. Das sind die Wahlmöglichkeiten, die ein Architekt abwägt; es wird kein Benchmark unterstellt.

• MongoDB Flex, der Kandidat des Laufs

  Am besten, wenn die Daten wirklich dokumentförmig sind und die Anwendung auf eine Dokument-API umziehen kann. STACKIT nennt dynamische Schemas, Aggregationen und mehrere Indextypen.

• PostgreSQL Flex mit JSONB

  Am besten, wenn Sie einen relationalen Dienst für typisierte Spalten und eine JSON-Spalte zugleich wollen und in Kauf nehmen, Abfragen auf SQL umzuschreiben. Eine Entwurfsalternative außerhalb des Laufs.

• Key Value Store (Valkey) für Sessions

  Eine Sessions-Tabelle mit eintägigem Ablauf ist im Grunde ein Cache. Wird sie nur über ihren Schlüssel abgefragt, passt ein Key-Value-Store mit ablaufenden Schlüsseln womöglich besser als eine Dokument-Collection. Ebenfalls eine Entwurfsalternative außerhalb des Laufs.

• Nach Workload aufteilen

  Die beiden Tabellen in der Demo müssen nicht im selben Dienst landen. Entscheiden Sie je Tabelle nach Zugriffsmuster und führen Sie erst zusammen, wo es Betriebsaufwand spart.

Eine Entwurfsreihenfolge, die funktioniert

Allgemeine Praxis, kein Laufergebnis. Jeder Schritt erzeugt etwas, das ein Reviewer prüfen kann.

1. 01

   Zugriffsmuster auflisten

   Halten Sie für jede Tabelle jeden Lese- und Schreibzugriff fest: über welchen Schlüssel, wie oft, wie aktuell die Daten sein müssen.

2. 02

   Ziel je Tabelle wählen

   Nutzen Sie die Optionen oben und notieren Sie die Begründung, damit die Entscheidung nicht wiederholt wird.

3. 03

   Dokumente oder Zeilen zeichnen

   Ein Beispieldatensatz je Collection, mit Schlüssel und Indizes, abgestimmt mit dem Team, dem die Anwendung gehört.

4. 04

   Datenzugriffsschicht umschreiben

   Ersetzen Sie die Oracle-SDK-Aufrufe und SQL-ähnlichen Abfragen; halten Sie die Änderung hinter einer Schnittstelle, damit sie testbar bleibt.

5. 05

   Laden und vergleichen

   Aus der Quelle exportieren, transformieren, laden und Anzahlen sowie Stichproben vergleichen. Der Lauf überträgt keine Daten und hält fest, dass Sie das Verfahren wählen.

Fragen von Anwendungsteams

Quellen

• Oracle NoSQL Database Cloud Service: Konzepte
• Oracle NoSQL Database Cloud Service: Wichtige Funktionen
• STACKIT-Dokumentation: MongoDB Flex