Warum VesselAPI von MongoDB zu TimescaleDB wechselte und was wir lernten

Am 1. Januar 2023 um 14:27 Uhr sendete ein Containerschiff vor der Küste von Singapur seine Position an die Welt. Innerhalb der nächsten 60 Sekunden folgten 699.999 weitere Meldungen – jede mit Kurs, Geschwindigkeit und Identifikationsnummer. Diese Flut an Daten, bekannt als AIS-Signale (Automatic Identification System), bildet das Rückgrat der globalen Schifffahrtsüberwachung. Doch während die Schiffe ihre Positionsdaten unaufhörlich in den Äther senden, muss irgendwo eine Datenbank diese Informationen nicht nur speichern, sondern auch in Echtzeit analysierbar machen.

Genau hier lag das Problem für das Team von VesselAPI. Ein Jahr lang betrieb das Unternehmen seine maritime Datenplattform auf MongoDB. Flexibel, schnell entwickelt – doch als die Anforderungen an Skalierbarkeit und räumliche Abfragen stiegen, wurde klar: Eine Dokumentendatenbank war nicht die richtige Wahl für raumzeitliche Daten. Die Lösung? Ein Wechsel zu TimescaleDB. Doch der Umstieg war mehr als nur ein Datenbank-Upgrade. Es war eine grundlegende Neugestaltung der Datenarchitektur.

AIS-Daten: Nicht nur Dokumente, sondern Messwerte

Auf den ersten Blick wirken AIS-Nachrichten wie klassische Dokumente: Jede Meldung enthält Felder wie Schiff-ID, Position, Geschwindigkeit und Kurs. MongoDBs Schemafreiheit ermöglichte es VesselAPI, schnell Prototypen zu bauen und das Datenmodell täglich anzupassen. Doch der Schein trog. Denn im Kern sind AIS-Daten keine Dokumente, sondern Messwerte mit zwei kritischen Eigenschaften: Zeit und Raum.

Die typischen Fragen an maritime Datenbanken zielen genau auf diese Dimensionen ab:

• Wo befand sich Schiff X vor zwei Stunden?
• Welche Schiffe passierten die Straße von Gibraltar seit Mitternacht?
• Gibt es Containerfrachter innerhalb von 50 Kilometern vor Hamburg?

MongoDB jedoch behandelt Zeitstempel und Koordinaten wie jedes andere Feld. Zwar lassen sich mit zusätzlichen Indizes räumliche Abfragen umsetzen, doch die Performanz leidet unter der wachsenden Datenmenge. Bei einer Spitzenlast von 700.000 Einträgen pro Stunde wurde das System langsam – und teuer. Die Datenbank kämpfte mit der inhärenten Struktur der Information.

Die Suche nach der passenden Datenbank-Architektur

Die Anforderungen an eine maritime Datenplattform sind komplex:

• Hohe Schreib- und Leseperformance für Zeitreihendaten
• Automatische Partitionierung nach Zeitintervallen
• Effiziente Kompression älterer Daten
• Räumliche Abfragen auf einer Kugeloberfläche (z.B. „50 km Umkreis von Rotterdam“)
• Retentionsrichtlinien ohne manuellen Cron-Job-Betrieb
• Relationale Joins für komplexe Analysen
• Geringer Betriebsaufwand ohne dedizierten Datenbankadministrator

Die Liste erinnerte an das klassische Problem: Entweder drei spezialisierte Datenbanken, die über APIs verknüpft werden müssen, oder eine einzige Lösung, die alle Anforderungen erfüllt. Die Evaluation führte schnell zu TimescaleDB – einer PostgreSQL-Erweiterung, die Zeitreihendaten nativ unterstützt.

Hypertables, Kompression und die Magie der Chunks

Der Kern von TimescaleDBs Stärke liegt in Hypertables. Aus Anwendersicht handelt es sich um eine gewöhnliche PostgreSQL-Tabelle. Doch im Hintergrund partitioniert die Datenbank die Einträge automatisch in Chunks – zeitlich zusammenhängende Blöcke, die als separate physische Tabellen gespeichert werden.

