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, selbstgenerierte Credentials. Null Wartung der Datenbank-Engine.

KONTAKTIEREN SIE UNSERE EXPERTEN DOKUMENTATION

PostgreSQL

Beziehungsorientiert

Streaming + Failover

Transaktionsanwendungen, APIs, SaaS

MariaDB

Beziehungsorientiert

Binog + auto-failover

CMS, E-Commerce, Legacy-Anwendungen

Redis

Wertschlüssel

Sentinel + Autofailover

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

Managed PostgreSQL Service auf Basis von CloudNativePG. Eine Primary nimmt Schreibvorgänge entgegen, Replikate werden per Streaming Replication von der Primary synchronisiert. Bei einem Ausfall wird automatisch ein Replikat ohne manuelles Eingreifen gefördert.

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. Die Wiederherstellung ist jederzeit zwischen zwei Backups möglich.
Deklarative Benutzer und Datenbanken
Deklarieren Sie Ihre Benutzer, Datenbanken, Admin- und Readonly-Rollen direkt in der Manifestdatei. Credentials in einem selbstgenerierten Secret gespeichert.
PostgreSQL-Erweiterungen
Aktivieren Sie uuid-ossp, pgcrypto, hstore und andere Erweiterungen pro Datenbank im Abschnitt databases[name].extensions.
Optionale synchrone Replikation
Konfigurieren Sie quorum.minSyncReplicas so, dass eine Transaktion erst nach Bestätigung einer Replikation freigegeben wird. uement.

Empfehlung Produktion

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

yaml

apiVersion: apps.cozystack.io/v1alpha1
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. MariaDB ist ein Open-Source-Fork von MySQL, der vollständig mit den MySQL-Clients und -Protokollen kompatibel ist - Ihre Anwendungen laufen ohne Änderungen. Mit replicas: 3 erhalten Sie 1 Primary + 2 Replicas, die auf verschiedene Rechenzentren verteilt sind.

Die Replikation verwendet das Binlog von MariaDB. Bei einem Ausfall der Primary wird automatisch ein Replikat gefördert.

MySQL-kompatibel 100%.
MySQL-Clients, -Protokolle, -Treiber funktionieren ohne Anpassung. Das CRD heißt MySQL, der Betreiber nutzt intern MariaDB.
Sicherungen von Restic nach S3.
Verschlüsselte Snapshots mit konfigurierbarer Aufbewahrung (--keep-last, --keep-daily). Gespeichert in einem beliebigen kompatiblen S3-Bucket.
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 Knoten durch Änderung des Manifests - nützlich für die Wartung.

Externe Exposition

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

yaml

apiVersion: apps.cozystack.io/v1alpha1
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

Managed Redis Service mit Master-Replicas-Architektur und Redis Sentinel. Mit replicas: 3 erhalten Sie 3 Redis-Pods (Master + Replikas) und 3 Sentinel-Pods für die Überwachung. Der Sentinel erkennt den Ausfall des Masters und fördert automatisch ein Replikat.

Die Daten werden über RDB/AOF auf Kubernetes-Volumes persistiert. Das Passwort wird automatisch generiert und in einem Secret gespeichert.

Automatische Sentinel und Quorum
Mindestens 3 Sentinel-Pods, um das Quorum zu gewährleisten (2/3-Mehrheit). Failover wird durch Konsens zwischen den Sentinels ausgelöst.
Standardauthentifizierung
authEnabled: true Standard - selbst generiertes Passwort. Nur bei isolierter Entwicklung deaktivieren.
RDB/AOF-Persistenz
Daten überleben auch Neustarts. Konfigurieren Sie die storageClass entsprechend Ihren Anforderungen an Leistung vs. Ausfallsicherheit.
Verbindung über Sentinel empfohlen.
Verbinden Sie Ihre Apps über den Dienst rfs-redis-<name> (Port 26379), um den Master nach Failover automatisch zu verfolgen.

StorageClass und Replikation

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

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: Redis
metadata:
  name: example
spec:
  replicas: 3 # 3 Redis + 3 Sentinel 
  resourcesPreset: nano
  size: 1Gi
  authEnabled: true # Mot de passe auto-généré
  external: false 


