Verwaltete Datenbanken - Hikube

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - das ist alles.

Fünf vollständig gemanagte Datenbanken auf Hikube. Automatische Replikation, Failover, S3-Backups, automatisch generierte Credentials. Null Wartung der Datenbank-Engine.

KOSTENLOS STARTEN DOKUMENTATION

PostgreSQL

Relational

Streaming + Failover

Transaktionsanwendungen, APIs, SaaS

MariaDB

Relational

Binlog + Auto-failover

CMS, E-Commerce, Legacy-Anwendungen

Redis

Key-Value

Sentinel + Auto-failover

Cache, Sitzungen, Warteschlangen

MongoDB

Dokumente

Replica Set + Wahl

APIs, Kataloge, halbstrukturierte Daten

ClickHouse

Analytisch (OLAP)

ReplicatedMergeTree + Keeper

Analytik, Logs, Data Lake, OLAP

Postgres

Automatisches Failover Streaming Replication PITR

Verwalteter PostgreSQL-Dienst auf Basis von CloudNativePG. Eine Primary nimmt Schreibvorgange an; Replikate werden per Streaming Réplication von der Primary synchronisiert. Bei einem Ausfall wird automatisch ein Replikat ohne manuelles Eingreifen hochgestuft.

Die Replikate werden auf verschiedene Rechenzentren verteilt: mit replicas: 3 erhalten Sie 1 Primary + 2 Standbys an 3 Standorten.

WAL + PITR-Backups
WALs werden kontinuierlich nach S3 archiviert. Wiederherstellung zu jedem Zeitpunkt zwischen zwei Backups moglich.
Deklarative Benutzer und Datenbanken
Benutzer, Datenbanken, Admin- und Readonly-Rollen im Manifest deklarieren. Credentials in einem selbstgenerierten Secret.
PostgreSQL-Erweiterungen
uuid-ossp, pgcrypto, hstore u. a. pro Datenbank in databases[name].extensions aktivieren.
Optionale synchrone Replikation
quorum.minSyncReplicas so setzen, dass eine Transaktion erst nach Bestätigung eines Replikats freigegeben wird.

Empfehlung Produktion

replicas: 3 + quorum.minSyncReplicas: 1 für einen guten Kompromiss zwischen Leistung und Haltbarkeit.

yaml

kind: Postgres 
metadata:
  name: example
spec:
  replicas: 3
  resourcesPreset: micro
  size: 10Gi
  users:
    user1:
      password: strongpassword
  databases:
    myapp:
     roles:
      admin:
       - user1
       readonly:
       - user2
     extensions:
      - uuid-ossp
  quorum:
    minSyncReplicas: 0
    maxSyncReplicas: 0
  backup:
    enabled: false
    # destinationPath: s3://bucket/path/
    # endpointURL: https://prod.s3.hikube.cloud
    # retentionPolicy: 30d

MariaDB

Automatisches Failover Group replication Restic backup

Managed MySQL-Dienst auf der Grundlage von MariaDB-Operator. Verwalteter Dienst auf Basis von MariaDB-Operator. MariaDB ist ein Open-Source-Fork von MySQL, vollständig kompatibel mit MySQL-Clients und -Protokollen - Ihre Anwendungen laufen unverändert. Mit replicas: 3 erhalten Sie 1 Primary + 2 Replikate auf verschiedenen Rechenzentren.

Die Replikation nutzt das Binlog von MariaDB; bei einem Ausfall der Primary stuft der Operator automatisch ein Replikat hoch.

100% MySQL-kompatibel
MySQL-Clients, -Protokolle, -Treiber funktionieren ohne Anpassung. Das CRD heißt MySQL, der Operator nutzt intern MariaDB.
Restic-Backups nach S3
verschlüsselte Snapshots mit konfigurierbarer Aufbewahrung (--keep-last, --keep-daily). In jedem kompatiblen S3-Bucket gespeichert.
Optionale externe Exposition
external: true Erstellt einen LoadBalancer-Dienst mit öffentlicher IP für Verbindungen außerhalb des Clusters.
Manueller Switchover
Geplantes Umschalten der Primary auf einen anderen Node über das Manifests - nützlich für die Wartung.

