Usar WoodpeckerCompatible with Milvus 2.6.x

Esta guía explica cómo habilitar y utilizar Woodpecker como el registro de escritura en cabeza (WAL) en Milvus 2.6.x. Woodpecker es un WAL nativo de la nube diseñado para el almacenamiento de objetos, que ofrece un alto rendimiento, baja sobrecarga operativa y escalabilidad sin fisuras. Para obtener detalles sobre la arquitectura y las pruebas comparativas, consulte Woodpecker.

Visión general

• A partir de Milvus 2.6, Woodpecker es un WAL opcional que proporciona escrituras ordenadas y recuperación como servicio de registro.
• Como opción de cola de mensajes, se comporta de forma similar a Pulsar/Kafka y puede habilitarse a través de la configuración.
• Soporta dos backends de almacenamiento: sistema de archivos local (local) y almacenamiento de objetos (minio/S3-compatible).

Inicio rápido

Para habilitar Woodpecker, establezca el tipo de MQ en Woodpecker:

mq:
  type: woodpecker

Nota: El cambio de mq.type para un clúster en ejecución es una operación de actualización. Siga cuidadosamente el procedimiento de actualización y valídelo en un clúster nuevo antes de cambiar a producción.

Configuración

A continuación se muestra el bloque de configuración completo de Woodpecker (edite milvus.yaml o anule en user.yaml):

# Related configuration of woodpecker, used to manage Milvus logs of recent mutation operations, output streaming log, and provide embedded log sequential read and write.
woodpecker:
  meta:
    type: etcd # The Type of the metadata provider. currently only support etcd.
    prefix: woodpecker # The Prefix of the metadata provider. default is woodpecker.
  client:
    segmentAppend:
      queueSize: 10000 # The size of the queue for pending messages to be sent of each log.
      maxRetries: 3 # Maximum number of retries for segment append operations.
    segmentRollingPolicy:
      maxSize: 256M # Maximum size of a segment.
      maxInterval: 10m # Maximum interval between two segments, default is 10 minutes.
      maxBlocks: 1000 # Maximum number of blocks in a segment
    auditor:
      maxInterval: 10s # Maximum interval between two auditing operations, default is 10 seconds.
  logstore:
    segmentSyncPolicy:
      maxInterval: 200ms # Maximum interval between two sync operations, default is 200 milliseconds.
      maxIntervalForLocalStorage: 10ms # Maximum interval between two sync operations local storage backend, default is 10 milliseconds.
      maxBytes: 256M # Maximum size of write buffer in bytes.
      maxEntries: 10000 # Maximum entries number of write buffer.
      maxFlushRetries: 5 # Maximum size of write buffer in bytes.
      retryInterval: 1000ms # Maximum interval between two retries. default is 1000 milliseconds.
      maxFlushSize: 2M # Maximum size of a fragment in bytes to flush.
      maxFlushThreads: 32 # Maximum number of threads to flush data
    segmentCompactionPolicy:
      maxSize: 2M # The maximum size of the merged files.
      maxParallelUploads: 4 # The maximum number of parallel upload threads for compaction.
      maxParallelReads: 8 # The maximum number of parallel read threads for compaction.
    segmentReadPolicy:
      maxBatchSize: 16M # Maximum size of a batch in bytes.
      maxFetchThreads: 32 # Maximum number of threads to fetch data.
  storage:
    type: minio # The Type of the storage provider. Valid values: [minio, local]
    rootPath: /var/lib/milvus/woodpecker # The root path of the storage provider.

Notas clave:

• woodpecker.meta
  • Tipo: Actualmente sólo se soporta etcd. Reutiliza el mismo etcd que Milvus para almacenar metadatos ligeros.
  • prefijo: El prefijo de la clave para los metadatos. Por defecto: woodpecker.
• woodpecker.client
  • Controla el comportamiento de anexión/rodamiento/auditoría de segmentos en el lado del cliente para equilibrar el rendimiento y la latencia de extremo a extremo.
• woodpecker.logstore
  • Controla las políticas de sincronización/descarga/compactación/lectura para los segmentos de registro. Estos son los controles principales para el ajuste de rendimiento/latencia.
• woodpecker.storage
  • type: minio para almacenamiento de objetos compatible con MinIO/S3 (MinIO/S3/GCS/OSS, etc.); local para sistemas de archivos locales/compartidos.
  • rootPath: Ruta raíz para el backend de almacenamiento (efectiva para local; con minio, las rutas vienen dictadas por bucket/prefix).

