Benchmark

Kapazität, in harten Zahlen

Gemessen, nicht hochgerechnet: 10.000 Sensoren, jeder meldet einmal pro Minute, auf einem einzigen Server. Der Benchmark wird mit dem Produkt ausgeliefert — jede Zahl unten lässt sich auf Ihrer eigenen Hardware reproduzieren.

Die Maschine hinter jeder Zahl auf dieser Seite: ein Intel Core i9-14900KF (24 Kerne), 64 GB RAM und NVMe-SSDs unter Windows 11, PostgreSQL in Docker — Datenbank, Backend-Dienste und Benchmark-Client alle auf diesem einen Server. Kein Cluster, kein separater Datenbank-Host, nichts über die Standard-Container-Konfiguration hinaus getunt.

Aufnehmen

Bevor etwas geschrieben wird, muss es ankommen. Gemessen auf demselben Server mit dem Live-Ingestion-Benchmark, der mit dem Produkt ausgeliefert wird: 10.000 Sensoren, jeder meldet zehnmal pro Sekunde — 12 Millionen Messwerte pro Lauf — durch die echten MQTT-, Kafka- und HTTP-Dienste in den gemeinsamen Puffer und weiter in den Speicher, jeder Lauf Messwert für Messwert gegen das Gesendete geprüft. Jeder Transport nimmt Messwerte gebündelt an (ein JSON-Array von Messwerten pro Nachricht oder die ingest-batch-Route über HTTP), und diese Form entscheidet über die Zahl: eine Flotte von 10.000 Sensoren bei 10 Hz sind 100.000 Messwerte pro Sekunde, und eine einzelne Ingestion-Instanz nimmt sie mit Reserve auf.

Gateways senden Bündel	~430.000 Messwerte/s	Eine Ingestion-Instanz, ein Puffer-Knoten. Ein Gateway, das pro Nachricht eine Sekunde Messwerte seiner Sensoren abschickt — 12 Millionen Messwerte in unter 30 Sekunden aufgenommen, keiner verloren
Viele Sensoren pro Nachricht, je ein Messwert	~120.000 Messwerte/s	Die natürliche Form eines abfragenden Gateways — weiterhin eine Instanz, ein Puffer-Knoten
Ein Messwert pro Nachricht	~80.000 Messwerte/s	Geräte, die beim Messen sofort senden, über Kafka — die Grenze eines einzelnen Puffer-Knotens; der Puffer ist dafür gebaut, sich über mehrere zu verteilen
Verlorene Messwerte über alle Läufe	0	Anzahlen, Summen und stichprobenartig geprüfte Minuten stimmten exakt mit dem Generator überein — im Puffer und danach in der Datenbank

Schreiben

Messwerte pro Monat	432.000.000	10.000 Sensoren × ein Messwert pro Minute, volle Dichte
Anhaltender Schreibdurchsatz	~134.000 Messwerte/s	Der produktive Speicherpfad, über Stunden flach — keine Verschlechterung, während Historie sich ansammelt
Langzeitspeicher pro Monat	≈5,3 GiB	Historie in voller Auflösung, zum Monatsschluss komprimiert
Ein Jahr Historie	≈64 GiB	Das Wachstum ist linear — ein Jahr vorauszuplanen ist Multiplikation
Arbeitsbereich, laufender Monat	≈12 GiB	Abgeschlossene Tage werden im Hintergrund verdichtet — der Arbeitsbereich bleibt ein paar Tage tief, statt den ganzen Monat zu wachsen

Zurücklesen

Die andere Hälfte der Geschichte: wie schnell die Messwerte wieder herauskommen. Gleiche Flotte, derselbe einzelne Server, gemessen gegen die echte Abfrage-API des Produkts, jede Antwort vollständig heruntergeladen — 3,4 Millionen Anfragen, kein einziger Fehler.

Live-Werte auf dem Bildschirm	~57.000 Anfragen/s	Jede Anfrage holt die neuesten Werte von zehn Sensoren — über eine halbe Million Live-Werte pro Sekunde, typische Antwort in 8 ms
Ein Sensor, ein Tag, als Diagramm	~1.390 Diagramme/s	Ein Tag Historie in Minutenauflösung antwortet in ~47 ms — auch im Monat, der noch geschrieben wird
Ein Monat über fünf Sensoren	~350 Diagramme/s	Ein Punkt je Sensor und Tag, vorberechnet beim Verdichten jedes Tages — der laufende Monat antwortet in ~46 ms
Ein Monat je Sensor zusammengefasst	~4.200 Zusammenfassungen/s	Minimum, Maximum, Mittelwert und Anzahl über einen abgeschlossenen Monat, typisch in ~15 ms zurück
Fehler im gesamten Durchlauf	0	3.406.032 Anfragen mit bis zu 512 parallelen Clients — jede Antwort vollständig