Für VesselAPIs vessel_positions-Hypertable bedeutet das: Jede Stunde AIS-Daten wird in einem eigenen Chunk abgelegt. Eine Retentionsrichtlinie von 78 Stunden löscht nicht Millionen von Zeilen einzeln, sondern entfernt einfach die ältesten Chunks. Der Vorgang dauert Millisekunden, unabhängig von der Datenmenge.

ALTER TABLE vessel_positions SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'mmsi',
  timescaledb.compress_orderby = 'timestamp DESC'
);

SELECT add_compression_policy('vessel_positions', INTERVAL '2 hours');

Die Kompression folgt demselben Prinzip. Nach zwei Stunden werden die Chunks automatisch verdichtet – segmentiert nach Schiffs-ID (MMSI) und sortiert nach neuesten Einträgen. Das hat zwei entscheidende Vorteile:

• Speicherersparnis: Ältere Daten benötigen bis zu 90 % weniger Speicherplatz.
• Abfrageperformance: Zeitbereichsabfragen müssen nicht die gesamte Tabelle scannen, sondern springen direkt zu den relevanten Chunks.

Hexagone, Geodaten und die Grenzen klassischer Indizes

Doch TimescaleDB kann mehr als nur Zeitreihen. Dank der Integration von PostGIS (für räumliche Abfragen) und H3 (für hexagonale Gitter) lassen sich komplexe geoanalytische Anfragen effizient umsetzen.

Beispielsweise die Frage: „Welche Schiffe befanden sich im letzten Monat in einem hexagonale Gitterzelle mit dem Zentrum bei Rotterdam?“. H3 unterteilt die Erdoberfläche in hexagonale Zellen mit definierter Kantenlänge. Eine solche Abfrage wäre in MongoDB mit Standardindizes kaum performant umsetzbar – in TimescaleDB hingegen nutzt die Datenbank die hexagonale Struktur direkt für optimierte Suchen.

Der stille Bug: Ein falsches Struct-Tag und die Folgen

Der Wechsel zu TimescaleDB brachte nicht nur technische Vorteile, sondern auch unerwartete Herausforderungen. Ein kleiner, aber folgenreicher Fehler zeigte, wie tiefgreifend die Architekturunterschiede sind.

In der MongoDB-Implementierung nutzte VesselAPI struct-Tags, um bestimmte Felder bei der Serialisierung zu ignorieren. Ein Tag wurde versehentlich auf „omitempty“ gesetzt – ein Standardwert, der bei leeren Feldern die Serialisierung unterdrückt. In MongoDB blieb das zunächst unbemerkt. Doch in TimescaleDB, wo die Daten direkt in Tabellenzeilen umgewandelt werden, führte dies zu sporadischen Datenverlusten. Ein Schiff, dessen Position plötzlich nicht mehr gespeichert wurde, weil ein Feld als „leer“ interpretiert wurde.

Der Fehler wurde erst nach Tagen durch manuelle Datenprüfungen auffällig. Die Lehre: Selbst scheinbar harmlose Metadaten können in einer neuen Datenbankarchitektur fatale Auswirkungen haben.

Fazit: Eine Datenbank, die mitwächst

Der Wechsel von MongoDB zu TimescaleDB war für VesselAPI ein Game-Changer. Die Plattform verarbeitet heute problemlos Hunderttausende von Positionsmeldungen pro Stunde – und das mit einer Infrastruktur, die sich selbst verwaltet. Retention, Kompression und räumliche Abfragen laufen ohne manuellen Eingriff. Die Datenbank wächst mit den Anforderungen, statt sie zu bremsen.

Doch der größte Vorteil liegt in der Flexibilität. Mit TimescaleDB lassen sich zukünftige Anwendungsfälle wie maschinelles Lernen auf Schiffsrouten oder Echtzeit-Kollisionswarnungen einfacher umsetzen. Die maritime Datenwelt bleibt ein Datenstrom, der nie versiegt – doch jetzt hat sie endlich eine Datenbank, die mithalten kann.