Woodpecker verwendenCompatible with Milvus 2.6.x

In dieser Anleitung wird erklärt, wie Woodpecker als Write-Ahead Log (WAL) in Milvus 2.6.x aktiviert und verwendet wird. Woodpecker ist ein Cloud-natives WAL, das für Objektspeicher entwickelt wurde und einen hohen Durchsatz, einen geringen betrieblichen Overhead und eine nahtlose Skalierbarkeit bietet. Einzelheiten zur Architektur und zu Benchmarks finden Sie unter Woodpecker.

Überblick

• Ab Milvus 2.6 ist Woodpecker ein optionales WAL, das geordnete Schreibvorgänge und Wiederherstellung als Protokollierungsdienst bietet.
• Als optionale Nachrichtenwarteschlange verhält er sich ähnlich wie Pulsar/Kafka und kann über die Konfiguration aktiviert werden.
• Es werden zwei Speicher-Backends unterstützt: lokales Dateisystem (local) und Objektspeicher (minio/S3-kompatibel).

Schnellstart

Um Woodpecker zu aktivieren, setzen Sie den MQ-Typ auf Woodpecker:

mq:
  type: woodpecker

Hinweis: Der Wechsel von mq.type für einen laufenden Cluster ist ein Upgrade-Vorgang. Führen Sie das Upgrade-Verfahren sorgfältig durch und validieren Sie es auf einem neuen Cluster, bevor Sie die Produktion umstellen.

Konfiguration