Durchhalten

Geschwindigkeit für eine Minute ist das eine; die Frage eines Skeptikers ist, wie lange es so weitergeht und ob dabei etwas verloren geht. Also lief derselbe Server drei Stunden am Stück: 10.000 Sensoren, die zehnmal pro Sekunde melden, plus 2.000 weitere über MQTT und HTTP — rund 102.000 Messwerte pro Sekunde, gleichmäßig — während eine ausgelastete Konsole ihm die ganze Zeit Fragen stellte. Danach wurde jeder Sensor Minute für Minute zurückgelesen und mit dem verglichen, was gesendet worden war.

Messwerte in drei Stunden gesendet	1.101.600.000	Keiner scheiterte beim Senden; die Produzenten fielen nie zurück
Messwerte exakt zurückgelesen	1.101.600.000	Jeder der 12.000 Sensoren, jede Minute, Anzahl und Summe identisch mit dem Gesendeten
Konsolenanfragen währenddessen	1.241.199 · 0 Fehler	Live-Werte, Diagramme und Einblicke-Fragen, ~115 pro Sekunde; typische Antwort 3 ms für Live-Werte, 13 ms für ein Diagramm — in der letzten Stunde wie in der ersten
Speicher nach drei Stunden	derselbe wie nach fünf Minuten	In keinem der drei Dienste ist etwas gewachsen

In diesen drei Stunden wurde der gerade geschriebene Tag zehnmal unter dem laufenden Datenstrom in seine Langzeitform verdichtet — ohne dass dabei ein einziger Messwert verloren ging.

Direktvergleich: TimescaleDB — gleiche Maschine, gleiche Daten, gleiche Fragen

Ein zweiter Benchmark, für diese Seite gefahren: 2.000 Sensoren × 30 Tage Minuten-Aggregate — 86,4 Millionen Zeilen mit identischen Werten —, eingespielt in die Engine von LandauOne und in TimescaleDB (aktuell, PostgreSQL 17, Kompression aktiv, segmentiert je Sensor), jeweils über den eigenen Produktionspfad: LandauOnes deduplizierendes Upsert gegen TimescaleDBs binäres COPY. Dieselbe Maschine wie oben, beide Datenbanken in Docker mit Standardkonfiguration, der Client im selben Prozess auf demselben Host, HTTP auf beiden Seiten ausgeklammert. Bevor irgendetwas gemessen wurde, mussten beide Systeme auf dieselben Fragen identische Antworten liefern — sie taten es, auf die Ziffer genau. Der Harness liegt im Repository (CompareBench); jede Zeile unten ist reproduzierbar.

Einspielen, 86,4 Mio. Zeilen	127.000 Zeilen/s	TimescaleDB: 1.290.000 Zeilen/s — TimescaleDB 915 % schneller (10×). Rohes COPY gegen ein Upsert, das beim Landen dedupliziert.
Monat versiegeln (Falten vs. Komprimieren)	2 min 57 s	TimescaleDB: 41 s — TimescaleDB 331 % schneller. LandauOnes Versiegelung berechnet dabei auch jede Zusammenfassung und jedes Perzentil unten vor.
Speicher, versiegelter Monat	1,11 GiB	TimescaleDB: 1,43 GiB — LandauOne 22 % kleiner, Zusammenfassungen inklusive.
Monatsdurchschnitt, ein Sensor	0,8 ms	TimescaleDB: 2,9 ms — LandauOne 276 % schneller
Stundenintervalle über einen Monat (720 Punkte), ein Sensor	21,2 ms	TimescaleDB: 5,0 ms — TimescaleDB 325 % schneller. LandauOne zahlt einen festen Preis, um den ganzen Monatswürfel zu öffnen; Timescale liest das Segment eines Sensors.
Tagesintervalle über einen Monat (30 Punkte), ein Sensor	21,0 ms	TimescaleDB: 4,1 ms — TimescaleDB 418 % schneller, aus demselben Grund.
Monats-P95 (gewichtet), ein Sensor	0,8 ms	TimescaleDB: 30,0 ms — LandauOne 3.706 % schneller (37×). Beim Versiegeln vorberechnet gegen beim Lesen sortiert.
P95 je Tag über einen Monat (30 Punkte), ein Sensor	35,0 ms	TimescaleDB: 49,1 ms — LandauOne 40 % schneller
Monatsdurchschnitt, 100 Sensoren	64,8 ms	TimescaleDB: 65,5 ms — gleichauf (100 einzelne Zusammenfassungs-Lesezugriffe gegen einen gruppierten Scan)
Monats-P95, 100 Sensoren	53,1 ms	TimescaleDB: 5,53 s — LandauOne 10.330 % schneller (104×). Der Abstand, der mit der Flotte wächst.

