Ihre Daten. Ihre Regeln. Ihre Datenbank.
Wenn die Optimierung bestehender Datenbanken nicht mehr genügt, entwerfen wir eine spezialisierte Engine für Ihren Workload und Ihre Hardware. Was gemessen wird, vereinbaren wir vor der Entwicklung. Unsere öffentliche Orderbook-Engine zeigt unseren Ansatz.
Eine Antwort, wenn Optimierung ihre Grenzen erreicht hat. Nicht die Standardantwort.
Eine universelle Engine trägt Aufwand mit sich, den Sie nicht benötigen: Schichten für andere Workloads und Funktionen, die Sie nie aufrufen. Ohne diese Schichten lässt sich die Antwortzeit in Mikrosekunden messen, weil auf dem Anfrageweg kaum noch etwas übrig bleibt.
Datenstrukturen für ein konkretes Zugriffsmuster benötigen weniger Rechenleistung, Speicher und Netzwerkverkehr für dasselbe Ergebnis. Die Ersparnis zeigt sich in Hardware, die Sie nicht mehr betreiben müssen. Sie steht im Benchmark, bevor Sie sich festlegen.
Schema, Indexstrategie und Netzwerkprotokoll folgen Ihrem Datenmodell und der Maschine, auf der es läuft. Nichts ist nur deshalb Teil der Engine, weil ein anderer Kunde es gebraucht hat.
Eine Datenbank-Engine für Level-2-Orderbuchdaten, in C++20 für einen Workload auf konkreter Hardware entwickelt. Auf GitHub können Sie sie klonen, den Aufbau der Speicherschicht lesen, die Testsuite ausführen und auf Ihrer eigenen Maschine messen. So sieht eine fertige maßgeschneiderte Engine aus. Ihr Projekt würde demselben Prozess folgen.
Ergebnisse hängen von Hardware und Workload ab. Der öffentliche Vergleich dokumentiert Methode und Grenzen; er ist keine Leistungsgarantie für Ihre Anwendung.
Quellcode der Engine ansehen (öffnet sich in einem neuen Tab)Benchmark-Methoden und Ergebnisse lesen(öffnet sich in einem neuen Tab)
Der Name unserer Engine macht eine Aussage über Kosten. Deshalb messen wir sie: die Server-CPU-Zeit, die jedes System zum Laden derselben 2.000.000 Orderbuch-Ebenen benötigt.
| Datenbank | Eingelesene Orderbuch-Ebenen pro Server-CPU-Sekunde |
|---|---|
| Orderbook DB Engine | 4,88 bis 5,00 Millionen |
| ClickHouse 26.9 | 1,64 bis 2,25 Millionen |
| TimescaleDB 2.30 | 0,63 Millionen |
Das 2,1-Fache des ClickHouse-Werts und das 7,7-Fache des TimescaleDB-Werts: unser langsamster Lauf im Vergleich zum jeweils schnellsten. Weniger CPU-Sekunden für dieselben Daten bedeuten weniger Server und weniger Energie.
Amazon EC2 m8a.xlarge (4 vCPU, AMD EPYC 9R45), 7. Oktober 2026, fünf Läufe, ClickHouse und TimescaleDB auf PostgreSQL 16 nativ installiert. ClickHouse beendet das Laden zuerst und nutzt dabei 2,4 bis 3,0 Kerne gegenüber 0,1 bei unserer Engine. Verglichen wird hier der Ressourcenaufwand des Ladens.
Methoden und vollständiger Vergleich(öffnet sich in einem neuen Tab)
Zwei Aufzeichnungen von Binance-Orderbüchern: ein Änderungsstrom und Top-20-Snapshots. Zehn Handelspaare über dieselben zehn Minuten, in jedes System geladen und nach dessen eigener Komprimierung auf dem Datenträger gemessen.
| Datenbank | Diffs, B/Zeile | Top 20, B/Zeile |
|---|---|---|
| Orderbook DB Engine | 3,78 | 0,53 |
| ClickHouse 26.9, Standard | 7,04 | 1,17 |
| ClickHouse 26.9, bestes von fünf Codec-Sets | 4,31 | 0,87 |
| TimescaleDB 2.30, komprimiert | 17,29 | 12,45 |
Was in der ClickHouse-Standardinstallation ein Terabyte belegt, benötigt in unserer Engine 0,46 bis 0,54 Terabyte. Mit dem besten von uns je Aufzeichnung gefundenen Codec-Set sind es 0,61 bis 0,88 des ClickHouse-Bedarfs. Eine neue Cluster-Replik und ein Backup kopieren die Segmente so, wie sie auf dem Datenträger liegen; sie übertragen also ebenfalls diese Bytes.
Amazon EC2 m8a.xlarge, 7. Oktober 2026: Jede Aufzeichnung wurde geladen und auf den Datenträger geschrieben; vor der Messung warteten wir 90 Sekunden. Das beste Codec-Set ist das kleinste der fünf je Aufzeichnung getesteten Sets.
Methoden und alle Datensätze(öffnet sich in einem neuen Tab)
Sechs Situationen, in denen Optimierung nicht mehr hilft. Wenn Smart Data Engine feststellt, dass keine Standard-Engine passt, ist es einer dieser Fälle.
Ihre Abfragen sind zu langsam. Indizes sind optimiert, Caches ergänzt und die Hardware erweitert. Trotzdem stoßen Sie an Grenzen, die universelle Datenbanken nicht überwinden.
Ihre Infrastrukturkosten steigen weiter. Sie bezahlen für ungenutzte Funktionen und Aufwand, der Ihrem Workload nicht hilft.
Was mit einer Million Datensätzen funktionierte, funktioniert nicht mit einer Milliarde. Ihre Datenbank wurde nicht für die inzwischen erreichte Größenordnung entwickelt.
Sie haben PostgreSQL, MongoDB, Redis und ClickHouse ausprobiert. Jede Lösung löst einen Teil des Problems, doch keine bildet Ihr konkretes Datenmodell passend ab.
Sie nutzen spezialisierte Infrastruktur: eigene SSDs, FPGAs oder bestimmte CPU-Architekturen, deren Potenzial Standarddatenbanken nicht vollständig ausschöpfen.
Ihre Dateninfrastruktur unterscheidet Sie vom Wettbewerb. Schnellere Abfragen, geringere Kosten und höhere Leistung verschaffen Ihnen einen Vorsprung.
Vier Phasen. Am Ende der zweiten erhalten Sie eine Kennzahl, an der Sie uns messen können.
Wir untersuchen mit Ihnen Datenstruktur, Volumen, Zugriffsmuster, Latenzziele und die vorgesehene Hardware. Ist eine maßgeschneiderte Engine nicht die richtige Antwort, erfahren Sie es in dieser Phase.
Datenstrukturen, Indexstrategie und Netzwerkprotokoll, alles auf Ihre Zugriffsmuster abgestimmt. Am Ende steht ein schriftlicher Benchmark: Was besser bedeutet, in Zahlen, anhand Ihrer Daten.
Die Implementierung wird kontinuierlich an diesem Benchmark gemessen, nicht erst am Ende. Nichts erreicht Ihre Produktion, bevor die vereinbarten Kennzahlen erfüllt sind.
Engine, Benchmarks, Testsuite und Dokumentation. Ihr Team übernimmt, oder wir betreiben die Lösung als Dienstleistung. Sie prüfen uns weiterhin am vereinbarten Benchmark.
Beschreiben Sie, was Sie versucht haben, welche Kosten entstanden sind und wo es nicht weiterging. Ist eine eigene Engine nicht die Antwort, wird das Gespräch kürzer und für Sie günstiger.
Projekt besprechen
