Datenbankskalierungsstrategien: Replikate lesen, Sharding und mehr

Die Datenbankleistung ist der Engpass bei 78 % der Skalierungsprobleme von Webanwendungen. Anwendungen können mit minimalem Aufwand horizontal skaliert werden, Datenbanken widersetzen sich jedoch der horizontalen Skalierung. Die von Ihnen für die Datenbankskalierung gewählten Strategien bestimmen, ob Ihre Anwendung 100 oder 100.000 Benutzer mit akzeptabler Leistung bedient.

Dieser Leitfaden deckt das gesamte Spektrum der Datenbankskalierungsstrategien ab, von einfachen Optimierungen, die die Notwendigkeit einer Skalierung verzögern, bis hin zu fortgeschrittenen Techniken wie horizontalem Sharding.

Wichtige Erkenntnisse

• Optimize queries and add indexes before adding infrastructure --- this solves 60% of database performance issues – Lesereplikate sind die Skalierungsstrategie mit dem geringsten Risiko und bewältigen 80 % der leseintensiven Arbeitslasten – Verbindungspooling ist obligatorisch, sobald Ihre Anwendung mehr als 10 Instanzen ausführt – Horizontales Sharding ist der letzte Ausweg, der eine erhebliche Anwendungskomplexität mit sich bringt

---

Die Skalierungsleiter

Skalieren Sie in dieser Reihenfolge. Jeder Schritt ist günstiger und weniger riskant als der nächste:

Schritt 1: Abfrageoptimierung (kostenlos)

Stellen Sie vor dem Hinzufügen der Infrastruktur sicher, dass Ihre vorhandene Datenbank optimal funktioniert.

-- Find slow queries in PostgreSQL
SELECT
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  query
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

Gängige Optimierungen:

– Fügen Sie fehlende Indizes für häufig gefilterte Spalten hinzu – Ersetzen Sie SELECT * durch bestimmte Spaltenlisten – Verwenden Sie EXPLAIN ANALYZE, um sequentielle Scans in großen Tabellen zu identifizieren – Fügen Sie zusammengesetzte Indizes für mehrspaltige WHERE-Klauseln hinzu

• Implementieren Sie die Paginierung mit Keyset-Paginierung anstelle von OFFSET

-- Bad: OFFSET pagination (scans all skipped rows)
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 10000;

-- Good: Keyset pagination (index-only scan)
SELECT * FROM orders
WHERE created_at < '2026-03-15T10:00:00Z'
ORDER BY created_at DESC
LIMIT 20;

Schritt 2: Vertikale Skalierung ($)

Erhöhen Sie CPU, RAM und Speicher auf Ihrem vorhandenen Datenbankserver. Dies spart Zeit und erfordert keine Anwendungsänderungen.

Bei 64 GB RAM und 8 vCPUs stoßen die meisten Anwendungen an ihre Grenzen. Darüber hinaus wird die vertikale Skalierung unerschwinglich.

Schritt 3: Verbindungspooling ($)

Application (50 pods x 20 connections = 1,000 connections)
    |
    v
PgBouncer (25 database connections, transaction pooling)
    |
    v
PostgreSQL (25 active connections, manageable)

PgBouncer-Konfiguration:

[databases]
app = host=db.example.com port=5432 dbname=production

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
pool_mode = transaction
default_pool_size = 25
max_client_conn = 1000
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

Schritt 4: Replikate lesen ($$)

Lesereplikate verarbeiten SELECT-Abfragen und entlasten 60–90 % der Datenbanklast von der Primärdatenbank.

Architektur:

Write queries --> Primary database
                      |
              Replication (async)
                      |
                 +----+----+
                 |         |
Read queries --> Replica 1  Replica 2

Routing auf Anwendungsebene (Drizzle ORM-Beispiel):

import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';

const primaryPool = new Pool({ connectionString: process.env.DATABASE_URL });
const replicaPool = new Pool({ connectionString: process.env.DATABASE_REPLICA_URL });