Externe Exposition

Vermeiden Sie external: true, wenn Ihre Anwendungen im selben Cluster laufen. Bevorzugen Sie die Verbindung über den ClusterIP-Dienst, um die Angriffsfläche zu begrenzen.

yaml

kind: MariaDB
metadata:
  name: example
spec:
  replicas: 3
  resourcesPreset: nano
  size: 10Gi
  external: true
  users:
    user1:
      password: hackme
      maxUserConnections: 1000
  databases:
    myapp1:
      roles:
        admin:
          - user1
      readonly:
          - user2
  backup:
    enabled: false
    # resticPassword: <password>
    # s3Bucket: s3. example.org/mysql
    # schedule: "0 2 * * *"

Redis

In-memory Sentinel Auto-failover

Verwalteter Redis-Dienst mit Master-Replicas-Architektur und Redis Sentinel. Mit replicas: 3 erhalten Sie 3 Redis-Pods (Master + Replikate) und 3 Sentinel-Pods zur Überwachung. Sentinel erkennt den Master-Ausfall und stuft automatisch ein Replikat hoch.

Die Daten werden per RDB/AOF auf Kubernetes-Volumes persistiert; das Passwort wird automatisch generiert und in einem Secret gespeichert.

Automatische Sentinel und Quorum
Mindestens 3 Sentinel-Pods, für das Quorum (2/3-Mehrheit). Failover wird durch Konsens zwischen den Sentinels ausgelöst.
Standard-Authentifizierung

authEnabled: true standardmäßig, automatisch generiertes Passwort. Nur in isolierter Entwicklung deaktivieren.
RDB/AOF-Persistenz
Daten überstehen Neustarts. storageClass je nach Anforderung an Leistung vs. Ausfallsicherheit konfigurieren.
Verbindung über Sentinel empfohlen.
Verbinden Sie Ihre Apps über den Dienst rfs-redis-<name> (Port 26379), um den Master nach Failover automatisch zu folgen.

StorageClass und Replikation

Bei replicas > 1 verwenden Sie storageClass: local (die Redis-Replikation bietet bereits HA). Bei replicas: 1 bevorzugen Sie storageClass: replicated.

yaml

kind: Redis
metadata:
  name: example
spec:
  replicas: 3 # 3 Redis + 3 Sentinel 
  resourcesPreset: nano
  size: 1Gi
  authEnabled: true # automatisch generiertes Passwort  
  external: false 


Bash
# Passwort abrufen
kubectl get secret redis-example-auth \
  -o json 1 jq -r \
  ' data | to_entries[] | "\ (.key): \. value |@base64d)"'

MongoDB

Vector Search Replica Set Atlas-kompatibel

Verwalteter MongoDB-Dienst auf Basis des MongoDB Kubernetes Operator. Jede Instanz stellt ein Replica Set bereit: eine Primary nimmt Schreibvorgange an, die Secondaries erhalten Änderungen per Oplog-Replikation. Bei einem Ausfall der Primary bestimmt eine automatische Wahl eine neue Primary.

MongoDB ist eine dokumentenorientierte Datenbank (BSON/JSON) ohne festes Schema, geeignet für halbstrukturierte Daten, REST-APIs und sich ändernde Datenmodelle.

Replica Set mit automatischer Wahl
Mindestens 3 Mitglieder für das Quorum (1 Primary + 2 Secondaries). Die Primary wird bei einem Ausfall per Mehrheitswahl gewählt.
Dokumentenorientierte Datenbank
BSON-Speicherung (binares JSON), flexibles Schema, Indizierung in beliebigen Feldern. Ideal für Kataloge, Profile, IoT-Daten, APIs.
Integrierte S3-Backups.
Snapshots per Restic zu jedem kompatiblen S3-Bucket - einschließlich Hikube-Object-Storage-Buckets.
Automatisch generierte Credentials.
im Manifest deklarierte Benutzer und Passwörter, gespeichert in einem selbstgenerierten Kubernetes Secret.

