Schritt 1: Zugriffsmuster vor der Technik festhalten
Schreibe zuerst auf, welche Abfragen die Anwendung stellt, wie oft und mit welchem Schlüssel. Erst danach ist die Auswahl eine technische Frage.
-- PostgreSQL: die teuersten Abfragen sichtbar machen
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT calls,
round(mean_exec_time::numeric, 2) AS ms_mittel,
rows,
left(query, 80) AS abfrage
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;
-- Verhältnis von Lesen zu Schreiben je Tabelle
SELECT relname, seq_scan, idx_scan, n_tup_ins, n_tup_upd, n_tup_del
FROM pg_stat_user_tables
ORDER BY seq_scan + idx_scan DESC
LIMIT 20;Wer bereits eine Datenbank betreibt, muss das Zugriffsmuster nicht schaetzen. Diese beiden Abfragen liefern die Grundlage der Entscheidung: welche Abfragen die Last erzeugen, wie viele Zeilen sie liefern und ob eine Tabelle ueberwiegend gelesen oder geschrieben wird. Bei einer Neuentwicklung ersetzt eine schriftliche Liste der geplanten Abfragen diesen Schritt.
Zugriffsmuster und passender Dienst
| Muster | Passt | Passt nicht |
|---|---|---|
| Viele verschiedene Abfragen, Verknüpfungen, Berichte | Amazon RDS oder Aurora, Azure SQL-Datenbank, Azure Database for PostgreSQL | DynamoDB, weil jede neue Abfrage einen weiteren Index braucht |
| Bekannter Schlüssel, sehr hohe Zugriffszahl, feste Muster | Amazon DynamoDB, Azure Cosmos DB | Eine einzelne große relationale Instanz, die vertikal wachsen muss |
| Dokumente mit wechselndem Aufbau, weltweite Verteilung | Azure Cosmos DB, Amazon DocumentDB | Data Warehouse, das auf Massenauswertung ausgelegt ist |
| Auswertungen über Millionen Zeilen mit Aggregation | Amazon Redshift, Azure Synapse oder Microsoft Fabric | Transaktionsdatenbank, die dabei den Tagesbetrieb ausbremst |
| Zeitreihen aus Sensoren, Metriken und Protokollen | Amazon Timestream, Azure Data Explorer | Klassische Tabelle mit Zeitstempelindex und wachsendem Index |