Perf: time-bound by-ID log lookups in ClickHouse (retry, retrieve event, retrieve attempt)

Aperta
  • Qualcosa non va?
#1,170 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
clickhouse, go
Ambito
backend, databases

Direzione di ricerca

Read Retry in internal/apirouter/retry_handlers.go and RetrieveEvent and RetrieveAttempt in internal/logstore/chlogstore/chlogstore.go; trace the ClickHouse queries and their existing tests. Compare an expanding time window with an optional time hint, since the issue leaves the approach and window sizing open. Done means lookups are time-bounded where possible, results and defaults stay unchanged, and the listed retry, event, and attempt paths are covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Lookups by ID in the ClickHouse log store run with no time range. The tables are sorted by time first, so the primary key can't narrow these queries and ClickHouse scans every part of the table. The cost grows with the amount of history stored.

Affected paths:

  • POST /retry: Retry in internal/apirouter/retry_handlers.go looks up the latest prior attempt by tenant, event_id and destination_id (limit 1) with no time filter. When no attempt is found it falls back to RetrieveEvent, also unbounded.
  • GET /events/:event_id and GET /attempts/:attempt_id: RetrieveEvent and RetrieveAttempt in internal/logstore/chlogstore/chlogstore.go filter on event_id = ? / attempt_id = ? only.

Results must stay the same and defaults unchanged. Ideas:

  1. Expanding window. Search a recent window first and widen until the row is found, up to the retention window (or without a limit when retention is unlimited). Open design point: how many steps and how wide. It depends on how much data a window holds, not only on retention length: a high-throughput deployment with short retention may still gain from a few steps, a low-volume one with long retention may not.
  2. Optional time hint. Let API callers pass the event time, or a lower bound, when they have it (operator events and alert payloads include it). Optional and backward-compatible; without it, 1 applies.

Open to other approaches.

Lingua principale
Go
Stelle
1.1k
Fork
70
Merge medio
3g 9h
PR unite (30g)
34

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hookdeck/outpost

Tutte le issue di hookdeck/outpost

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.