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

Support reusing a training result across multiple vector index writers

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

I maintainer di solito rispondono entro 2 giorni

@wangzhigang1999 ci sta già lavorando.

Dal 2/9/2026.

  • #87 di @wangzhigang1999 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, cpp, java, python, rust
Ambito
api, data-engineering, search

Direzione di ricerca

Inizia tracciando VectorIndexTrainer::train, il punto di ingresso proposto training.create_writer() e il percorso from_trained esistente di IVF-PQ tra tutti i tipi di indice supportati. Poi esamina l’API unificata e i relativi binding C, C++, Java/JNI e Python. Il lavoro è completo quando writer indipendenti riutilizzano un unico risultato di training completato, mantenendo i payload vuoti, le API consumer esistenti e il formato attuale su disco.

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

Descrizione

Motivation

Callers that build one vector index file per segment currently need a separate training pass for every writer. The trained centroids, quantizers, and rotations can often be shared when those segments come from the same table or data distribution, but the unified API consumes VectorIndexTraining when it creates a writer.

For N segments, this makes the lifecycle effectively:

train -> writer 1
train -> writer 2
...
train -> writer N

IVF-PQ already has an internal from_trained path, but this capability is not available through the unified API or consistently across the supported index types and language bindings.

Proposed API

Allow a completed training result to create multiple independent writers:

let training = VectorIndexTrainer::train(config, training_vectors, training_count)?;
let first = training.create_writer();
let second = training.create_writer();

Each writer should start with the same trained model and an empty vector/ID payload. The existing consuming APIs should remain unchanged for one-shot callers.

Equivalent opt-in entry points should be exposed through C, C++, Java/JNI, and Python.

Expected benefit

In a release-mode synthetic build with 128-dimensional vectors, 8,192 training rows, and eight segments of 2,048 vectors each, training once reduced writer preparation time by 84-87% across IVF-Flat, IVF-SQ, IVF-PQ, IVF-RQ, and DiskANN. Including vector insertion and serialization, elapsed time fell by 73-84%.

The benefit comes from reducing N training passes to one; it does not change the index algorithms themselves.

Compatibility and scope

  • No default behavior change: callers opt in to reusable training explicitly.
  • Existing consuming APIs remain available.
  • No on-disk format change.
  • No cross-process training-model serialization or index merging in this issue.
Lingua principale
Rust
Stelle
25
Fork
24
Merge medio
2g 4h
PR unite (30g)
11

Preparare l'ambiente

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 apache/paimon-vector-index

Tutte le issue di apache/paimon-vector-index

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.