Utiliser WoodpeckerCompatible with Milvus 2.6.x

Ce guide explique comment activer et utiliser Woodpecker en tant que journal en avance sur l'écriture (WAL) dans Milvus 2.6.x. Woodpecker est un WAL natif conçu pour le stockage d'objets, offrant un débit élevé, une faible surcharge opérationnelle et une évolutivité transparente. Pour plus de détails sur l'architecture et le benchmark, voir Woodpecker.

Vue d'ensemble

• À partir de Milvus 2.6, Woodpecker est un WAL optionnel qui fournit des écritures ordonnées et une récupération en tant que service de journalisation.
• En tant que choix de file d'attente de messages, il se comporte de manière similaire à Pulsar/Kafka et peut être activé via la configuration.
• Deux systèmes de stockage sont pris en charge : le système de fichiers local (local) et le stockage d'objets (minio/S3-compatible).

Démarrage rapide

Pour activer Woodpecker, définissez le type MQ sur Woodpecker :

mq:
  type: woodpecker

Remarque : le changement de mq.type pour un cluster en cours d'exécution est une opération de mise à niveau. Suivez attentivement la procédure de mise à niveau et validez sur un nouveau cluster avant de passer en production.

Configuration de Woodpecker

Vous trouverez ci-dessous le bloc de configuration complet de Woodpecker (modifiez milvus.yaml ou remplacez dans 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.

Notes importantes :

• woodpecker.meta
  • type: Actuellement, seul etcd est pris en charge. Réutiliser le même etcd que Milvus pour stocker des métadonnées légères.
  • prefix: Le préfixe clé pour les métadonnées. Valeur par défaut : woodpecker.
• woodpecker.client
  • Contrôle le comportement du segment append/rolling/audit côté client pour équilibrer le débit et la latence de bout en bout.
• woodpecker.logstore
  • Contrôle les politiques de synchronisation/flush/compactage/lecture pour les segments de journaux. Il s'agit des principaux boutons de réglage du débit et de la latence.
• woodpecker.storage
  • type: minio pour le stockage d'objets compatible avec MinIO/S3 (MinIO/S3/GCS/OSS, etc.) ; local pour les systèmes de fichiers locaux/partagés.
  • rootPath: Chemin d'accès à la racine du backend de stockage (effectif pour local; avec minio, les chemins d'accès sont dictés par le seau/préfixe).

Modes de déploiement

Milvus prend en charge les modes autonome et en grappe. Matrice de prise en charge du backend de stockage Woodpecker :

	storage.type=local	storage.type=minio
Milvus autonome	Pris en charge	Pris en charge
Milvus Cluster	Limité (nécessite un système de stockage partagé)	Pris en charge

Notes :

• Avec minio, Woodpecker partage le même stockage d'objets avec Milvus (MinIO/S3/GCS/OSS, etc.).
• Avec local, un disque local à un seul nœud n'est adapté qu'au mode autonome. Si tous les pods peuvent accéder à un système de fichiers partagé (par exemple, NFS), le mode Cluster peut également utiliser local.

Guides de déploiement

Activer Woodpecker pour un cluster Milvus sur Kubernetes (Milvus Operator, storage=minio)

Après avoir installé Milvus Operator, démarrez un cluster Milvus avec Woodpecker activé à l'aide de l'exemple officiel :

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

Cet exemple configure Woodpecker en tant que file d'attente de messages et active le nœud de streaming. Le premier démarrage peut prendre du temps pour extraire les images ; attendez que tous les pods soient prêts :

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

Une fois qu'ils sont prêts, vous devriez voir des pods similaires à ceux qui suivent :

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

Exécutez la commande suivante pour désinstaller le cluster Milvus.

kubectl delete milvus my-release

Si vous devez ajuster les paramètres de Woodpecker, suivez les paramètres décrits dans message storage config.

Activer Woodpecker pour un cluster Milvus sur Kubernetes (tableau Helm, storage=minio)

Commencez par ajouter et mettre à jour la carte Milvus Helm comme décrit dans Exécuter Milvus dans Kubernetes avec Helm.

Ensuite, déployez avec l'un des exemples suivants :

- Déploiement en cluster (paramètres recommandés avec Woodpecker et Streaming Node activés) :

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

- Déploiement autonome (Woodpecker activé) :

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

Après le déploiement, suivez la documentation pour transférer le port et vous connecter. Pour ajuster les paramètres de Woodpecker, suivez les paramètres décrits dans la configuration du stockage des messages.

Activer Woodpecker pour Milvus Standalone dans Docker (storage=local)

Suivre Run Milvus in Docker. Exemple :

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

Pour modifier davantage les paramètres de Woodpecker, mettez à jour user.yaml et exécutez bash standalone_embed.sh restart.

Activer Woodpecker pour Milvus Standalone avec Docker Compose (storage=minio)

Suivre Run Milvus with Docker Compose. Exemple :

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

Conseils pour l'optimisation du débit

Sur la base des repères et des limites du backend dans Woodpecker, optimisez le débit d'écriture de bout en bout à partir des aspects suivants :

• Côté stockage
  • Stockage d'objets (compatible minio/S3): Augmentez la concurrence et la taille des objets (évitez les objets minuscules). Surveillez les limites du réseau et de la bande passante des godets. Un seul nœud MinIO sur SSD plafonne souvent autour de 100 Mo/s localement ; un seul EC2 vers S3 peut atteindre des Go/s.
  • Systèmes de fichiers locaux/partagés (locaux): Préférez les disques NVMe/rapides. Assurez-vous que le système de fichiers gère bien les petites écritures et la latence fsync.
• Boutons Woodpecker
  • Augmentez logstore.segmentSyncPolicy.maxFlushSize et maxFlushThreads pour des vidages plus importants et un parallélisme plus élevé.
  • Réglez maxInterval en fonction des caractéristiques du support (échangez la latence contre le débit avec une agrégation plus longue).
  • Pour le stockage d'objets, envisagez d'augmenter segmentRollingPolicy.maxSize pour réduire les commutations de segments.
• Côté client/application
  • Utiliser des lots plus importants et un plus grand nombre d'écrivains/clients simultanés.
  • Contrôler la synchronisation de l'actualisation et de la constitution de l'index (mettre en lot avant de déclencher) afin d'éviter les petites écritures fréquentes.

Démonstration d'insertion par lots

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

Temps de latence

Woodpecker est un WAL natif conçu pour le stockage d'objets avec des compromis entre le débit, le coût et la latence. Le mode léger intégré actuellement pris en charge donne la priorité à l'optimisation des coûts et du débit, car la plupart des scénarios exigent que les données soient écrites dans un certain délai plutôt que d'exiger une faible latence pour les demandes d'écriture individuelles. Par conséquent, Woodpecker utilise des écritures par lots, avec des intervalles par défaut de 10 ms pour les backends de stockage de systèmes de fichiers locaux et de 200 ms pour les backends de stockage de type MinIO. Lors d'opérations d'écriture lentes, la latence maximale est égale au temps d'intervalle plus le temps de vidage.

Notez que l'insertion de lots est déclenchée non seulement par les intervalles de temps, mais aussi par la taille du lot, qui est par défaut de 2 Mo.

Pour plus de détails sur l'architecture, les modes de déploiement (MemoryBuffer / QuorumBuffer) et les performances, voir Architecture Woodpecker.

Pour plus de détails sur les paramètres, voir le dépôt GitHub Woodpecker.