Twoje dane. Twoje zasady. Twoja baza danych.
Gdy tuning gotowych baz przestaje wystarczać, projektujemy silnik pod Twoje obciążenie i sprzęt. Przed budową uzgadniamy, co będziemy mierzyć. Publiczny silnik orderbookowy pokazuje nasze podejście do tej pracy.
To odpowiedź na moment, w którym tuning nie ma już czego poprawiać. Nie jest to odpowiedź domyślna.
Silnik general-purpose niesie narzut, o który nigdy nie prosiłeś: warstwy pod workloady, których nie masz, i funkcje, których nigdy nie wywołasz. Wyjmij je, a czas odpowiedzi liczy się w mikrosekundach, bo w ścieżce prawie nic nie zostaje.
Struktury danych zbudowane pod jeden wzorzec dostępu oznaczają mniej obliczeń, mniej storage’u i mniejszy ruch sieciowy przy tym samym wyniku. Oszczędność widać jako sprzęt, którego nie wstawiasz do szafy, i siedzi w benchmarku, zanim się do czegokolwiek zobowiążesz.
Schemat, strategia indeksów i protokół wire idą za Twoim modelem danych i za maszyną, na której to chodzi. Nic w tym silniku nie istnieje dlatego, że potrzebował tego inny klient.
Silnik bazodanowy do danych Level 2 order booka, napisany w C++20 pod jeden workload i konkretny sprzęt. Jest na GitHubie: sklonuj, przeczytaj, jak ułożona jest warstwa storage, odpal testy, zmierz na własnej maszynie. Tak wygląda skończony silnik na zamówienie i taki sam proces przeszedłby Twój projekt.
Wyniki zależą od sprzętu i obciążenia. Publiczne porównanie opisuje metodykę i ograniczenia pomiarów. Nie jest gwarancją wydajności Twojej aplikacji.
Przeczytaj źródło silnika (otwiera w nowej karcie)Przeczytaj metodykę i wyniki pomiarów(otwiera w nowej karcie)
Nazwa naszego silnika obiecuje niski koszt, więc mierzymy koszt: czas CPU serwera, który każdy system zużywa na zapis tych samych 2 000 000 poziomów księgi zleceń.
| Baza danych | Poziomy księgi zapisane na sekundę CPU serwera |
|---|---|
| Orderbook DB Engine | od 4,88 do 5,00 mln |
| ClickHouse 26.9 | od 1,64 do 2,25 mln |
| TimescaleDB 2.30 | 0,63 mln |
2,1 razy tyle co ClickHouse i 7,7 razy tyle co TimescaleDB, nasz najwolniejszy przebieg wobec najszybszego każdego z nich: mniej sekund CPU na te same dane to mniej serwerów i mniej energii.
Amazon EC2 m8a.xlarge (4 vCPU, AMD EPYC 9R45), 7 października 2026, pięć przebiegów, ClickHouse i TimescaleDB na PostgreSQL 16 zainstalowane natywnie. ClickHouse kończy zapis pierwszy, bo używa od 2,4 do 3,0 rdzenia, gdy nasz silnik 0,1; tu porównujemy koszt zapisu.
Dwa nagrania ksiąg zleceń z Binance, dziesięć par z tych samych dziesięciu minut, wgrane do każdego systemu i zmierzone na dysku po jego własnej kompresji.
| Baza danych | Strumień zmian, bajty na wiersz | Migawki top 20, bajty na wiersz |
|---|---|---|
| Orderbook DB Engine | 3,78 | 0,53 |
| ClickHouse 26.9 po instalacji | 7,04 | 1,17 |
| ClickHouse 26.9, najlepszy z pięciu zestawów kodeków | 4,31 | 0,87 |
| TimescaleDB 2.30 po kompresji | 17,29 | 12,45 |
To, co w ClickHouse po instalacji zajmuje terabajt, u nas zajmuje od 0,46 do 0,54 terabajta, a od 0,61 do 0,88 tego, czego ClickHouse potrzebuje z najlepszym zestawem kodeków znalezionym dla każdego nagrania. Replika dołączająca do klastra i kopia zapasowa kopiują segmenty tak, jak leżą na dysku, więc przenoszą te same bajty.
Amazon EC2 m8a.xlarge, 7 października 2026: każde nagranie wgrane, zrzucone na dysk i zostawione na 90 sekund przed pomiarem. Najlepszy zestaw kodeków to najmniejszy z pięciu, które sprawdziliśmy dla każdego nagrania.
Sześć sytuacji, w których tuning przestaje pomagać. Jeśli rozmieszczenie ze Smart Data Engine skończyło się na „nic gotowego nie pasuje", to była jedna z nich.
Zapytania są za wolne. Dostroiłeś indeksy, dodałeś cache, dołożyłeś sprzętu, a nadal walisz w ścianę, przez którą baza general-purpose nie przejdzie.
Rachunek za infrastrukturę rośnie z miesiąca na miesiąc. Płacisz za funkcje, których nie używasz, i za narzut, który nie robi nic dla Twojego workloadu.
To, co działało przy milionie rekordów, nie działa przy miliardzie. Twoja baza nie była projektowana na skalę, do której doszedłeś.
Próbowałeś PostgreSQL, MongoDB, Redisa, ClickHouse. Każdy rozwiązuje część problemu, żaden nie obsługuje Twojego modelu danych tak, jak trzeba.
Pracujesz na wyspecjalizowanej infrastrukturze: własne SSD, FPGA albo konkretna architektura CPU, której gotowa baza nie wykorzysta w pełni.
Infrastruktura danych jest u Ciebie elementem przewagi, nie kosztem. Szybsze zapytania na mniejszym sprzęcie to coś, czego konkurencja nie skopiuje jednym zakupem.
Cztery etapy, a pod koniec drugiego dostajesz liczbę, przy której nas rozliczasz.
Badamy Twoje dane razem z Tobą: strukturę, wolumeny, wzorce dostępu, cele latencji i sprzęt, na którym to ma stać. Jeśli własny silnik jest złą odpowiedzią, słyszysz to na tym etapie.
Struktury danych, strategia indeksów i protokół wire, wszystko wybrane pod Twoje wzorce dostępu. Etap kończy się zapisanym benchmarkiem: co znaczy lepiej, w liczbach, na Twoich danych.
Implementowane i mierzone przy tym benchmarku na bieżąco, a nie na końcu. Nic nie trafia na Twoją produkcję, dopóki liczby nie są spełnione.
Silnik, benchmarki, testy i dokumentacja. Twój zespół przejmuje to dalej albo my utrzymujemy to jako usługę zarządzaną, a Ty dalej sprawdzasz nas przy benchmarku.
Powiedz, co próbowałeś, ile to kosztowało i gdzie się zatrzymało. Jeśli własny silnik nie jest odpowiedzią, to będzie krótsza rozmowa i tańsza dla Ciebie.
Rozpocznij projekt
