# DLOB Retention And Feature Store Plan

Status na `2026-03-29`.

Ten dokument zapisuje robocze ustalenia o:

- retencji danych DLOB na `mevnode_bot`
- ryzyku zajetosci dysku
- tym, co warto trzymac dlugo pod modele / "economic transformers"

## Aktualny stan operacyjny

### Dysk

- root `/` na `mevnode_bot`: `3.6T`
- zajete: ok. `471G`
- wolne: ok. `3.0T`
- biezace uzycie: ok. `14%`

Najwiekszy konsument miejsca:

- PostgreSQL / TimescaleDB na local volume poda `postgres-0`
- rozmiar bazy `crypto`: ok. `457 GB`

Najwieksze hypertable:

- `public.dlob_all_derived_ts`: ok. `260 GB`
- `public.dlob_hot_snapshot_ts`: ok. `177 GB`
- `public.dlob_hot_derived_ts`: ok. `19 GB`

Wniosek:

- miejsca nie brakuje teraz
- ale storage DLOB jest juz na tyle duzy, ze trzeba nim zarzadzac swiadomie

## Od kiedy sa dane

- `dlob_hot_snapshot_ts`: od `2026-03-17 00:23:36.013+00`
- `dlob_hot_derived_ts`: od `2026-03-17 00:23:36.013+00`
- `dlob_all_derived_ts`: od `2026-03-17 00:44:42.386+00`

## Aktualna retencja TimescaleDB

Na `2026-03-29` retencja jest juz ustawiona i joby sa `Success`.

- `dlob_hot_snapshot_ts`: `30 days`
- `dlob_all_derived_ts`: `30 days`
- `dlob_hot_derived_ts`: `180 days`
- legacy `dlob_stats_ts` / `dlob_depth_bps_ts` / `dlob_slippage_ts*`: `7 days`

Wazne doprecyzowanie:

- stare rekordy nie beda "nadpisywane"
- stare chunki beda usuwane przez polityki retencji

Praktycznie:

- tabele `30-day` zaczna byc realnie przycinane okolo `2026-04-16`
- `dlob_hot_derived_ts` zacznie byc realnie przycinane dopiero po osiagnieciu ok. `180 days`

## Czy trzeba juz robic ring buffer

Nie pilnie.

Lepsza kolejnosc:

1. Zostawic obecna retencje.
2. Sprawdzic po `2026-04-16`, czy `30-day` tabele rzeczywiscie zaczely sie wyplaszczac rozmiarowo.
3. Wlaczyc kompresje TimescaleDB dla duzych hypertabli.
4. Dopiero potem decydowac, czy potrzebny jest dodatkowy custom ring buffer.

Powod:

- miejsca jest duzo
- retencja juz istnieje
- najwiekszy zysk teraz da kompresja, nie customowa logika bufora

## Wazna obserwacja

Na `2026-03-29` kompresja TimescaleDB dla tabel `dlob_*` jest wylaczona:

- `public.dlob_all_derived_ts`: `compression_enabled = false`
- `public.dlob_hot_snapshot_ts`: `compression_enabled = false`
- `public.dlob_hot_derived_ts`: `compression_enabled = false`

To jest najprostszy kandydat na kolejny krok oszczedzania miejsca.

## Co warto trzymac dlugo dla modeli

Nie warto trzymac wszystkiego w raw snapshotach.

Do treningu modeli bardziej oplacalne jest trzymanie:

- stalych cech numerycznych
- etykiet future outcome
- kilku skal czasowych

Zamiast:

- pelnego `payload JSON`
- wszystkich poziomow `bids/asks` dla kazdego ticka
- duplikowania raw i derived w dlugim horyzoncie

## Rekomendowana piramida danych

### Warstwa 1. Short-term raw

Przechowywac krotko jako source of truth:

- `dlob_hot_snapshot_ts`
- `dlob_all_derived_ts`

Cel:

- debugging
- replay
- reprocessing
- walidacja feature engineering

### Warstwa 2. Feature bars

Z raw / derived budowac stale, numeryczne wektory cech:

- `1s` feature bars na `180d+`
- `5s` albo `15s` feature bars na `1y+`
- `1m` regime bars bardzo dlugo

To powinno byc glownym wejsciem do modeli.

### Warstwa 3. Labels

Osobno trzymac etykiety przyszlego wyniku:

- `fwd_ret_1s`
- `fwd_ret_5s`
- `fwd_ret_30s`
- `fwd_ret_5m`
- `max_up`
- `max_down`
- adverse selection
- fill probability proxy
- edge net of fees / funding / slippage

## Jakie cechy warto trzymac

### Mikrostruktura

- `mid`
- `microprice`
- `spread_bps`
- `mark - oracle`
- `mid - oracle`
- basis

### Plynnosc i ksiega

- `best_bid_size`
- `best_ask_size`
- imbalance
- depth w koszykach `1/2/5/10/20/50 bps`
- slope / curvature booka

### Aktywnosc i jakosc feedu

- liczba update'ow w bucketcie
- udział `indicative` vs normalnych snapshotow
- staleness feedu
- luki czasowe

### Statystyki krotkoterminowe

- realized vol `5s`
- realized vol `30s`
- realized vol `5m`
- momentum score
- mean reversion score
- spread capture proxy
- slippage dla stalych notionals

## Proponowane tabele docelowe

Minimalny zestaw:

- `dlob_features_1s`
- `dlob_features_5s`
- `dlob_regime_1m`
- `bot_labels_horizons`

Kazda z tych tabel powinna miec:

- `event_ts`
- `source`
- `market_type`
- `market_index`
- zestaw cech numerycznych
- opcjonalnie `meta`

To da:

- staly rozmiar rekordu
- tansze trenowanie
- latwiejsze sample / batch / join
- mniej miejsca niz raw JSON

## Dlaczego to jest lepsze od trzymania wszystkiego

Bo modele nie potrzebuja pelnego surowego payloadu do kazdego kroku.

Dla modeli wazniejsze sa:

- stabilne, stale-wymiarowe wejscia
- konsekwentne etykiety
- latwe agregowanie po oknach czasu

Raw trzeba trzymac krotko.
Feature store i labels trzeba trzymac dlugo.

## Rekomendacja na kolejny tydzien

1. Nie wdrazac jeszcze custom ring buffer.
2. Zweryfikowac po `2026-04-16`, czy `30-day` retencja rzeczywiscie przycina `hot_snapshot` i `all_derived`.
3. Przygotowac plan wlaczenia kompresji TimescaleDB dla:
   - `dlob_all_derived_ts`
   - `dlob_hot_snapshot_ts`
   - `dlob_hot_derived_ts`
4. Zaprojektowac schemat `dlob_features_1s`, `dlob_features_5s`, `dlob_regime_1m`, `bot_labels_horizons`.
5. Uznac raw DLOB za short-term storage, a feature bars + labels za long-term storage pod modele.

## Decyzja robocza

Obecny kierunek:

- retencja raw zostaje
- kompresja powinna byc kolejnym krokiem
- dlugoterminowo nie trzymac wszystkiego jako raw snapshots
- dla modeli przejsc na warstwy cech i etykiet o nizszej skali