Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support reusing a training result across multiple vector index writers

Abierto
  • ¿Algo no está bien?
#86 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@wangzhigang1999 ya está trabajando en esto.

Desde el 2/9/2026.

  • #87 de @wangzhigang1999 — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, cpp, java, python, rust
Área
api, data-engineering, search

Línea de trabajo

Comienza rastreando VectorIndexTrainer::train, el punto de entrada propuesto training.create_writer() y la ruta existente from_trained de IVF-PQ en todos los tipos de índice compatibles. Después, inspecciona la API unificada y sus bindings de C, C++, Java/JNI y Python. Se considera terminado cuando los writers independientes reutilicen un único resultado de entrenamiento completado, manteniendo los payloads vacíos, las APIs consumidoras existentes y el formato actual en disco.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
25
Forks
24
Merge medio
3 d 6 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/paimon-vector-index

Todos los issues de apache/paimon-vector-index

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.