Einheit 4.1: Integration von Datenbank und Caching

Einführung

Sie entwickeln die TaskBoard API und die Datenschicht muss auf verwalteten Datenbanken von IONOS CLOUD laufen. Das ändert einige Annahmen, die Sie möglicherweise aus anderen Cloud-Umgebungen mitbringen. Verwaltete Datenbanken werden hier über ein privates LAN erreicht, nicht über einen öffentlichen Endpunkt. Jede Client-Verbindung ist TLS-verschlüsselt, und die relationalen Datenbankcluster bieten keine Lese-Replikate, auf die Sie Leseverkehr umleiten können (nur MongoDB Enterprise kann lesbare Sekundärknoten hinzufügen). Ihr Hebel für das Skalieren von Lesezugriffen ist kein Replikat-Endpunkt, sondern der In-Memory DB-Cache.

Diese Einheit behandelt Verbindungscodes. Sie verbinden psycopg2 und SQLAlchemy mit PostgreSQL, mysql-connector mit MariaDB, pymongo mit MongoDB und redis-py mit dem In-Memory DB-Cluster, alles mit TLS und Pooling. Sie behandeln auch die zwei betrieblichen Realitäten, die Entwickler häufig treffen: Die Verbindungsgrenzen sind durch den RAM des Clusters festgelegt und können nicht durch ein Client-Flag erhöht werden. Außerdem sichert der Backup Service verwaltete Datenbanken nicht ab, sodass die Wiederherstellung über das eigene PITR der Datenbank und Ihre eigenen logischen Backups erfolgt.

1. Verbindung zu Managed PostgreSQL

PostgreSQL-Cluster lauschen auf dem Port 5432 und befinden sich in einem privaten LAN innerhalb Ihres Rechenzentrums. Das Cluster-Objekt enthält eine datacenterId, eine lanId und eine primaryInstanceAddress. Ihre Anwendung verbindet sich mit dieser Primärinstanz-Adresse. Es gibt keinen öffentlichen Hostnamen. Der Standard-SSL-Modus ist prefer und TLS kann vom Client nicht deaktiviert werden. Planen Sie daher verschlüsselte Verbindungen ab der ersten Zeile des Codes ein.

Die unterstützten Hauptversionen sind 14, 15 und 16. Die Serverzertifikatskette verweist auf die ISRG Root X1-Stammberechtigung. Ein aktueller CA-Bundle auf Ihrem Anwendungshost validiert die Verbindung ohne zusätzliche Einrichtung.

1.1 Verbindung mit psycopg2

Verbinden Sie sich mit sslmode=require, damit der Treiber bei fehlgeschlagener TLS-Verhandlung fehlerhaft schließt. Der Host ist die Primärinstanz-Adresse des Clusters, die über Ihr privates LAN erreichbar ist.

import psycopg2

conn = psycopg2.connect(
    host="10.7.222.10",        # primaryInstanceAddress from the cluster object
    port=5432,
    dbname="taskboard",
    user="taskboard_app",
    password="<from-secret-store>",
    sslmode="require",
    connect_timeout=10,
)
conn.autocommit = False

with conn.cursor() as cur:
    cur.execute(
        "INSERT INTO tasks (title, status) VALUES (%s, %s) RETURNING id",
        ("Ship unit 4.1", "open"),
    )
    task_id = cur.fetchone()[0]
    conn.commit()
print(f"Inserted task {task_id}")

Für asyncpg in einem asynchronen Dienst übergeben Sie ssl="require" und verwenden Sie denselben Host, dasselbe Port und dieselben Zugangsdaten. Erstellen Sie niemals SQL-Zeichenketten mit f-Strings; verwenden Sie stattdessen Parameterplatzhalter, wie oben gezeigt.

1.2 Verbindungsbeschränkungen sind durch RAM festgelegt

Der Wert von max_connections wird aus dem Cluster-RAM berechnet und ist nicht durch den Benutzer konfigurierbar. Die folgende Tabelle zeigt die genaue Zuordnung, die von der Plattform erzwungen wird.

Davon sind 11 Verbindungen reserviert, daher muss Ihr Anwendungspool unter der veröffentlichten Zahl minus den reservierten Slots bleiben. Da diese Obergrenze festgelegt ist, können Sie das Problem „zu viele Verbindungen“ nicht durch Anpassen einer Servereinstellung lösen. Sie lösen es durch Pooling, wie im Folgenden beschrieben.