Empfehlung Produktion

replicas: 3 für das Quorum (1 Primary + 2 Secondaries).

yaml

kind: MongoDB 
metadata:
  name: example
spec:
  replicas: 3 # 1 primary + 2 secondaries
  resourcesPreset: micro
  size: 10Gi
  users:
    appuser:
      password: strongpassword
      roles:
      myapp:
        - readwrite
    analyst:
      password: readonlypass
      roles:
      myapp:
        - read
 backup:
   enabled: false
   # resticPassword: <password>
   # s3Bucket: s3.example.org/mongo
   # schedule: "0 2 * * *"

ClickHouse

ReplicatedMergeTree Shards + Replicas ClickHouse Keeper

Spaltenorientierte OLAP-Datenbank, optimiert für analytische Abfragen auf großen Mengen. Die Architektur beruht auf zwei Parametern: Shards verteilen die Daten horizontal (mehr Shards = mehr Kapazität und Parallelität), Replikate duplizieren jeden Shard für Hochverfugbarkeit.

ClickHouse Keeper (Alternative zu ZooKeeper, Raft-Protokoll) koordiniert die Replikation; er benötigt eine ungerade Anzahl von Instanzen (3 empfohlen) für das Quorum.

Nur OLAP
ClickHouse ist nicht für häufige Transaktionen geeignet (Unit UPDATE/DELETE) . Für transaktionale Workloads PostgreSQL oder MySQL verwenden.
Sharding und Parallelität
SELECT-Abfragen laufen parallel auf allen Shards. Für kleine Mengen reichen 1 Shard + 2 Replikate.
Integrierter ClickHouse Keeper .
Automatisch mit standardmäßig 3 Instanzen bereitgestellt. Verwaltet die Raft-Koordination zwischen den Replikaten jedes Shards.
Restic-Backups nach S3.
Gleiches Modell wie MariaDB - verschlüsselte Snapshots, konfigurierbare Aufbewahrung, Hikube-kompatibler S3-Endpunkt.

Empfehlung Produktion

shards: 2 + replicas: 2 + Keeper: 3 für einen guten Kompromiss zwischen Kapazität und Verfügbarkeit.

yaml

kind: ClickHouse 
metadata:
  name: example
spec:
  shards: 1 # Horizontale Partitionen 
  replicas: 2 # Kopek pro Shard → 2 Pods
  resourcesPreset: small
  size: 10Gi
  clickhouseKeeper:
    enabled: true
    replicas: 3 # Immer ungerade 
    resourcesPreset: micro
    size: 1Gi
  users:
   user1:
     password: strongpassword
   analyst:
     readonly: true
     password: readonlypass

Warum gemanagt

Weniger Ops, mehr Business-Code

Eine Datenbank in der Produktion zu pflegen bedeutet, Versions-Updates zu verwalten, die Replikation zu überwachen, Backups zu konfigurieren, Wiederherstellungsverfahren zu testen und um 3 Uhr morgens einzugreifen, wenn eine Primary ausfällt. Das ist keine Wertschöpfung, das ist Infrastruktur.

Auf Hikube entfallt dieser Aufwand. Sie deklarieren, was Sie wollen - Datenbanktyp, Anzahl der Replikate, Größe, Benutzer - und der Operator provisioniert, repliziert, schaltet auf Failover um und sichert automatisch. Ihre Teams konzentrieren sich auf Abfragen, Schema und Anwendungsleistung, nicht auf die Infrastruktur.

Die Datenbanken werden in der Schweiz gehostet, im selben Rechenzentrum wie Ihre Hikube Kubernetes-Cluster. Die Latenz zwischen Ihrer Anwendung und Ihrer Datenbank ist minimal und Ihre Daten verlassen den europäischen Raum nicht.

