205 lines
4.0 KiB
Markdown
205 lines
4.0 KiB
Markdown
# 3700X jako drugi bare metal dla Drift perps
|
|
|
|
Ten dokument opisuje sensowną rolę drugiego hosta:
|
|
|
|
- `AMD Ryzen 7 3700X`
|
|
- `128 GB RAM`
|
|
- `2 x 1 TB NVMe`
|
|
- `1 Gbps`
|
|
|
|
W tym układzie zakładamy, że:
|
|
|
|
- host `9950X` robi tylko `Agave + Yellowstone Geyser`,
|
|
- host `3700X` robi `consumer + processing + lekka/umiarkowana baza`,
|
|
- komunikacja między hostami idzie po prywatnej sieci (`private VLAN` albo później `wg0`).
|
|
|
|
## Cel
|
|
|
|
Rozdzielić role:
|
|
|
|
- `9950X`: ingest danych z Solany, bez ciężkiej obróbki
|
|
- `3700X`: odbiór streamu, dekodowanie Drift, budowa DLOB, zapis pochodnych danych, API i worker-y
|
|
|
|
To zmniejsza ryzyko, że:
|
|
|
|
- baza danych,
|
|
- parser,
|
|
- albo batch/worker
|
|
|
|
zwiększą lag walidatora.
|
|
|
|
## Co uruchamiać na 3700X
|
|
|
|
Tak:
|
|
|
|
- Yellowstone gRPC consumer
|
|
- parser Drift
|
|
- cache stanu w RAM
|
|
- worker-y realtime
|
|
- Redis / NATS / lekka kolejka
|
|
- Postgres o umiarkowanej skali
|
|
- read-only API / query layer
|
|
- monitoring
|
|
|
|
Nie:
|
|
|
|
- `agave-validator`
|
|
- ciężkie historyczne archiwum raw streamu
|
|
- duży ClickHouse na start
|
|
- wszystko naraz bez limitów retencji
|
|
|
|
## Układ usług
|
|
|
|
Przepływ:
|
|
|
|
1. `9950X` uruchamia `Agave + Geyser plugin`
|
|
2. `3700X` łączy się po prywatnym adresie do `gRPC`
|
|
3. consumer odbiera tylko potrzebny scope Drift
|
|
4. parser buduje lokalny stan
|
|
5. do DB trafiają tylko dane pochodne i potrzebne eventy
|
|
|
|
Model:
|
|
|
|
- host A = producer
|
|
- host B = consumer + processing
|
|
|
|
## Dyski
|
|
|
|
Najprostszy podział:
|
|
|
|
- `nvme0`:
|
|
- system
|
|
- Docker
|
|
- binarki
|
|
- cache buildów
|
|
- `nvme1`:
|
|
- dane consumera
|
|
- Postgres
|
|
- logi aplikacyjne
|
|
- kolejki / spool
|
|
|
|
Filesystem:
|
|
|
|
- `ext4` na obu dyskach
|
|
|
|
## Minimalny scope Yellowstone pod Drift perps
|
|
|
|
Na start nie streamuj całej Solany. Dla Drift perps minimalny sensowny zakres to:
|
|
|
|
- `slots`
|
|
- `transactions` tylko dla programu Drift
|
|
- `accounts` dla kont Drift potrzebnych do stanu rynku i userów
|
|
|
|
## Konta i strumienie
|
|
|
|
Na start streamuj:
|
|
|
|
- `State`
|
|
- `PerpMarketAccount` dla wybranych rynków
|
|
- `SpotMarketAccount` potrzebne do collateral / quote
|
|
- `UserAccount`
|
|
|
|
Powód:
|
|
|
|
- Drift trzyma zlecenia i pozycje w `UserAccount`
|
|
- lokalny `DLOB` buduje się właśnie z `UserAccount`
|
|
- `PerpMarketAccount` daje stan rynku
|
|
- `SpotMarketAccount` jest potrzebny dla cross-margin
|
|
|
|
## Filtry v1
|
|
|
|
Najrozsądniejsza wersja startowa:
|
|
|
|
- `slots`: włączone
|
|
- `transactions`:
|
|
- `account_include = [Drift Program ID]`
|
|
- bez vote tx
|
|
- `accounts`:
|
|
- exact accounts dla `State` i marketów
|
|
- `UserAccount` dla programu Drift
|
|
|
|
Jeśli interesują Cię tylko wybrane rynki, np. `SOL-PERP`, `BTC-PERP`, `ETH-PERP`, to:
|
|
|
|
- odbierasz `UserAccount`,
|
|
- po dekodzie odrzucasz userów bez pozycji i bez orderów na tych rynkach
|
|
|
|
To jest bezpieczniejsze operacyjnie niż próba zbyt agresywnego filtrowania przed dekodem.
|
|
|
|
## Co liczyć po stronie consumera
|
|
|
|
W RAM trzymaj:
|
|
|
|
- cache `UserAccount`
|
|
- cache `PerpMarketAccount`
|
|
- cache `SpotMarketAccount`
|
|
- ostatni slot
|
|
|
|
Z tego licz:
|
|
|
|
- lokalny `DLOB`
|
|
- best bid / ask
|
|
- depth
|
|
- zmiany pozycji
|
|
- fills
|
|
- liquidations
|
|
- funding / mark / oracle impact
|
|
|
|
Do DB zapisuj:
|
|
|
|
- eventy biznesowe
|
|
- snapshoty pochodne
|
|
- agregaty
|
|
|
|
Nie zapisuj na start całego raw streamu 1:1.
|
|
|
|
## Co daje taki układ
|
|
|
|
- mniejszy wpływ processingu na lag walidatora
|
|
- bezpieczny transport po prywatnej sieci
|
|
- prostsza diagnostyka
|
|
- możliwość restartu parsera bez ruszania noda
|
|
- łatwiejsze skalowanie w przyszłości
|
|
|
|
## Ograniczenia 3700X
|
|
|
|
Ten host jest dobry jako:
|
|
|
|
- consumer node
|
|
- processing node
|
|
- umiarkowana DB
|
|
|
|
To nie jest idealny host pod:
|
|
|
|
- bardzo ciężki ClickHouse
|
|
- duże historyczne archiwum
|
|
- wiele ciężkich pipeline'ów naraz
|
|
|
|
Najbardziej ograniczą Cię:
|
|
|
|
- `1 Gbps`
|
|
- pojemność `2 x 1 TB`
|
|
- RAM przy większej retencji i większej liczbie workerów
|
|
|
|
## Rekomendacja startowa
|
|
|
|
Na `3700X` uruchom:
|
|
|
|
- Yellowstone consumer
|
|
- Drift parser
|
|
- Redis
|
|
- Postgres
|
|
- lekkie API
|
|
|
|
Na `9950X` zostaw tylko:
|
|
|
|
- `Agave`
|
|
- `Geyser`
|
|
|
|
Najpierw uruchom zakres dla 2-3 rynków perp i dopiero potem rozszerzaj.
|
|
|
|
## Powiązane dokumenty
|
|
|
|
- `doc/rpc/software-placement.md`
|
|
- `doc/rpc/geyser-dlob.md`
|
|
- `doc/dlob-services.md`
|