2. Connection Pooling

Es gibt keine Lese-Replikate. Jeder Lese- und jeder Schreibvorgang trifft auf die einzelne Primärinstanz. Daher wird eine unbegrenzte Anwendung, die pro Anfrage eine Verbindung öffnet, die feste Obergrenze von max_connections schnell erschöpfen. Pooling ist zwingend erforderlich, nicht optional, und Sie nutzen zwei Ebenen gemeinsam: einen Pool auf Anwendungsebene und den verwalteten PgBouncer-Pooler.

2.1 Anwendungsebenes Pooling mit SQLAlchemy

Begrenzen Sie den SQLAlchemy-Pool deutlich unter der Cluster-Obergrenze und aktivieren Sie pool_pre_ping, damit veraltete Verbindungen recycelt und nicht während eines Fehlers an eine Anfrage übergeben werden.

from sqlalchemy import create_engine, text

engine = create_engine(
    "postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:5432/taskboard",
    connect_args={"sslmode": "require"},
    pool_size=20,          # steady-state connections
    max_overflow=10,       # burst headroom, keep total well under the ceiling
    pool_pre_ping=True,
    pool_recycle=1800,
)

with engine.connect() as conn:
    rows = conn.execute(text("SELECT id, title FROM tasks WHERE status = :s"),
                        {"s": "open"}).fetchall()

Wenn Sie N Replikate der Anwendung betreiben, erkennt der Cluster N * (pool_size + max_overflow) Verbindungen. Dimensionieren Sie den Pool anhand der Gesamtzahl des Clusters, geteilt durch Ihre Replikatanzahl, und lassen Sie dabei einen Puffer.

2.2 Verwalteter PgBouncer-Pooler

PostgreSQL-Cluster bieten einen verwalteten PgBouncer-Pooler. Sie aktivieren ihn und wählen den Poolmodus; die unterstützten Modi sind transaction (Standard) und session. Der Pooler lauscht auf Port 6432, nicht auf den Datenbankport 5432.

# Route the app through PgBouncer: same host, pooler port 6432
engine = create_engine(
    "postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:6432/taskboard",
    connect_args={"sslmode": "require"},
    pool_size=10, max_overflow=5, pool_pre_ping=True,
)

Verwenden Sie den Modus transaction für typische Web-Workloads, damit eine Backend-Verbindung nur für die Dauer einer Transaktion aufrechterhalten wird. Dies erhöht die Anzahl der Clients, die die feste Verbindungsgrenze bedienen kann. Sessionsbezogene Funktionen wie vorbereitete Anweisungen und SET, die über eine Sitzung hinweg bestehen bleiben müssen, erfordern den Modus session.

3. Integration von MariaDB und MongoDB

PostgreSQL ist einer von mehreren verwalteten Engines, und das Verbindungsmodell ist konsistent: privates LAN, erzwungenes TLS, feste Grenzen. Der Treiber und die Berechnung der Verbindungsgrenzen unterscheiden sich je nach Engine.

3.1 MariaDB

MariaDB lauscht auf Port 3306. Alle Client-Verbindungen sind TLS-verschlüsselt, und das Serverzertifikat wird von Let's Encrypt ausgestellt, sodass ein standardmäßiges CA-Bundle es validiert. Es werden nur Long-Term-Support-Versionen angeboten, beginnend mit 10.6 (zum Beispiel 10.6 und 10.11). Die Replikation erfolgt ausschließlich asynchron.

Die Cluster-Grenze max_connections beträgt 500, und jeder Benutzer ist auf 250 Verbindungen begrenzt. Diese Benutzergrenze ist bewusst gewählt: Da ein Benutzer höchstens 250 der 500 Slots belegen kann, ist die Wahrscheinlichkeit deutlich geringer, dass ein einzelner unkontrolliert laufender Anwendungsbenutzer das gesamte Cluster auslaugt.

import mysql.connector

