From 706f49c61345152921b8e2a7fd132fb69172a411 Mon Sep 17 00:00:00 2001 From: timvisee Date: Wed, 29 Nov 2023 10:58:53 +0100 Subject: [PATCH] Update and merge shard transfer texts --- .../guides/distributed_deployment.md | 45 ++++++++++--------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/qdrant-landing/content/documentation/guides/distributed_deployment.md b/qdrant-landing/content/documentation/guides/distributed_deployment.md index aa3c09dfd..e91efd40d 100644 --- a/qdrant-landing/content/documentation/guides/distributed_deployment.md +++ b/qdrant-landing/content/documentation/guides/distributed_deployment.md @@ -221,8 +221,9 @@ POST /collections/{collection_name}/cluster -After the transfer is initiated, the service will keep both copies of the shard in sync until the transfer is complete. -It will also make sure the transferred shard indexing process is keeping up before performing a final switch. This way, Qdrant ensures that there will be no degradation in performance at the end of the transfer. Once the transfer is completed, the old shard is deleted from the original node. +After the transfer is initiated, the service will process it based on the used +[transfer method](#shard-transfer-method) keeping both shards in sync. Once the +transfer is completed, the old shard is deleted from the source node. In case you want to downscale the cluster, you can move all shards away from a peer and then remove the peer using the [remove peer API](https://qdrant.github.io/qdrant/redoc/index.html#tag/cluster/operation/remove_peer). @@ -237,22 +238,23 @@ After that, Qdrant will exclude the node from the consensus, and the instance wi *Available as of v1.7.0* There are different methods for transferring, such as moving or replicating, a -shard to another node. Depending on how you'd like to manage your cluster you -might want to choose a specific method. Each method has its own pros and cons. -Which is fastest depends on the size and state of a shard. +shard to another node. Depending on what performance and guarantees you'd like +to have and how you'd like to manage your cluster, you likely want to choose a +specific method. Each method has its own pros and cons. Which is fastest depends +on the size and state of a shard. Available shard transfer methods are: - `stream_records`: _(default)_ transfer shard by streaming just its records to the target node in batches. - `snapshot`: transfer shard including its index and quantized data by utilizing a [snapshot](../../concepts/snapshots) automatically. -Pros, cons and requirements for each transfer method are: +Each has pros, cons and specific requirements, which are: | Method: | Stream records | Snapshot | |:---|:---|:---| | **Connection** | | | -| **HNSW index** | | | -| **Quantization** | | | +| **HNSW index** | | | +| **Quantization** | | | | **Consistency** | | | | **Disk space** | | | @@ -283,26 +285,29 @@ POST /collections/{collection_name}/cluster The `stream_records` transfer method is the simplest available. It simply transfers all shard records in batches to the target node until it has -transferred all of them. The method has two common disadvantages: 1. it does not -transfer index or quantization data, meaning that the shard has to be optimized -again on the new node which can be very expensive. 2. The consistency and -ordering guarantees are `weak`[^unordered], which is not suitable for some -applications. Because it is so simple it's also very robust, making it a -reliable choice if the above cons are accepatble in your use case. If your -cluster is unstable and out of resources it is probably best to use the -`stream_records` transfer method, because it is unlikely to fail. +transferred all of them, keeping both shards in sync. It will also make sure the +transferred shard indexing process is keeping up before performing a final +switch. The method has two common disadvantages: 1. It does not transfer index +or quantization data, meaning that the shard has to be optimized again on the +new node, which can be very expensive. 2. The consistency and ordering +guarantees are `weak`[^unordered], which is not suitable for some applications. +Because it is so simple, it's also very robust, making it a reliable choice if +the above cons are acceptable in your use case. If your cluster is unstable and +out of resources, it's probably best to use the `stream_records` transfer +method, because it is unlikely to fail. The `snapshot` transfer method utilizes [snapshots](../../concepts/snapshots) to transfer a shard. A snapshot is created automatically. It is then transferred and restored on the target node. After this is done, the snapshot is removed from both nodes. While the snapshot/transfer/restore operation is happening, the -source nodes queues up all new operations. All queued updates are then sent in +source node queues up all new operations. All queued updates are then sent in order to the target shard to bring it into the same state as the source. There are two important benefits: 1. It transfers index and quantization data, so that the shard does not have to be optimized again on the target node, making them -immediately available. Especially on large shards, this can give a huge -performance improvement. 2. The consistency and ordering guarantees can be -`strong`[^ordered], required for some applications. +immediately available. This way, Qdrant ensures that there will be no +degradation in performance at the end of the transfer. Especially on large +shards, this can give a huge performance improvement. 2. The consistency and +ordering guarantees can be `strong`[^ordered], required for some applications. The `stream_records` method is currently used as default. This may change in the future.