Modos de despliegue

Milvus soporta los modos Standalone y Cluster. Matriz de soporte del backend de almacenamiento Woodpecker:

	storage.type=local	storage.type=minio
Milvus Independiente	Soportado	Soportado
Milvus Cluster	Limitado (necesita FS compartido)	Compatible

Notas:

• Con minio, Woodpecker comparte el mismo almacenamiento de objetos con Milvus (MinIO/S3/GCS/OSS, etc.).
• Con local, un disco local de nodo único sólo es adecuado para Standalone. Si todos los pods pueden acceder a un sistema de archivos compartido (por ejemplo, NFS), el modo Cluster también puede utilizar local.

Guías de despliegue

Habilitar Woodpecker para un Cluster Milvus en Kubernetes (Milvus Operator, storage=minio)

Después de instalar el Operador Milvus, inicie un cluster Milvus con Woodpecker habilitado utilizando la muestra oficial:

kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_woodpecker.yaml

Esta muestra configura Woodpecker como la cola de mensajes y habilita el Nodo de Streaming. El primer arranque puede tardar en extraer imágenes; espere hasta que todos los pods estén listos:

kubectl get pods
kubectl get milvus my-release -o yaml | grep -A2 status

Cuando estén listos, debería ver pods similares a:

NAME                                               READY   STATUS    RESTARTS   AGE
my-release-etcd-0                                  1/1     Running   0          17m
my-release-etcd-1                                  1/1     Running   0          17m
my-release-etcd-2                                  1/1     Running   0          17m
my-release-milvus-datanode-7f8f88499d-kc66r        1/1     Running   0          16m
my-release-milvus-mixcoord-7cd7998d-x59kg          1/1     Running   0          16m
my-release-milvus-proxy-5b56cf8446-pbnjm           1/1     Running   0          16m
my-release-milvus-querynode-0-558d9cdd57-sgbfx     1/1     Running   0          16m
my-release-milvus-streamingnode-58fbfdfdd8-vtxfd   1/1     Running   0          16m
my-release-minio-0                                 1/1     Running   0          17m
my-release-minio-1                                 1/1     Running   0          17m
my-release-minio-2                                 1/1     Running   0          17m
my-release-minio-3                                 1/1     Running   0          17m

Ejecute el siguiente comando para desinstalar el cluster Milvus.

kubectl delete milvus my-release

Si necesita ajustar los parámetros de Woodpecker, siga la configuración descrita en message storage config.

Habilitar Woodpecker para un cluster Milvus en Kubernetes (Helm Chart, storage=minio)

Primero agregue y actualice el gráfico Helm de Milvus como se describe en Ejecutar Milvus en Kubernetes con Helm.

Luego despliegue con uno de los siguientes ejemplos:

- Despliegue en clúster (configuración recomendada con Woodpecker y Streaming Node habilitados):

helm install my-release zilliztech/milvus \
  --set image.all.tag=v2.6.0 \
  --set pulsarv3.enabled=false \
  --set woodpecker.enabled=true \
  --set streaming.enabled=true \
  --set indexNode.enabled=false

- Despliegue autónomo (Woodpecker habilitado):

helm install my-release zilliztech/milvus \
  --set image.all.tag=v2.6.0 \
  --set cluster.enabled=false \
  --set pulsarv3.enabled=false \
  --set standalone.messageQueue=woodpecker \
  --set woodpecker.enabled=true \
  --set streaming.enabled=true

Después del despliegue, siga la documentación para redirigir puertos y conectarse. Para ajustar los parámetros de Woodpecker, siga los ajustes descritos en la configuración del almacenamiento de mensajes.

Habilitar Woodpecker para Milvus Standalone en Docker (storage=local)

Siga Ejecutar Milvus en Docker. Ejemplo:

mkdir milvus-wp && cd milvus-wp
curl -sfL https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh -o standalone_embed.sh

# Create user.yaml to enable Woodpecker with local filesystem
cat > user.yaml <<'EOF'
mq:
  type: woodpecker
woodpecker:
  storage:
    type: local
    rootPath: /var/lib/milvus/woodpecker
EOF

bash standalone_embed.sh start

Para cambiar aún más la configuración de Woodpecker, actualice user.yaml y ejecute bash standalone_embed.sh restart.

Habilitar Woodpecker para Milvus Standalone con Docker Compose (storage=minio)

Siga Ejecutar Milvus con Docker Compose. Ejemplo:

mkdir milvus-wp-compose && cd milvus-wp-compose
wget https://github.com/milvus-io/milvus/releases/download/v2.6.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
# By default, the Docker Compose standalone uses Woodpecker
sudo docker compose up -d
# If you need to change Woodpecker parameters further, write an override:
docker exec -it milvus-standalone bash -lc 'cat > /milvus/configs/user.yaml <<EOF
mq:
  type: woodpecker
woodpecker:
  logstore:
    segmentSyncPolicy: 
      maxFlushThreads: 16
  storage:
    type: minio
EOF'

# Restart the container to apply the changes
docker restart milvus-standalone

Consejos para ajustar el rendimiento

Basándose en los puntos de referencia y los límites del backend en Woodpecker, optimice el rendimiento de escritura de extremo a extremo desde los siguientes aspectos:

• Lado de almacenamiento
  • Almacenamiento de objetos (compatible con minio/S3): Aumente la concurrencia y el tamaño de los objetos (evite los objetos diminutos). Vigile los límites de ancho de banda de la red y de los buckets. Un único nodo MinIO en SSD suele tener un límite de 100 MB/s a nivel local; un único EC2 a S3 puede alcanzar los GB/s.
  • Sistemas de archivos locales/compartidos (local): Prefiera NVMe/discos rápidos. Asegúrese de que el sistema de archivos gestiona bien las escrituras pequeñas y la latencia de fsync.
• Controles Woodpecker
  • Aumente logstore.segmentSyncPolicy.maxFlushSize y maxFlushThreads para descargas más grandes y mayor paralelismo.
  • Ajusta maxInterval según las características del medio (intercambia latencia por rendimiento con una agregación más larga).
  • Para el almacenamiento de objetos, considere aumentar segmentRollingPolicy.maxSize para reducir los cambios de segmento.
• Lado cliente/aplicación
  • Utilizar lotes de mayor tamaño y más escritores/clientes simultáneos.
  • Controle los tiempos de refresco y creación de índices (acumule los lotes antes de activarlos) para evitar pequeñas escrituras frecuentes.

Demostración de inserción por lotes

from pymilvus import MilvusClient
import random

# 1. Set up a Milvus client
client = MilvusClient(
    uri="http://<Proxy Pod IP>:27017",
)

# 2. Create a collection
res = client.create_collection(
    collection_name="test_milvus_wp",
    dimension=512,
    metric_type="IP",
    shards_num=2,
)
print(res)

# 3. Insert randomly generated vectors
colors = ["green", "blue", "yellow", "red", "black", "white", "purple", "pink", "orange", "brown", "grey"]
data = []

batch_size = 1000
batch_count = 2000
for j in range(batch_count):
    start_time = time.time()
    print(f"Inserting {j}th vectors {j * batch_size} startTime{start_time}")
    for i in range(batch_size):
        current_color = random.choice(colors)
        data.append({
            "id": (j*batch_size + i),
            "vector": [ random.uniform(-1, 1) for _ in range(512) ],
            "color": current_color,
            "color_tag": f"{current_color}_{str(random.randint(1000, 9999))}"
        })
    res = client.insert(
        collection_name="test_milvus_wp",
        data=data
    )
    data = []
    print(f"Inserted {j}th vectors endTime:{time.time()} costTime:{time.time() - start_time}")

Latencia

Woodpecker es una WAL nativa de la nube diseñada para el almacenamiento de objetos con compensaciones entre rendimiento, coste y latencia. El modo integrado ligero actualmente soportado prioriza la optimización del coste y el rendimiento, ya que la mayoría de los escenarios sólo requieren que los datos se escriban en un tiempo determinado en lugar de exigir una baja latencia para las solicitudes de escritura individuales. Por lo tanto, Woodpecker emplea escrituras por lotes, con intervalos predeterminados de 10 ms para backends de almacenamiento de sistemas de archivos locales y 200 ms para backends de almacenamiento tipo MinIO. Durante las operaciones de escritura lentas, la latencia máxima es igual al tiempo de intervalo más el tiempo de descarga.

Tenga en cuenta que la inserción de lotes se activa no sólo por los intervalos de tiempo, sino también por el tamaño del lote, que por defecto es de 2 MB.

Para obtener más información sobre la arquitectura, los modos de implementación (MemoryBuffer / QuorumBuffer) y el rendimiento, consulte Arquitectura de Woodpecker.

Para más detalles sobre los parámetros, consulte el repositorio GitHub de Woodpecker.