Was die Zahlen bedeuten — und was sie kosten

Wo LandauOne vorn liegt

Historische Statistiken werden beim Verdichten jedes Tages und Monats vorberechnet: Der Durchschnitt, der Median oder das P95 eines Monats ist ein Zeilen-Lesezugriff statt eines Scans — 276 % schneller beim Durchschnitt, 37× beim einzelnen P95, 104× bei den P95 von hundert Sensoren, und der Abstand wächst mit der Historie, weil eine zusammengefasste Antwort nicht teurer wird, je mehr Daten hinter ihr liegen. Derselbe Monat braucht 22 % weniger Platte, Zusammenfassungen inklusive, und Perzentile, Spitzen-Hüllkurven, Abdeckung und Zähler-Deltas kommen als Produktfunktionen — im Diagramm, im Alarm, im Bericht, in der E-Mail — nicht als SQL, das Sie schreiben und pflegen.

Wo TimescaleDB vorn liegt

TimescaleDB ist eine Allzweck-Datenbank, und diese Allgemeinheit ist real: beliebiges SQL über Ihre Rohzeilen, Joins gegen eigene Tabellen, Zeitstempel unterhalb der Minute und ein großes Ökosystem. Das Masseneinspielen ist rund 10× schneller (ein rohes COPY gegen LandauOnes deduplizierendes Upsert), der Kompressionslauf 4× flotter als LandauOnes reichere Versiegelung, und Ein-Sensor-Intervalldiagramme über einen versiegelten Monat kommen 4–5× früher zurück. LandauOne tauscht diese Allgemeinheit bewusst ein: Seine Abfrageoberfläche ist seine API — die Aggregationen dieser Seite, ab Minutenauflösung —, und der Statistik-Satz ist auf das festgelegt, was die Versiegelung vorberechnet. Sind Ihre Fragen offenes SQL, ist Timescale das richtige Werkzeug; sind es die Fragen, die ein Betriebsteam Sensoren tatsächlich stellt, antwortet diese Engine schneller, von weniger Platte, mit der Konsole inklusive.

Gegen die übliche Alternative

LandauOne gegen TimescaleDB + Grafana

Der direkte Vergleich oben stellt Engines gegenüber. Der Vergleich, den Menschen tatsächlich anstellen, ist der mit dem Stack, den sie sonst zusammenbauen würden — eine Zeitreihendatenbank plus ein Dashboard-Werkzeug. Hier ist er, in aller Deutlichkeit.

Was Timescale + Grafana Ihnen gibt

Eine sehr gute Datenbank und ein sehr gutes Diagrammwerkzeug. Alles zwischen Broker und Diagramm bauen und betreiben Sie selbst: die Consumer für MQTT, Kafka, Service Bus und Event Hubs, die Feldzuordnung je Produzent, Zeitstempelprüfung, Duplikatunterdrückung, Verlustzählung, Aufbewahrung, die Alarmregeln, Anmeldung und Besitz je Nutzer, Freigabe, das Register dessen, was melden sollte, Berichte und deren Versand, ein Audit-Protokoll — und das SQL hinter jeder Statistik, geschrieben, geprüft und gepflegt von Ihrem Team.

Was LandauOne Ihnen gibt

Das ganze Produkt: die Eingangstür für diese Broker mit Prüfung, Deduplizierung und gezählten Verlusten; den Speicher mit seinen vorberechneten Statistiken; und die Konsole — sechzehn Module von Dashboards, Karten, Grundrissen und Live-Kameras bis zu Alarmen, Sensorzustand, Berichten, Audit, Speicher und den beiden Ingestion-Monitoren. Die Statistiken, deren Reihung auf der anderen Seite 37× und 104× länger dauerte, sind hier ein Zeilenlesen, und sie kommen als Funktionen an: gezeichnet, alarmiert, berichtet, versandt und in Einblicke befragt.

Wo die andere Seite vorn liegt

Freies SQL über Rohzeilen, Joins gegen Ihre eigenen Tabellen, wörtlich gehaltene Zeitstempel unterhalb der Minute, ein 10× schnellerer Massenimport und ein großes Ökosystem an Plug-ins. Sind Ihre Fragen Ad-hoc-SQL, bauen Sie den Stack. Sind es die Fragen, die ein Betriebsteam Sensoren jeden Tag stellt, beantwortet LandauOne sie schneller, von weniger Platte, ohne etwas zusammenzubauen.

Was Sie nicht zusammenbauen

Aufnahme, Prüfung, Deduplizierung, Aufbewahrung, Alarme, Anmeldung, Freigabe, Berichte, Audit, offline funktionierende Karten, Kamerazugriff hinter Anmeldung und die Monitore, die sagen, was angekommen ist — auf der anderen Seite jeweils ein eigenes Projekt, hier jeweils schon da und gemessen.