docs(snapshot): sync workspace documentation
This commit is contained in:
204
3700x.md
Normal file
204
3700x.md
Normal file
@@ -0,0 +1,204 @@
|
||||
# 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`
|
||||
Reference in New Issue
Block a user