cnx = mysql.connector.connect(
    host="10.7.222.20",
    port=3306,
    database="taskboard",
    user="taskboard_app",
    password="<pw>",
    ssl_disabled=False,        # TLS is enforced server-side regardless
    pool_name="taskboard_pool",
    pool_size=20,
)
cur = cnx.cursor()
cur.execute("SELECT id, title FROM tasks WHERE status = %s", ("open",))
for task_id, title in cur.fetchall():
    print(task_id, title)
cur.close(); cnx.close()

Der Speicher ist auf 2 TB pro Cluster begrenzt, und eine einzelne Instanz darf 16 Kerne nicht überschreiten.

3.2 MongoDB

MongoDB-Cluster stellen eine Verbindungszeichenfolge in der Form mongodb+srv://m-<id>.mongodb.<region>.ionos.com bereit, die Sie in der Regel aus einer Terraform-Ausgabe lesen, anstatt sie hartkodiert einzubetten. Die unterstützten Versionen sind 6.0 und 7.0. Seitens des Servers wird kein Verbindungspooling bereitgestellt, sodass der Pool auf der Treiberseite in pymongo Ihr Pool ist.

from pymongo import MongoClient

uri = "mongodb+srv://taskboard_app:<pw>@m-abc123.mongodb.de-txl.ionos.com"
client = MongoClient(
    uri,
    tls=True,
    maxPoolSize=50,
    serverSelectionTimeoutMS=5000,
    retryWrites=True,
)
db = client["taskboard"]
db.task_events.insert_one({"task_id": 42, "event": "created"})
print(db.task_events.count_documents({"task_id": 42}))

Die maximale Verbindungsanzahl skaliert mit dem RAM. Die folgende Tabelle zeigt die durchgesetzte Zuordnung.

Die Rollenzuweisung verwendet die in MongoDB integrierten Rollen wie read, readWrite, dbAdmin und clusterMonitor. Vergeben Sie readWrite, das auf die taskboard-Datenbank beschränkt ist, für den Anwendungsnutzer, anstatt einer clusterweiten Administratorrolle.

4. In-Memory DB (Redis) Caching

Da die relationalen Engines keine Lese-Replikate bereitstellen, ist der In-Memory DB-Cluster der nativen Weg in IONOS CLOUD, um relationale Lesezugriffe zu skalieren. Er ist mit Redis OSS 7.2 kompatibel und lauscht auf dem Port 6379. TLS verwendet eine Let's Encrypt-Zertifizierungsstelle, sobald Sie die Instanz entsprechend konfiguriert haben (TLS ist standardmäßig nicht aktiviert, daher muss es explizit aktiviert werden, wie es das redis-py-Beispiel unten mit ssl=True tut). Ein Cluster besteht aus maximal 5 Knoten. Die zugrunde liegende Valkey-Engine verwendet standardmäßig ein Maximum von 10.000 Client-Verbindungen (maxclients).

Die Standard-Eviction-Richtlinie ist allkeys-lru und die Persistenz ist standardmäßig auf None eingestellt, was die richtige Einstellung für einen reinen Cache ist: Behandeln Sie ihn als flüchtig und stellen Sie sicher, dass Sie ihn immer aus der Quelldatenbank neu aufbauen können.

4.1 Verbindung mit redis-py

import redis

r = redis.Redis(
    host="10.7.222.30",
    port=6379,
    password="<pw>",
    ssl=True,
    ssl_cert_reqs="required",
    socket_timeout=2,
    decode_responses=True,
)
r.set("health", "ok", ex=30)
print(r.get("health"))

4.2 Cache-Aside-Muster

Cache-aside ist der Standard-Lese-Pfad: Prüfen Sie den Cache, greifen Sie bei einem Trefferverfehlern auf die Datenbank zurück und befüllen Sie anschließend den Cache. Setzen Sie eine TTL, damit veraltete Einträge ablaufen, selbst wenn keine Schreiboperation sie ungültig macht.

import json

def get_task(task_id, r, engine):
    key = f"task:{task_id}"
    cached = r.get(key)
    if cached:
        return json.loads(cached)              # cache hit
    with engine.connect() as conn:
        row = conn.execute(
            text("SELECT id, title, status FROM tasks WHERE id = :id"),
            {"id": task_id}).mappings().first()
    if row:
        r.set(key, json.dumps(dict(row)), ex=300)   # populate with 5 min TTL
    return dict(row) if row else None

