Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Optimize node collection indexes

Aperta
  • Qualcosa non va?
#706 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
mongodb, python
Ambito
databases

Direzione di ricerca

Inizia con l’inventario degli indici di produzione e la query delle dimensioni nell’issue, quindi esamina Node.get_indexes() in kernelci-core/api/models.py. Verifica il conteggio dei campi id prima di eliminare id_1, rimuovi o nascondi gli indici specificati e controlla nuovamente $indexStats dopo il periodo di osservazione. Il lavoro è completato quando gli indici rimanenti sono gestiti dal codice e la riduzione pianificata dell’ingombro è verificata.

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

Descrizione

Background

The production node collection (35.6M docs) has 19 indexes totaling
~11.8 GB — 38% of all data on disk (storageSize 19 GB, indexSize
11.8 GB). Every node insert/update pays maintenance cost on all of them,
and they inflate physical backup size and restore time.

$indexStats from production (window: ~2 days since pod restart on
2026-07-06) shows roughly half of them unused.

Finding 1: no node indexes are managed by code

Node in kernelci-core does not implement get_indexes(), so
db.create_indexes() creates nothing for the node collection. All 18
non-_id indexes were created manually on the server with no record of
why. Whatever survives this cleanup should be added to
Node.get_indexes() (kernelci-core api/models.py) so the index set is
code-managed and reproducible.

Finding 2: redundant indexes — safe to drop now

  • data.kernel_revision.commit_1 (12k ops) — fully covered by the
    compound
    data.kernel_revision.commit_1_data.kernel_revision.branch_1_data.kernel_revision.tree_1
    (prefix rule). Drop the single, keep the compound.
  • created_1_updated_-1 (0 ops) — created_1 is its prefix and is
    in active use (likely the node purge job). Drop the compound, keep
    created_1.
  • id_1 (0 ops) — the API maps id ↔ _id; documents likely have
    no id field. Verify with
    db.node.countDocuments({id: {$exists: true}}) — if 0, drop.

Finding 3: zero-usage indexes — hide, observe, then drop

Zero ops in the sample window, but the window is too short to catch
weekly/monthly jobs. Hide them (planner stops using them, instantly
reversible with unhideIndex), observe 2–4 weeks, then drop what nobody
missed:

  • updated_1
  • treeid_1 (sparse)
  • owner_1
  • data.error_code_1
  • result_1
  • group_1
  • data.kernel_revision.branch_1
  • data.kernel_revision.tree_1
db.node.hideIndex("<name>")

Indexes confirmed in active use (keep)

_id_ (4.0M ops), parent_1 (2.3M), state_1 (712k), kind_1 (241k),
data.kernel_revision.commit_1_..._tree_1 compound,
processed_by_kcidb_bridge_1_updated_-1, name_1, created_1.

Expected impact

  • Estimated 2–4 GB reduction in index footprint (more after observation
    phase drops).
  • Reduced write amplification on every node insert/update.
  • Smaller physical backups and faster restores.

Plan

  1. Capture per-index sizes:
    db.node.aggregate([{$collStats: {storageStats: {}}}]) →
    indexSizes
  2. Drop data.kernel_revision.commit_1, created_1_updated_-1;
    verify and drop id_1
  3. Hide the 8 zero-usage indexes, re-check $indexStats after
    2–4 weeks
  4. Drop unused ones
  5. Add surviving indexes to Node.get_indexes() in kernelci-core

Issue written with help of Codex AI assistant

Lingua principale
Python
Stelle
10
Fork
21
Merge medio
22m
PR unite (30g)
1

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 kernelci/kernelci-api

Tutte le issue di kernelci/kernelci-api

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.