Multi-Tenant-SaaS-Anwendung

Jeder Kunde hat ein isoliertes Schema in derselben PostgreSQL-Instanz. ACID-Transaktionen, Integritatsbeschrankungen, komplexe Joins. Das sekundare Replikat fangt Reporting-Abfragen ab, ohne die Primary zu beeinträchtigen.

replicas: 3 - quorum: 1 - WAL backup

CMS und E-Commerce-Plattform

WordPress, Magento, PrestaShop: Diese Anwendungen sind für MariaDB konzipiert. Migration von einem selbstgehosteten MariaDB ohne Codeanderung. Der externe LoadBalancer bietet direkten Zugriff aus den Admin-Tools.

replicas: 3 - external: true - Restic backup

Sessions Cache und Rate Limiting

Benutzersitzungen in einer Hochfrequenz-API. Sub-Millisekunden-Latenz, automatischer Schlüsselablauf (TTL), atomare Zahler für Rate Limiting. Sentinel garantiert die Kontinuitat, selbst wenn der Master ausfällt.

replicas: 3 - authEnabled: true - storageClass: local

Produktkatalog und REST-API

E-Commerce-Katalog mit je nach Kategorie variablen Attributen (Kleidung, Elektronik, Lebensmittel). Das flexible Schema von MongoDB vermeidet Tabellenmigrationen bei jedem neuen Produkttyp. Indizierung auf jedem verschachtelten Feld.

replicas: 3 - Replica Set - Restic backup

Echtzeit-Analytics auf Anwendungslogs

Ingestion von Milliarden von Ereignissen (Logs, Metriken, Klicks). Aggregierte Abfragen laufen dank Spaltenspeicher und Sharding selbst auf Terabyte-großen Tabellen in Sekunden. Ideal für BI-Dashboards und Echtzeit-Alerts.

shards: 2 - replicas: 2 - Keeper: 3

Vollständiger Stack für eine ML-Anwendung

PostgreSQL für strukturierte Daten (Benutzer, Jobs), Redis für die ML-Job-Queue und den Ergebnis-Cache, MongoDB für Modell-Artefakte und Metadaten (variable Struktur), ClickHouse für Echtzeit-Inferenzmetriken.

PG + Redis + Mongo + ClickHouse

Gemeinsame Funktionen

Was alle Dienste teilen

Jede auf Hikube verwaltete Datenbank bietet die gleichen grundlegenden Mechanismen, unabhangig von der gewählten Technologie.

Deklarative Bereitstellung über kubectl.
Ein YAML-Manifest, ein kubectl apply. Der Operator provisioniert und pflegt den Cluster automatisch.
Automatisch generierte Credentials in einem Secret.
Jeder Dienst erzeugt ein Secret <service>-<name>-credentials mit den Passwörtern. Keine manuelle Zugriffskonfiguration.
Integrierte S3-Backups.
PostgreSQL verwendet WAL archiving + CloudNativePG. MariaDB und ClickHouse via Restic. Zu jedem kompatiblen S3-Endpunkt einschließlich Hikube-Buckets.
Ressourcen-Presets oder explizite Konfiguration
resourcesPreset (nano bis 2xlarge) für einen schnellen Start. resources.cpu und resources.memory für die Produktion. Beide schließen sich gegenseitig aus.

nano

250m

128 Mi

Mikro

500m

256 Mi

small

1 CPU

512 MI

medium

1 CPU

1 Gi

breite

2 CPU

2 Gi

xlarge

4 CPU

4 Gi

2xbreit

8 CPU

8 Gi

Ja, das ist der empfohlene Anwendungsfall. Erstellen Sie einen Hikube-Bucket, rufen Sie die Credentials aus dem generierten Secret ab und tragen Sie sie im backup-Abschnitt Ihres Manifests ein. So bleiben die Backups in derselben Infrastruktur, in der Schweiz.