4.3 Write-Through-Muster

Write-Through aktualisiert die Datenbank und den Cache in derselben Operation, damit Lesevorgänge nach einem Schreibvorgang niemals einen veralteten Wert liefern. Schreiben Sie zuerst in die Datenbank und aktualisieren Sie den Cache erst, nachdem der Commit erfolgreich war.

def update_task_status(task_id, status, r, engine):
    with engine.begin() as conn:                # commits on context exit
        conn.execute(text("UPDATE tasks SET status = :s WHERE id = :id"),
                     {"s": status, "id": task_id})
    r.set(f"task:{task_id}", json.dumps({"id": task_id, "status": status}),
          ex=300)

Redis eignet sich für TaskBoard noch an zwei weiteren Stellen: für die Sitzungsspeicherung und zum Caching der Abfrageergebnisse der Aufgabenliste, die andernfalls bei jedem Seitenaufruf die einzelne Primärinstanz stark belasten würden.

5. Wiederherstellung: PITR und die Lücke im Backup Service

Die Wiederherstellung für verwaltete Datenbanken erfolgt über die eigene point-in-time-Wiederherstellung der Datenbank, nicht über den Backup Service. Der Backup Service sichert verwaltete DBaaS-Instanzen nicht, daher darf nicht davon ausgegangen werden, dass die Aufgabendaten durch eine Sicherungseinheit erfasst werden. Für logische Exporte, die über das PITR-Fenster hinausgehen, sollten Sie pg_dump oder das MariaDB-Dump-Tool aus dem Anwendungscode oder einem Cron-Job planen und die Ausgabe im Object Storage ablegen.

PostgreSQL und MariaDB verwenden standardmäßig auf v1-Clustern ein 7-tägiges point-in-time-Wiederherstellungsfenster. Bei ihren v2-APIs ist die Aufbewahrungsdauer jedoch über backup.retentionDays von 1 bis 365 Tage konfigurierbar. Prüfen Sie daher vor Annahmen über ein starres 7-Tage-Fenster die API-Version und die Aufbewahrungseinstellung Ihres Clusters. Die PITR-Wiederherstellung erfolgt über die REST-API. Der Basispfad für PostgreSQL lautet https://api.ionos.com/databases/postgresql, und eine Wiederherstellung ist eine In-Place-Operation; die Datenbank ist während der Ausführung nicht verfügbar.

5.1 Auslösen der PostgreSQL-PITR über die API

curl -X POST \
  "https://api.ionos.com/databases/postgresql/clusters/${CLUSTER_ID}/restore" \
  -H "Authorization: Bearer ${IONOS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "recoveryTargetTime": "2026-06-04T09:30:00Z"
  }'

Der Wert recoveryTargetTime ist ein ISO-8601-Zeitstempel und ist nicht inklusiv. Einschränkungen für die Wiederherstellung: Es kann nur eine Sicherung auf einmal wiederhergestellt werden, der Cluster muss sich im Zustand AVAILABLE befinden, bevor Sie eine Wiederherstellung auslösen, Sie können nur von derselben oder einer älteren Hauptversion wiederherstellen, und eine Wiederherstellung kann die Datenbank in eine andere Region verschieben. Die Plattform empfiehlt während der Wiederherstellung mindestens 4 GB RAM, die Sie anschließend wieder reduzieren können.

Schnellreferenz für die API

Wichtige API-Endpunkte für die Integration verwalteter Datenbanken:

Basis-URL: https://api.ionos.com/databases/postgresql (regionsspezifische Hosts gelten für In-Memory DB und MariaDB) Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Verbinde die TaskBoard API mit PostgreSQL und dem In-Memory DB Cache, füge eine Aufgabe ein, cache den Lesevorgang und verifiziere TLS.

Voraussetzungen:

• IONOS CLOUD Konto mit API Token
• Ein laufender PostgreSQL Cluster und ein In-Memory DB Replikat-Set auf einem gemeinsamen privaten LAN
• Python 3.10+ mit psycopg2-binary, sqlalchemy und redis installiert
• Die primaryInstanceAddress des Clusters und die Knotenadresse der In-Memory DB

Schritt 1: TLS zu PostgreSQL verifizieren