Bash
# Récupérer le mot de passe
kubectl get secret redis-example-auth \
  -o json 1 jq -r \
  ' data | to_entries[] | "\ (.key): \. value |@base64d)"'

MongoDB

Vector Search Replica Set Atlas-kompatibel

Managed MongoDB-Service, der auf dem MongoDB Kubernetes Operator basiert. Jede Instanz setzt ein Replica Set ein - ein Primary nimmt Schreibvorgänge entgegen, die Secondaries erhalten Änderungen per Oplog-Replikation. Bei einem Ausfall des Primary wird durch eine automatische Wahl ein neuer Primary aus den Secondaries bestimmt.

MongoDB ist eine dokumentenorientierte Datenbank (BSON/JSON) ohne festes Schema, die sich besonders für halbstrukturierte Daten, REST-APIs und Anwendungen mit sich häufig ändernden Datenmodellen eignet.

Replica Set mit automatischer Wahl
Mindestens 3 Mitglieder für das Quorum - 1 primary + 2 secondaries. Der Primary wird im Falle eines Ausfalls automatisch durch Mehrheitswahl gewählt.
Dokumentenorientierte Datenbank.
BSON-Speicherung (binäres JSON), flexibles Schema, Indizierung in beliebigen Feldern. Ideal für Kataloge, Benutzerprofile, IoT-Daten, APIs.
Integrierte S3-Backups.
Snapshots über Restic zu jedem kompatiblen S3-Bucket - einschließlich Hikube Object Storage Buckets.
Selbstgenerierte Berechtigungsnachweise.
Im Manifest deklarierte Benutzer und Passwörter, die in einem selbstgenerierten Kubernetes Secret gespeichert sind.

Empfehlung Produktion

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

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: MongoDB 
metadata:
  name: example
spec:
  replicas: 3 # 1 primary + 2 secondaries
  resourcesPreset: micro
  size: 10G1
  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, die für analytische Abfragen in großen Mengen optimiert ist. 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 Hochverfügbarkeit.

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

Nur OLAP
ClickHouse ist nicht für häufige Transaktionen (Unit UPDATE/DELETE) geeignet. Für transaktionale Zwecke sollten Sie PostgreSQL oder MySQL verwenden.
Sharding und Parallelität
SELECT-Abfragen werden auf allen Shards parallel ausgeführt. Für kleine Mengen reicht 1 Shard + 2 Replikate.
Integrierter ClickHouse Keeper .
Wird automatisch mit 3 Standardinstanzen bereitgestellt. Verwaltet die Raft-Koordination zwischen den Replikas auf jedem Shard.
Backups von Restic nach S3.
Gleiches Modell wie MySQL - verschlüsselte Snapshots, konfigurierbare Retention, Hikube-kompatibler S3-Endpunkt.

Empfehlung Produktion

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

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: ClickHouse 
metadata:
  name: example
spec:
  shards: 1 # Partitions horizontales
  replicas: 2 # Copies par shard → 2 pods
  resourcesPreset: small
  size: 10Gi
  clickhouseKeeper:
    enabled: true
    replicas: 3 # Toujours impair
    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, Versionsaktualisierungen zu verwalten, die Replikation zu überwachen, Backups zu konfigurieren, Wiederherstellungsverfahren zu testen und um 3 Uhr morgens einzugreifen, wenn ein Primary abstürzt. Das ist keine Wertschöpfung, das ist Infrastruktur.

Auf Hikube fällt dieser Aufwand weg. Sie deklarieren, was Sie wollen, Basistyp, Anzahl der Replikate, Größe, Benutzer, und der Betreiber stellt automatisch bereit, repliziert, schaltet auf Failover um und sichert. Ihre Teams konzentrieren sich auf die Abfragen, das Schema und die 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 der gleichen PostgreSQL-Instanz. ACID-Transaktionen, Integritätsbeschränkungen, komplexe Joins. Das sekundäre Replikat absorbiert Reporting-Abfragen, ohne die Primary zu beeinträchtigen.

replicas: 3 - quorum: 1 - WAL backup

CMS und E-Commerce-Plattform