export const primaryDb = drizzle(primaryPool);
export const replicaDb = drizzle(replicaPool);

// In service code:
// Write operations use primaryDb
async createOrder(data: OrderInput) {
  return primaryDb.insert(orders).values(data).returning();
}

// Read operations use replicaDb
async getOrders(organizationId: string) {
  return replicaDb.select().from(orders)
    .where(eq(orders.organizationId, organizationId))
    .orderBy(desc(orders.createdAt));
}

Hinweise zur Replikationsverzögerung: Die asynchrone Replikation führt zu einer Verzögerung (normalerweise 10–100 ms). Unmittelbar nach einem Schreibvorgang können beim Lesen aus dem Replikat veraltete Daten zurückgegeben werden. Verwenden Sie die primäre für Lesevorgänge, die auf Schreibvorgänge im selben Benutzerfluss folgen.

Schritt 5: Caching ($$)

Redis-Caching eliminiert wiederholte Datenbankabfragen vollständig.

async getProduct(id: string): Promise<Product> {
  const cacheKey = `product:${id}`;

  // Check cache first
  const cached = await this.redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Cache miss: query database
  const product = await this.db.select().from(products)
    .where(eq(products.id, id))
    .limit(1);

  // Cache for 5 minutes
  await this.redis.setex(cacheKey, 300, JSON.stringify(product[0]));

  return product[0];
}

Cache-Invalidierungsstrategie: Beim Schreiben ungültig machen. Wenn ein Produkt aktualisiert wird, löschen Sie den Cache-Schlüssel. Verwenden Sie ein Cache-Aside-Muster (Anwendung verwaltet den Cache) anstelle eines Durchschreibmusters (Datenbank verwaltet den Cache).

Schritt 6: Horizontales Sharding ($$$)

Beim Sharding werden Daten basierend auf einem Shard-Schlüssel auf mehrere Datenbankinstanzen verteilt.

Wann soll ein Shard erfolgen:

– Eine einzelne Datenbank ist größer als 1 TB und wächst – Der Schreibdurchsatz übersteigt das, was ein einzelner Primärserver verarbeiten kann

• Die Kosten für die vertikale Skalierung übersteigen 2.000 US-Dollar/Monat, ohne Spielraum

Wann man NICHT sharden sollte:

• Sie haben die Schritte 1-5 noch nicht ausgeschöpft
• Ihre Daten passen in eine einzige 500-GB-Datenbank
• Shardübergreifende Abfragen kommen in Ihrer Anwendung häufig vor

---

PostgreSQL-spezifische Optimierungen

Partitionierung (vor dem Sharding)

Die PostgreSQL-Tabellenpartitionierung teilt große Tabellen in kleinere physische Tabellen auf und behält dabei eine einzige logische Tabelle bei:

-- Partition orders by month
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    organization_id UUID NOT NULL,
    created_at TIMESTAMP NOT NULL,
    total DECIMAL(10,2)
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2026_01 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE orders_2026_02 PARTITION OF orders
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

CREATE TABLE orders_2026_03 PARTITION OF orders
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

Die Partitionierung verbessert die Abfrageleistung für Zeitbereichsabfragen bei großen Tabellen um das 10- bis 100-fache, da PostgreSQL nur relevante Partitionen scannt.

Staubsaugen und Wartung

