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.
- tipo: Attualmente è supportato solo
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:
minioper lo storage di oggetti compatibile con MinIO/S3 (MinIO/S3/GCS/OSS, ecc.);localper i file system locali/condivisi. - rootPath: Percorso di root per il backend di archiviazione (efficace per
local; conminio, i percorsi sono dettati da bucket/prefisso).
- type:
Modalità di distribuzione
Milvus supporta le modalità Standalone e Cluster. Matrice di supporto del backend di archiviazione Woodpecker:
storage.type=local | storage.type=minio | |
|---|---|---|
| Milvus Standalone | Supportato | Supportato |
| Milvus Cluster | Limitato (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 anchelocal.
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 / servizio | Stato | Note |
|---|---|---|
| Archiviazione Blob di Azure | Supportato | Utilizza l'SDK nativo di Azure. |
| AWS S3 | Supportato | S3 nativo con supporto completo per la scrittura condizionale. |
MinIO (>= 2024-12) | Supportato | Supporto completo della scrittura condizionale S3. |
| Aliyun OSS | Supportato | Supportato attraverso la sua interfaccia compatibile con S3. |
| Tencent COS | Supportato | Supportato attraverso la sua interfaccia compatibile con S3. |
| Google Cloud Storage (GCS) | Supportato | Supportato attraverso la modalità di interoperabilità S3. |
| Huawei Cloud OBS | Non supportato | Manca della semantica di scrittura condizionale richiesta. |
| Dati VAST | Supportato | Verificato dalla comunità ; funziona solo con i bucket non aggiornati. |
| Altri archivi compatibili con S3 | Parziale | Dipende 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-44Zo 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.maxFlushSizeemaxFlushThreadsper avere flush più grandi e un maggiore parallelismo. - Regolate
maxIntervalin 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.maxSizeper ridurre gli scambi di segmento.
- Aumentate
- 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.