OLTP vs. OLAP
Transaktionale und analytische Datenbanken
OLTP vs. OLAP ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was sind OLTP und OLAP?
Datenbanken sind nicht für alle Anwendungsfälle gleichermaßen geeignet. Zwei grundlegend unterschiedliche Workloads haben geprägt, wie wir Datenbanken entwerfen und betreiben: OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing).
Für alle, die professionell mit Daten arbeiten, ist es entscheidend, den Unterschied zu verstehen. Die richtige Wahl zwischen OLTP und OLAP bestimmt die Abfragegeschwindigkeit, die Speicherkosten und die Gesamtarchitektur Ihres Datensystems.
OLTP: Für Transaktionen entwickelt
OLTP-Systeme verarbeiten eine große Anzahl kurzer, schneller Vorgänge – Einfügungen, Aktualisierungen und Löschvorgänge, die Geschäftsvorfälle in Echtzeit abbilden. Beispiele sind das Aufgeben einer Bestellung, die Verarbeitung einer Zahlung oder die Aktualisierung eines Kundendatensatzes.
Die wichtigsten Eigenschaften von OLTP sind eine geringe Latenz pro Vorgang, hohe Nebenläufigkeit und starke Konsistenz. Jede Transaktion muss ACID-konform sein, um die Datenintegrität zu schützen.
-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);
-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;OLAP: Für Analysen entwickelt
OLAP-Systeme sind für komplexe Abfragen optimiert, die große Mengen historischer Daten durchsuchen, um Trends, Muster und Zusammenfassungen sichtbar zu machen. Business-Analysten und Data Scientists verwenden OLAP, um Fragen wie diese zu beantworten: „Wie hoch war unser Gesamtumsatz pro Region im letzten Quartal?“
OLAP-Abfragen aggregieren häufig Millionen von Zeilen und umfassen mehrere Joins über Fakt- und Dimensionstabellen. Die Geschwindigkeit einzelner Schreibvorgänge ist zweitrangig; entscheidend sind der Lesedurchsatz und die Flexibilität der Abfragen.
-- OLAP example: total sales by region for Q1 2024
SELECT
d.region,
SUM(f.sales_amount) AS total_sales,
COUNT(f.order_id) AS order_count
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
JOIN dim_store d ON f.store_key = d.store_key
WHERE dd.year = 2024
AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;Die beiden Systeme im direkten Vergleich
Am einfachsten merken Sie sich den Unterschied, wenn Sie betrachten, wer welches System verwendet und wie:
- OLTP: Wird von Anwendungs-Backends verwendet; Tausende gleichzeitiger Benutzer; jede Abfrage greift auf wenige Zeilen zu.
- OLAP: Wird von Analysten und Reporting-Tools verwendet; weniger gleichzeitige Abfragen, von denen jede Millionen von Zeilen durchsucht.
Diese gegensätzlichen Zugriffsmuster führen zu sehr unterschiedlichen Schemadesigns, Indexierungsstrategien und sogar Hardwareentscheidungen.
-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;
-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;Schemadesign: Normalisiert vs. denormalisiert
OLTP-Datenbanken bevorzugen normalisierte Schemata (3NF oder höher), um Redundanzen zu vermeiden und Schreibvorgänge effizient zu machen. Jede Entität befindet sich in einer eigenen Tabelle, wodurch die pro Transaktion verarbeitete Datenmenge reduziert wird.
OLAP-Datenbanken bevorzugen denormalisierte Schemata – insbesondere Star- und Snowflake-Schemata –, bei denen Daten vorab verknüpft und redundant gespeichert werden. Dadurch entfallen teure Joins zur Abfragezeit, und spaltenorientierte Speicher-Engines können Daten schneller durchsuchen.
-- Normalized OLTP design (3NF)
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(150) UNIQUE
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE,
total NUMERIC(10,2)
);
-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
customer_key INT,
date_key INT,
product_key INT,
region VARCHAR(50),
category VARCHAR(50),
amount NUMERIC(12,2)
);Indexierungsstrategien unterscheiden sich
OLTP-Systeme setzen stark auf B-Tree-Indizes für Primär- und Fremdschlüssel, um schnelle Suchen einzelner Zeilen und effiziente Joins innerhalb einer Transaktion zu ermöglichen.
OLAP-Systeme profitieren von Bitmap-Indizes, spaltenorientierter Speicherung und Partitionierung. Das Durchsuchen einer gesamten Spalte (z. B. aller Verkaufsbeträge) ist wesentlich effizienter, wenn die Daten spaltenweise statt zeilenweise gespeichert werden.
-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
ON orders (customer_id);
-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
ON orders (order_date, customer_id);
-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
PARTITION OF fact_sales
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');Nebenläufigkeit und Sperren
OLTP-Systeme müssen Tausende gleichzeitiger Schreibvorgänge ohne Konflikte verarbeiten. Datenbanken verwenden Zeilensperren und MVCC (Multi-Version Concurrency Control), sodass Leser niemals Schreiber blockieren und umgekehrt.
OLAP-Abfragen sind überwiegend schreibgeschützt. Sperren sind nur selten ein Problem, aber lang laufende Scans können erhebliche CPU- und I/O-Ressourcen verbrauchen. Die meisten Data Warehouses führen OLAP in einem separaten System aus, das durch Batch-ETL oder CDC (Change Data Capture) aus der OLTP-Quelle befüllt wird.
-- OLTP: explicit transaction with row-level lock
BEGIN;
SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;
UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;
COMMIT;ETL: Verbindung zwischen OLTP und OLAP
Da OLTP und OLAP inkompatible Designs haben, führen Organisationen ETL (Extract, Transform, Load)-Pipelines aus, um Daten planmäßig (nächtlich, stündlich oder nahezu in Echtzeit) aus der Transaktionsdatenbank in das analytische Data Warehouse zu kopieren und dort neu zu strukturieren.
Der ETL-Prozess wandelt normalisierte OLTP-Zeilen in denormalisierte Fakten- und Dimensionsdatensätze um und wendet dabei Geschäftslogik an (z. B. Währungsumrechnung oder Kundensegmentierung).
-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
customer_key,
date_key,
product_key,
amount
)
SELECT
dc.customer_key,
dd.date_key,
dp.product_key,
o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date dd ON dd.calendar_date = o.order_date
JOIN dim_product dp ON dp.source_product_id = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);Typische OLAP-Abfragemuster
OLAP-Abfragen umfassen fast immer Aggregationen (SUM, COUNT, AVG), Gruppierungen über mehrere Dimensionen und eine Filterung nach Datumsbereichen oder Kategorien. Diese Elemente bilden die Grundlage von Dashboards und Geschäftsberichten.
Fensterfunktionen sind bei OLAP-Workloads besonders leistungsfähig: Sie ermöglichen den Vergleich der Werte jeder Periode mit denen der vorherigen Periode, ohne einen Self-Join zu benötigen.
-- Year-over-year revenue comparison using a window function
SELECT
dd.year,
dd.quarter,
SUM(f.amount) AS revenue,
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year) AS prev_year_revenue,
ROUND(
100.0 * (SUM(f.amount) -
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year))
/ NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year), 0)
, 2) AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;HTAP: Verwischte Grenzen
Moderne Systeme wie TiDB, SingleStore und PostgreSQL + spaltenbasierte Erweiterungen implementieren HTAP (Hybrid Transactional/Analytical Processing). Sie sollen beide Workloads in einer einzigen Engine verarbeiten und dadurch die betriebliche Komplexität vermeiden, die durch die Pflege getrennter OLTP- und OLAP-Systeme entsteht.
HTAP erreicht dies, indem Daten gleichzeitig in zwei Formaten gespeichert werden: in einem zeilenorientierten Speicher für transaktionale Schreibvorgänge und in einem spaltenorientierten Speicher für analytische Lesevorgänge. Beide werden automatisch synchron gehalten.
-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
date_key INT,
product_key INT,
region VARCHAR(50),
amount NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');
-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;Das richtige System auswählen
Die Entscheidung zwischen OLTP und OLAP (oder HTAP) hängt von Ihrem hauptsächlichen Workload ab:
- Wenn Sie eine Anwendung entwickeln, die Ereignisse in Echtzeit erfasst – verwenden Sie eine OLTP-Datenbank (PostgreSQL, MySQL, SQL Server).
- Wenn Sie eine Berichtsebene für historische Daten entwickeln – verwenden Sie ein OLAP-Warehouse (BigQuery, Redshift, Snowflake, ClickHouse).
- Wenn Sie beides benötigen und einen einfacheren Betrieb wünschen – prüfen Sie HTAP-Optionen.
Viele Produktionsarchitekturen verwenden beides: eine OLTP-Datenbank als führendes System und ein separates Data Warehouse für Analysen, verbunden durch eine ETL-Pipeline.
-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
relname AS table_name,
seq_scan,
idx_scan,
n_live_tup AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;Wissenscheck
Testen Sie Ihr Verständnis der wichtigsten Unterschiede zwischen OLTP- und OLAP-Systemen.
Zusammenfassung der Lektion
OLTP vs. OLAP – wichtigste Erkenntnisse:
- OLTP verarbeitet transaktionale Workloads in Echtzeit: schnelle, nebenläufige Schreibvorgänge auf Zeilenebene mit ACID-Garantien.
- OLAP verarbeitet analytische Workloads: komplexe Aggregationen über große historische Datensätze mithilfe denormalisierter Schemata.
- Das Schemadesign richtet sich nach dem Workload – normalisiert (3NF) für OLTP, Star- oder Snowflake-Schema für OLAP.
- ETL-Pipelines verbinden die beiden Systeme, indem sie transformierte OLTP-Daten in das analytische Data Warehouse laden.
- HTAP-Systeme versuchen, beide Workloads mithilfe einer dualen zeilen- und spaltenorientierten Speicherung in einer einzigen Engine zu bedienen.
Wenn Sie die richtige Architektur von Anfang an wählen, vermeiden Sie später aufwendige Migrationen und stellen sicher, dass Ihre Abfragen mit der von Ihren Benutzern erwarteten Geschwindigkeit ausgeführt werden.
Häufig gestellte Fragen
Ist die Lektion „OLTP vs. OLAP“ kostenlos?
Ja — der vollständige Text von „OLTP vs. OLAP“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „OLTP vs. OLAP“?
Transaktionale und analytische Datenbanken Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um SQL Academy zu starten?
Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „OLTP vs. OLAP“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?
Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- OLTP vs. OLAP
- Fakten- und Dimensionstabellen
- Stern- und Schneeflockenschemata
- Analytische Abfragen schreiben