resourcesPreset wendet ein vordefiniertes Profil an (nano, micro, small...). Dies ist die einfachste Art zu starten. Wenn Sie resources.cpu und resources.memory explizit setzen, wird das Preset komplett ignoriert. Beide schließen sich gegenseitig aus kombinieren Sie sie nicht im selben Manifest.

Nein. ClickHouse ist eine OLAP-Engine, die für analytische Abfragen, Aggregationen, Spaltenscans in großen Mengen - optimiert ist. Sie ist nicht für häufige transaktionale Operationen geeignet (unitäreUPDATE / DELETE, ACID-Transaktionen). Für transaktionale Workloads PostgreSQL oder MariaDB auf Hikube verwenden.

Ja. Der Dienst basiert auf MariaDB, einem Open-Source-Fork von MySQL, vollständig kompatibel mit dem MySQL-Protokoll, der Syntax und den Clients. Ihre Anwendungen, Treiber und ORMs funktionieren ohne Änderung.

Minimum 3. Redis Sentinel benötigt ein Quorum - eine Mehrheit der Sentinels (2 von 3) muss sich einig sein, um einen Failover zu beschließen. Mit replicas: 3 erhalten Sie 3 Redis-Pods und 3 Sentinel-Pods, wodurch die Beschlussfähigkeit auch dann gewährleistet ist, wenn ein Sentinel nicht verfügbar ist.

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - das ist alles.

5 DB

Native HA

S3-Backup

0 config

Der richtige Engine für jeden Zweck

Jede Datenbank im Detail

Postgres

Empfehlung Produktion

MariaDB

Externe Exposition

Redis

StorageClass und Replikation

MongoDB

Empfehlung Produktion

ClickHouse

Empfehlung Produktion

Weniger Ops, mehr Business-Code

Automatisches Failover ohne Eingreifen

Deklaratives Scaling

Testbare und geplante Backups

Kubernetes-native Credentials

Welche Datenbank für welchen Bedarf?

Multi-Tenant-SaaS-Anwendung

CMS und E-Commerce-Plattform

Sessions Cache und Rate Limiting

Produktkatalog und REST-API

Echtzeit-Analytics auf Anwendungslogs

Vollständiger Stack für eine ML-Anwendung

Was alle Dienste teilen

Fragen zu verwalteten Datenbanken

Kann ich in Hikube-S3-Buckets sichern?

Was ist der Unterschied zwischen resourcesPreset und resources?

Ist ClickHouse für meine transaktionalen Abfragen geeignet?

Ist der MariaDB-Dienst mit meinen bestehenden MySQL-Anwendungen kompatibel?

Wie viele Redis-Replikas braucht man für automatisches Failover?

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse. kubectlapply - das ist alles.

5 DB

Native HA

S3-Backup

0 config

Der richtige Engine für jeden Zweck

Jede Datenbank im Detail

Postgres

Empfehlung Produktion

MariaDB

Externe Exposition

Redis

StorageClass und Replikation

MongoDB

Empfehlung Produktion

ClickHouse

Empfehlung Produktion

Weniger Ops, mehr Business-Code

Automatisches Failover ohne Eingreifen

Deklaratives Scaling

Testbare und geplante Backups

Kubernetes-native Credentials

Welche Datenbank für welchen Bedarf?

Multi-Tenant-SaaS-Anwendung

CMS und E-Commerce-Plattform

Sessions Cache und Rate Limiting

Produktkatalog und REST-API

Echtzeit-Analytics auf Anwendungslogs

Vollständiger Stack für eine ML-Anwendung

Was alle Dienste teilen

Fragen zu verwalteten Datenbanken

Kann ich in Hikube-S3-Buckets sichern?

Was ist der Unterschied zwischen resourcesPreset und resources?

Ist ClickHouse für meine transaktionalen Abfragen geeignet?

Ist der MariaDB-Dienst mit meinen bestehenden MySQL-Anwendungen kompatibel?

Wie viele Redis-Replikas braucht man für automatisches Failover?

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - das ist alles.