PGPASSWORD=$PW psql "host=10.7.222.10 port=5432 dbname=taskboard user=taskboard_app sslmode=require" -c "SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid();"

Erwartete Ausgabe:

 ssl
-----
 t

Schritt 2: Erstellen der Tabelle tasks

PGPASSWORD=$PW psql "host=10.7.222.10 sslmode=require dbname=taskboard user=taskboard_app" \
  -c "CREATE TABLE IF NOT EXISTS tasks (id SERIAL PRIMARY KEY, title TEXT, status TEXT);"

Erwartete Ausgabe:

CREATE TABLE

Schritt 3: Eine Aufgabe aus Python einfügen

from sqlalchemy import create_engine, text
engine = create_engine("postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:5432/taskboard",
                       connect_args={"sslmode": "require"}, pool_size=5, pool_pre_ping=True)
with engine.begin() as c:
    tid = c.execute(text("INSERT INTO tasks (title, status) VALUES (:t, 'open') RETURNING id"),
                    {"t": "Lab task"}).scalar()
print("task id:", tid)

Erwartete Ausgabe:

task id: 1

Schritt 4: Verbindung mit dem Cache herstellen

import redis
r = redis.Redis(host="10.7.222.30", port=6379, password="<pw>", ssl=True,
                ssl_cert_reqs="required", decode_responses=True)
print(r.ping())

Erwartete Ausgabe:

True

Schritt 5: Lesen cachen (Cache-Aside)

import json
key = f"task:{tid}"
if not r.get(key):
    with engine.connect() as c:
        row = c.execute(text("SELECT id, title, status FROM tasks WHERE id = :id"),
                        {"id": tid}).mappings().first()
    r.set(key, json.dumps(dict(row)), ex=300)
print(r.get(key))

Erwartete Ausgabe:

{"id": 1, "title": "Lab task", "status": "open"}

Schritt 6: Bestätigen, dass der zweite Lesevorgang ein Cache-Treffer ist

print("cached:", r.ttl(key), "seconds remaining")

Erwartete Ausgabe:

cached: 300 seconds remaining

Prüfliste:

• [ ] psql meldet ssl = t, was bestätigt, dass TLS aktiv ist
• [ ] Aufgabenzeile eingefügt und eine ID über SQLAlchemy zurückgegeben
• [ ] r.ping() gibt True über TLS zurück
• [ ] Der zweite Lesevorgang gibt den Wert aus Redis zurück, nicht aus PostgreSQL

Aufräumarbeiten:

PGPASSWORD=$PW psql "host=10.7.222.10 sslmode=require dbname=taskboard user=taskboard_app" -c "DROP TABLE tasks;"
# Flush the lab cache key
redis-cli -h 10.7.222.30 -p 6379 -a "$PW" --tls DEL task:1

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Integration verwalteter Datenbanken zu vermeiden sind:

1. Verbindung pro Anfrage öffnen und das Limit erschöpfen

   • Problem: Unter Last wirft die Anwendung FATAL: too many connections for role oder sorry, too many clients already.
   • Ursache: max_connections ist durch den RAM des Clusters festgelegt (zum Beispiel 1000 bei mehr als 8 GB), 11 Slots sind reserviert, und es gibt keine Lese-Replikate, um die Last zu verteilen. Eine Anwendung ohne Verbindungspool multipliziert die Verbindungen mit der Anzahl der Replikate.
   • Lösung: Begrenzen Sie den Pool deutlich unter dem Limit und leiten Sie die Anfragen über PgBouncer im transaction-Modus auf Port 6432 weiter:

   create_engine(url, pool_size=20, max_overflow=10, pool_pre_ping=True)
   

2. Annahme, dass der Backup Service Ihre Datenbankdaten schützt

   • Problem: Eine fehlerhafte Migration entfernt eine Tabelle, und es gibt keine Sicherungseinheit, von der aus wiederhergestellt werden kann.
   • Warum es passiert: Der Backup Service sichert verwaltete DBaaS-Instanzen nicht. Entwickler gehen davon aus, dass ein Sicherungstool alles abdeckt.
   • Lösung: Verlassen Sie sich für die kürzliche Wiederherstellung auf die Datenbank-PITR (Standardfenster von 7 Tagen, über die v2 API per backup.retentionDays konfigurierbar von 1 bis 365 Tagen) und planen Sie logische Dump-Dateien für ältere Daten ein:

   pg_dump "host=10.7.222.10 sslmode=require dbname=taskboard" | gzip > taskboard-$(date +%F).sql.gz
   