Nachstehend finden Sie den vollständigen Woodpecker-Konfigurationsblock (bearbeiten Sie milvus.yaml oder überschreiben Sie ihn 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.

Wichtige Hinweise:

• woodpecker.meta
  • Typ: Derzeit wird nur etcd unterstützt. Verwenden Sie denselben etcd wie Milvus, um leichtgewichtige Metadaten zu speichern.
  • Präfix: Das Schlüsselpräfix für Metadaten. Standard: woodpecker.
• woodpecker.client
  • Steuert das Verhalten beim Anhängen/Rollen/Auditing von Segmenten auf der Client-Seite, um Durchsatz und End-to-End-Latenz auszugleichen.
• woodpecker.logstore
  • Steuert die Synchronisierungs-/Flush-/Kompaktierungs-/Leserichtlinien für Protokollsegmente. Dies sind die wichtigsten Regler für die Abstimmung von Durchsatz und Latenz.
• woodpecker.storage
  • type: minio für MinIO/S3-kompatible Objektspeicher (MinIO/S3/GCS/OSS usw.); local für lokale/gemeinsame Dateisysteme.
  • rootPfad: Wurzelpfad für das Speicher-Backend (gilt für local; bei minio werden die Pfade durch Bucket/Präfix vorgegeben).

Bereitstellungsmodi

Milvus unterstützt sowohl den Standalone- als auch den Cluster-Modus. Woodpecker-Speicher-Backend-Unterstützungsmatrix:

	storage.type=local	storage.type=minio
Milvus Einzelplatz	Unterstützt	Unterstützt
Milvus Cluster	Eingeschränkt (benötigt gemeinsames FS)	Unterstützt

Anmerkungen:

• Mit minio nutzt Woodpecker den gleichen Objektspeicher wie Milvus (MinIO/S3/GCS/OSS, etc.).
• Mit local ist eine lokale Festplatte mit einem Knoten nur für Standalone geeignet. Wenn alle Pods auf ein gemeinsames Dateisystem (z. B. NFS) zugreifen können, kann der Cluster-Modus auch local verwenden.

Leitfäden für den Einsatz

Woodpecker für einen Milvus Cluster auf Kubernetes aktivieren (Milvus Operator, storage=minio)

Nach der Installation des Milvus Operator starten Sie einen Milvus-Cluster mit aktiviertem Woodpecker unter Verwendung des offiziellen Beispiels:

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

Dieses Beispiel konfiguriert Woodpecker als Nachrichtenwarteschlange und aktiviert den Streaming Node. Der erste Start kann einige Zeit in Anspruch nehmen; warten Sie, bis alle Pods bereit sind:

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

Wenn sie fertig sind, sollten Sie Pods ähnlich wie diese sehen:

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

Führen Sie den folgenden Befehl aus, um den Milvus-Cluster zu deinstallieren.

kubectl delete milvus my-release

Wenn Sie Woodpecker-Parameter anpassen müssen, befolgen Sie die in message storage config beschriebenen Einstellungen.

Aktivieren von Woodpecker für einen Milvus-Cluster auf Kubernetes (Helm Chart, storage=minio)

Fügen Sie zunächst das Milvus Helm Chart hinzu und aktualisieren Sie es, wie unter Milvus in Kubernetes mit Helm ausführen beschrieben.

Führen Sie dann die Bereitstellung mit einem der folgenden Beispiele durch:

- Cluster-Bereitstellung (empfohlene Einstellungen mit aktiviertem Woodpecker und Streaming Node):

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

- Eigenständige Bereitstellung (Woodpecker aktiviert):

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

Nach dem Deployment folgen Sie den Anweisungen zum Port-Forwarding und zur Verbindung. Um Woodpecker-Parameter anzupassen, folgen Sie den Einstellungen, die in message storage config beschrieben sind.

Aktivieren Sie Woodpecker für Milvus Standalone in Docker (storage=local)

Folgen Sie Run Milvus in Docker. Beispiel:

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

Um weitere Woodpecker-Einstellungen zu ändern, aktualisieren Sie user.yaml und führen Sie bash standalone_embed.sh restart aus.

Aktivieren Sie Woodpecker für Milvus Standalone mit Docker Compose (storage=minio)

Folgen Sie Run Milvus with Docker Compose. Beispiel:

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

Tipps zur Durchsatzoptimierung

Optimieren Sie auf der Grundlage der Benchmarks und Backend-Limits in Woodpecker den End-to-End-Schreibdurchsatz unter den folgenden Aspekten:

• Speicherseite
  • Objektspeicher (minio/S3-kompatibel): Erhöhen Sie die Nebenläufigkeit und die Objektgröße (vermeiden Sie kleine Objekte). Achten Sie auf die Grenzen der Netzwerk- und Bucket-Bandbreite. Ein einzelner MinIO-Knoten auf SSD hat oft eine lokale Obergrenze von etwa 100 MB/s; ein einzelner EC2 zu S3 kann GB/s erreichen.
  • Lokale/gemeinsame Dateisysteme (lokal): Bevorzugen Sie NVMe/schnelle Festplatten. Stellen Sie sicher, dass das FS kleine Schreibvorgänge und fsync-Latenz gut handhabt.
• Woodpecker-Knöpfe
  • Erhöhen Sie logstore.segmentSyncPolicy.maxFlushSize und maxFlushThreads für größere Flushes und höhere Parallelität.
  • Passen Sie maxInterval entsprechend den Medieneigenschaften an (tauschen Sie Latenz gegen Durchsatz mit längerer Aggregation).
  • Für Objektspeicher sollten Sie segmentRollingPolicy.maxSize erhöhen, um Segmentwechsel zu reduzieren.
• Client-/Anwendungsseite
  • Verwenden Sie größere Stapelgrößen und mehr gleichzeitige Schreiber/Clients.
  • Steuern Sie das Timing der Auffrischung/des Indexaufbaus (Stapelverarbeitung vor Auslösung), um häufige kleine Schreibvorgänge zu vermeiden.

Batch Insert Demo

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

Latenz

Woodpecker ist eine Cloud-native WAL, die für die Objektspeicherung mit Kompromissen zwischen Durchsatz, Kosten und Latenzzeit entwickelt wurde. Der derzeit unterstützte leichtgewichtige eingebettete Modus priorisiert die Optimierung von Kosten und Durchsatz, da die meisten Szenarien nur das Schreiben von Daten innerhalb einer bestimmten Zeit erfordern und keine niedrige Latenz für einzelne Schreibanfragen verlangen. Daher verwendet Woodpecker gebündelte Schreibvorgänge mit Standardintervallen von 10 ms für lokale Dateisystem-Speicher-Backends und 200 ms für MinIO-ähnliche Speicher-Backends. Bei langsamen Schreibvorgängen ist die maximale Latenzzeit gleich der Intervallzeit plus der Flush-Zeit.

Beachten Sie, dass das Einfügen von Stapeln nicht nur durch Zeitintervalle, sondern auch durch die Stapelgröße ausgelöst wird, die standardmäßig bei 2 MB liegt.

Einzelheiten zur Architektur, zu den Bereitstellungsmodi (MemoryBuffer / QuorumBuffer) und zur Leistung finden Sie unter Woodpecker-Architektur.

Weitere Details zu den Parametern finden Sie im Woodpecker-GitHub-Repository.