WordPress, Magento, PrestaShop. Alle diese Anwendungen sind für MariaDB konzipiert. Migration von einem selbstgehosteten MariaDB ohne Codeänderung. Der externe LoadBalancer bietet direkten Zugriff von den Verwaltungswerkzeugen aus.

replicas: 3 - external: true - Restic backup

Sessions Cache und Rate Limiting

Speicherung von Benutzersitzungen in einer Hochfrequenz-API. Sub-Millisekunden-Latenz, automatischer Schlüsselverfall (TTL), Atomzähler für Rate Limiting. Der Sentinel garantiert die Kontinuität, selbst wenn der Master fällt.

replicas: 3 - authEnabled: true - storageClass: local

Produktkatalog und REST API

E-Commerce-Katalog mit variablen Attributen je nach Kategorie (Kleidung, Elektronik, Lebensmittel). Das flexible Schema von MongoDB vermeidet die Migration von Tabellen bei jedem neuen Produkttyp. Indexierung auf jedes verschachtelte Feld...

replicas: 3 - Replica Set - Restic backup

Echtzeit-Analytik auf Anwendungslogs

Verwaltung von Milliarden von Ereignissen (Logs, Metriken, Klicks). Aggregierte Abfragen werden dank Spaltenspeicher und Sharding selbst auf Terabyte großen Tabellen in Sekundenschnelle ausgeführt. Ideal für BI-Dashboards und Echtzeit-Warnungen.

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 gemeinsam haben

Jede auf Hikube verwaltete Datenbank zeigt die gleichen grundlegenden Mechanismen, unabhängig von der gewählten Technologie.

Deklarative Bereitstellung über kubectl.
Ein YAML-Manifest, ein kubectl apply. Der Betreiber provisioniert und pflegt den Cluster automatisch.
Selbstgenerierte Credentials in einem Secret.
Jeder Dienst generiert ein Kubernetes Secret <service>-<name>-credentials, das die Passwörter enthält. Keine manuelle Konfiguration der Zugänge.
Integrierte S3-Backups.
PostgreSQL verwendet WAL archiving + CloudNativePG. MariaDB und ClickHouse verwenden Restic. Alle 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 Produktionsumgebungen. Beide schließen sich gegenseitig aus.

nano

250m

128 Mi

Mikro

500m

256 Mi

small

1 CPU

512 mi

medium

1 GPU

1 Gi

breite

2 GPUS

2 Gi

xlarge

4 GPUS

4 Gi

2xbreit

8 GPU

8 Gi

Ja, dies ist der empfohlene Anwendungsfall. Erstellen Sie einen Hikube-Bucket, rufen Sie die Credentials aus dem generierten Secret ab und füllen Sie sie im Backup-Abschnitt Ihres Manifests aus. So bleiben die Backups in der gleichen 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 Transaktionsoperationen sollten Sie PostgreSQL oder MySQL auf Hikube verwenden.

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

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 BDDS

Native HA

S3-Backup

0 config

Der richtige Motor 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 Basis für welchen Bedarf?

Multi-Tenant-SaaS-Anwendung

CMS und E-Commerce-Plattform

Sessions Cache und Rate Limiting

Produktkatalog und REST API

Echtzeit-Analytik auf Anwendungslogs

Vollständiger Stack für eine ML-Anwendung

Was alle Dienste gemeinsam haben

Fragen zu verwalteten Datenbanken

Kann ich zu den Hikube S3 Buckets sichern?

Was ist der Unterschied zwischen resourcesPreset und resources?

Ist ClickHouse für meine Transaktionsanfragen geeignet?

Ist der MySQL-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 BDDS

Native HA

S3-Backup

0 config

Der richtige Motor 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 Basis für welchen Bedarf?

Multi-Tenant-SaaS-Anwendung

CMS und E-Commerce-Plattform

Sessions Cache und Rate Limiting

Produktkatalog und REST API

Echtzeit-Analytik auf Anwendungslogs

Vollständiger Stack für eine ML-Anwendung

Was alle Dienste gemeinsam haben

Fragen zu verwalteten Datenbanken

Kann ich zu den Hikube S3 Buckets sichern?

Was ist der Unterschied zwischen resourcesPreset und resources?

Ist ClickHouse für meine Transaktionsanfragen geeignet?

Ist der MySQL-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.