-- Check table bloat
SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  round(n_dead_tup::numeric / greatest(n_live_tup, 1) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

Konfigurieren Sie Autovacuum aggressiv für Tabellen mit hohem Schreibzugriff:

ALTER TABLE orders SET (
  autovacuum_vacuum_threshold = 100,
  autovacuum_vacuum_scale_factor = 0.05,
  autovacuum_analyze_threshold = 50,
  autovacuum_analyze_scale_factor = 0.02
);

---

Datenbankleistung überwachen

Verfolgen Sie diese Kennzahlen, um zu verstehen, wann und wie eine Skalierung erfolgen sollte:

Eine Cache-Trefferquote unter 95 % ist der stärkste Indikator dafür, dass Sie mehr Speicher benötigen. Das Erhöhen von shared_buffers und effective_cache_size ist oft günstiger und schneller als das Hinzufügen von Read Replicas.

Abfrageleistungsverfolgung

-- Enable pg_stat_statements (postgresql.conf)
-- shared_preload_libraries = 'pg_stat_statements'

-- Find the top 10 most time-consuming queries
SELECT
  queryid,
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  rows,
  query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Überprüfen Sie wöchentlich die zehn häufigsten Suchanfragen. Durch die Optimierung auch nur einer einzelnen, häufig ausgeführten Abfrage kann die Gesamtlast der Datenbank um 10–30 % reduziert werden.

---

Häufig gestellte Fragen

Woher wissen wir, wann es Zeit für eine Skalierung ist?

Überwachen Sie drei Metriken: Abfragelatenz P95 (Warnung bei 500 ms), Verbindungsauslastung (Warnung bei 80 %) und CPU-Auslastung (Warnung bei 70 % dauerhaft). Wenn Sie diese Schwellenwerte regelmäßig erreichen, gehen Sie zum nächsten Schritt auf der Skalierungsleiter über. Führen Sie keine Voroptimierung durch – skalieren Sie, wenn die Daten es erfordern.

Replikate lesen oder zwischenspeichern – was zuerst?

Beginnen Sie mit dem Caching. Redis-Caching ist einfacher zu implementieren, eliminiert mehr Last (Cache-Treffer überspringen die Datenbank vollständig) und kostet weniger. Fügen Sie Lesereplikate hinzu, wenn Ihre Cache-Trefferquote bereits über 80 % liegt, die Primärdatenbank jedoch immer noch durch Cache-Fehler und Schreibvorgänge unter Druck steht.

Wie funktioniert die Datenbankskalierung mit Odoo?

Odoo verwendet ausschließlich PostgreSQL. Beginnen Sie mit der Abfrageoptimierung (Odoo generiert komplexe Abfragen für die Berichterstellung). Fügen Sie PgBouncer für Verbindungspooling hinzu, wenn Sie mehr als 50 gleichzeitige Benutzer haben. Verwenden Sie Lesereplikate für Berichtsabfragen (konfigurieren Sie die Option --db-replica von Odoo). ECOSIRE bietet Odoo-Leistungsoptimierung einschließlich Datenbankoptimierung.

Ist eine verwaltete Datenbank (RDS/Cloud SQL) den Aufpreis wert?

Ja, für die meisten Unternehmen. Verwaltete Datenbanken übernehmen automatisierte Backups, Patches, Failover und Überwachung. Der Kostenaufschlag von 30–40 % gegenüber selbstverwaltetem PostgreSQL wird durch die eingesparte Entwicklungszeit ausgeglichen. Die Ausnahme bilden groß angelegte Bereitstellungen, bei denen der Kostenaufschlag für eine große Instanz die Kosten eines Teilzeit-DBA übersteigt.

---

Was als nächstes kommt

Die Datenbankskalierung ist eine Komponente einer umfassenderen Infrastrukturskalierungsstrategie. Kombinieren Sie es mit CDN-Optimierung für statische Assets, Kubernetes-Autoskalierung für Anwendungs-Pods und Lasttests, um Ihre Skalierungsentscheidungen unter realistischen Bedingungen zu validieren.

Kontaktieren Sie ECOSIRE für Beratung zur Datenbankoptimierung oder sehen Sie sich unseren DevOps-Leitfaden für die vollständige Infrastruktur-Roadmap an.

---

Herausgegeben von ECOSIRE – hilft Unternehmen dabei, ihre Dateninfrastruktur sicher zu skalieren.