3. Deaktivierung von TLS, um es „funktionieren zu lassen“

   • Problem: Die Verbindung schlägt lokal fehl, daher greift eine Entwicklungsperson zu sslmode=disable.
   • Ursache: Ein fehlendes oder veraltetes CA-Bündel führt zu einem Fehlschlag der Zertifikatsvalidierung, und der schnelle Workaround sieht aus wie das Abschalten von TLS.
   • Lösung: TLS kann auf PostgreSQL durch den Client nicht deaktiviert werden (der Standardmodus ist prefer und kann nicht deaktiviert werden), daher sollte stattdessen die CA-Kette korrigiert werden. PostgreSQL verknüpft mit ISRG Root X1. MariaDB und In-Memory DB verwenden Let's Encrypt. Aktualisieren Sie das System-CA-Bündel und behalten Sie sslmode=require bei.

Zusammenfassung

Sie können jetzt Produktionsanwendungscode mit jeder von IONOS CLOUD verwalteten Datenbankengine verbinden, wobei TLS erzwungen und Verbindungen gepoolt werden, und Sie können Daten über den richtigen Mechanismus wiederherstellen. Das Verbindungsmodell ist über alle Engines hinweg konsistent: privates LAN, verschlüsselter Transport und eine feste Verbindungsgrenze, die Sie durch Pooling einhalten, anstatt sie mit einem Serverflag zu umgehen. Der In-Memory DB-Cache ist Ihr Werkzeug zum Skalieren von Lesezugriffen, da die relationalen Engines keine Lese-Replikate bereitstellen.

Für TaskBoard gilt insbesondere: PostgreSQL speichert die Aufgaben, Redis puffert Lesezugriffe und Sitzungen, und die Wiederherstellung erfolgt über Datenbank-PITR plus eigene geplante Sicherungen. Erstellen Sie diese Verbindungshilfsprogramme einmalig, mit eingebautem Pooling und TLS, und verwenden Sie sie in jedem Dienst der Anwendung erneut.

Wichtige Punkte:

• Verwaltete Datenbanken werden über das private LAN mit erzwungenem TLS erreicht, niemals über einen öffentlichen Endpunkt
• max_connections ist durch den Cluster-Arbeitsspeicher festgelegt und nicht benutzerkonfigurierbar, daher ist Pooling obligatorisch
• Die relationalen Engines haben keine Lese-Replikate; der In-Memory DB-Cache ist die native Lese-Skalierungslösung von IONOS CLOUD
• PgBouncer im Modus transaction auf Port 6432 vervielfacht die Anzahl der Clients, die eine feste Grenze bedienen kann
• Der Backup Service sichert DBaaS nicht; die Wiederherstellung erfolgt über Datenbank-PITR (Standard: 7 Tage, konfigurierbar 1-365 Tage über die v2 API) plus eigene Sicherungen

Wichtige Begriffe:

• PITR: Point-in-time recovery, Wiederherstellung eines Clusters auf einen ISO-8601-Zeitstempel innerhalb des Aufbewahrungsfensters (Standard: 7 Tage; 1-365 Tage konfigurierbar über die v2 API) über die REST API
• PgBouncer: Der verwaltete PostgreSQL-Verbindungspooler auf Port 6432, der die Pool-Modi transaction und session unterstützt
• Cache-aside: Ein Lese-Muster, das den Cache prüft, bei einem Verfehlen auf die Datenbank zurückgreift und anschließend den Cache mit einer TTL befüllt
• Write-through: Ein Schreib-Muster, das Datenbank und Cache in derselben Operation aktualisiert, um veraltete Lesezugriffe zu vermeiden
• primaryInstanceAddress: Die private-LAN-Adresse der primären Instanz eines Datenbankclusters, mit der sich die Anwendung verbindet

Nächste Schritte

Weiter lernen: Einheit 4.2: Object Storage Integration

Verwandte Themen:

• Einheit 4.3: Event Streaming Integration
• Einheit 4.4: AI Model Hub Integration