• Informazioni su Milvus
  • Iniziare
  • Concetti
  • Guida per l'utente
  • Importazione dei dati
  • Strumenti AI
  • Guida all'amministrazione
    • Distribuzione
    • Configurazione
    • Gestire le dipendenze
    • Scala
    • Aggiornamento
    • Monitoraggio, avvisi e registri
    • Gruppi di risorse
    • Sicurezza
    • Interruttore Tipo MQ
  • Strumenti
  • Integrazioni
  • Tutorial
  • Domande frequenti
  • API Reference

Utilizzare WoodpeckerCompatible with Milvus 2.6.x

Questa guida spiega come abilitare e utilizzare Woodpecker come Write-Ahead Log (WAL) in Milvus 2.6.x. Woodpecker è un WAL cloud-native progettato per l'archiviazione di oggetti, che offre un elevato throughput, un basso overhead operativo e una scalabilità continua. Per i dettagli sull'architettura e sui benchmark, vedere Woodpecker.

Panoramica

  • A partire da Milvus 2.6, Woodpecker è un WAL opzionale che fornisce scritture ordinate e recupero come servizio di log.
  • Come coda di messaggi, si comporta in modo simile a Pulsar/Kafka e può essere abilitato tramite configurazione.
  • Sono supportati due backend di archiviazione: file system locale (local) e archiviazione di oggetti (minio/S3-compatibile).

Avvio rapido

Per abilitare Woodpecker, impostare il tipo di MQ su Woodpecker:

mq:
  type: woodpecker

Nota: Il passaggio a mq.type per un cluster in esecuzione è un'operazione di aggiornamento. Seguire attentamente la procedura di aggiornamento e convalidarla su un cluster nuovo prima di passare alla produzione.

Configurazione

Di seguito è riportato il blocco di configurazione completo di Woodpecker (modificare milvus.yaml o sovrascrivere in 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.

Note chiave:

  • woodpecker.meta
    • tipo: Attualmente è supportato solo etcd. Utilizza lo stesso etcd di Milvus per memorizzare metadati leggeri.
    • prefisso: Il prefisso della chiave per i metadati. Predefinito: woodpecker.
  • woodpecker.client
    • Controlla il comportamento di appendimento/arrotolamento/auditing dei segmenti sul lato client per bilanciare il throughput e la latenza end-to-end.
  • woodpecker.logstore
    • Controlla le politiche di sincronizzazione/flush/compattazione/lettura dei segmenti di log. Queste sono le manopole principali per la regolazione del throughput e della latenza.
  • woodpecker.storage
    • type: minio per lo storage di oggetti compatibile con MinIO/S3 (MinIO/S3/GCS/OSS, ecc.); local per i file system locali/condivisi.
    • rootPath: Percorso di root per il backend di archiviazione (efficace per local; con minio, i percorsi sono dettati da bucket/prefisso).

Modalità di distribuzione

Milvus supporta le modalità Standalone e Cluster. Matrice di supporto del backend di archiviazione Woodpecker:

storage.type=localstorage.type=minio
Milvus StandaloneSupportatoSupportato
Milvus ClusterLimitato (necessita di FS condiviso)Supportato

Note:

  • Con minio, Woodpecker condivide lo stesso storage di oggetti con Milvus (MinIO/S3/GCS/OSS, ecc.).
  • Con local, un disco locale a singolo nodo è adatto solo per Standalone. Se tutti i pod possono accedere a un file system condiviso (ad esempio, NFS), la modalità Cluster può utilizzare anche local.

Compatibilità dello storage a oggetti per storage.type=minio

La seguente matrice riassume la compatibilità attualmente nota dei backend di object storage quando Woodpecker è configurato con storage.type=minio. Queste informazioni si basano sulla discussione GitHub #150.

Fornitore / servizioStatoNote
Archiviazione Blob di AzureSupportatoUtilizza l'SDK nativo di Azure.
AWS S3SupportatoS3 nativo con supporto completo per la scrittura condizionale.
MinIO (>= 2024-12)SupportatoSupporto completo della scrittura condizionale S3.
Aliyun OSSSupportatoSupportato attraverso la sua interfaccia compatibile con S3.
Tencent COSSupportatoSupportato attraverso la sua interfaccia compatibile con S3.
Google Cloud Storage (GCS)SupportatoSupportato attraverso la modalità di interoperabilità S3.
Huawei Cloud OBSNon supportatoManca della semantica di scrittura condizionale richiesta.
Dati VASTSupportatoVerificato dalla comunità; funziona solo con i bucket non aggiornati.
Altri archivi compatibili con S3ParzialeDipende dal supporto completo della semantica S3 Conditional Write.

Note:

  • La compatibilità dipende dal supporto nativo dell'SDK o dal supporto della semantica S3 Conditional Write.
  • Se si autogestisce MinIO per Woodpecker, utilizzare RELEASE.2024-12-18T13-15-44Z o versioni successive.
  • Questa matrice riflette la discussione in corso e può evolvere man mano che il supporto del backend viene convalidato.

Guide alla distribuzione

Abilitare Woodpecker per un cluster Milvus su Kubernetes (Milvus Operator, storage=minio)

Dopo aver installato Milvus Operator, avviare un cluster Milvus con Woodpecker abilitato utilizzando l'esempio ufficiale:

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

Questo esempio configura Woodpecker come coda di messaggi e abilita lo Streaming Node. Il primo avvio potrebbe richiedere del tempo per estrarre le immagini; attendere che tutti i pod siano pronti:

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

Una volta pronti, si dovrebbero vedere pod simili 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

Eseguire il seguente comando per disinstallare il cluster Milvus.

kubectl delete milvus my-release

Se è necessario regolare i parametri di Woodpecker, seguire le impostazioni descritte in message storage config.

Abilitare Woodpecker per un cluster Milvus su Kubernetes (Helm Chart, storage=minio)

Per prima cosa aggiungere e aggiornare il grafico di Milvus Helm come descritto in Eseguire Milvus in Kubernetes con Helm.

Quindi eseguire il deploy con uno dei seguenti esempi:

- Distribuzione in cluster (impostazioni consigliate con Woodpecker e Streaming Node abilitati):

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

- Distribuzione autonoma (Woodpecker abilitato):

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

Dopo la distribuzione, seguire la documentazione per il port-forward e la connessione. Per regolare i parametri di Woodpecker, seguire le impostazioni descritte in message storage config.

Abilitare Woodpecker per Milvus Standalone in Docker (storage=locale)

Seguire Eseguire Milvus in Docker. Esempio:

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

Per modificare ulteriormente le impostazioni di Woodpecker, aggiornare user.yaml ed eseguire bash standalone_embed.sh restart.

Abilitare Woodpecker per Milvus Standalone con Docker Compose (storage=minio)

Seguire Eseguire Milvus con Docker Compose. Esempio:

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

Suggerimenti per la messa a punto del throughput

In base ai benchmark e ai limiti del backend in Woodpecker, ottimizzare il throughput di scrittura end-to-end dai seguenti aspetti:

  • Lato storage
    • Storage a oggetti (compatibile con minio/S3): Aumentare la concorrenza e le dimensioni degli oggetti (evitare oggetti minuscoli). Attenzione ai limiti di banda della rete e dei bucket. Un singolo nodo MinIO su SSD spesso si aggira intorno ai 100 MB/s a livello locale; un singolo EC2 su S3 può raggiungere i GB/s.
    • File system locali/condivisi (locali): Preferire NVMe/dischi veloci. Assicurarsi che il FS gestisca bene le piccole scritture e la latenza di fsync.
  • Manopole Woodpecker
    • Aumentate logstore.segmentSyncPolicy.maxFlushSize e maxFlushThreads per avere flush più grandi e un maggiore parallelismo.
    • Regolate maxInterval in base alle caratteristiche del supporto (scambiate la latenza con il throughput con un'aggregazione più lunga).
    • Per l'archiviazione degli oggetti, considerare l'aumento di segmentRollingPolicy.maxSize per ridurre gli scambi di segmento.
  • Lato client/applicazione
    • Usare batch di dimensioni maggiori e un numero maggiore di scrittori/clienti simultanei.
    • Controllare la tempistica di aggiornamento e creazione dell'indice (batch up prima dell'attivazione) per evitare frequenti piccole scritture.

Dimostrazione dell'inserimento in batch

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}")

Latenza

Woodpecker è un WAL cloud-native progettato per lo storage di oggetti con compromessi tra throughput, costi e latenza. La modalità embedded leggera attualmente supportata dà la priorità all'ottimizzazione dei costi e del throughput, poiché la maggior parte degli scenari richiede solo la scrittura dei dati entro un certo tempo piuttosto che una bassa latenza per le singole richieste di scrittura. Pertanto, Woodpecker impiega scritture in batch, con intervalli predefiniti di 10 ms per i backend di archiviazione del filesystem locale e di 200 ms per i backend di archiviazione di tipo MinIO. Durante le operazioni di scrittura lente, la latenza massima è pari al tempo di intervallo più il tempo di flush.

Si noti che l'inserimento di batch è attivato non solo dagli intervalli di tempo, ma anche dalla dimensione del batch, che è predefinita a 2MB.

Per i dettagli sull'architettura, le modalità di distribuzione (MemoryBuffer / QuorumBuffer) e le prestazioni, vedere Architettura di Woodpecker.

Per ulteriori dettagli sui parametri, consultare il repository GitHub di Woodpecker.