krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-09-29 07:58:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

tweaks

Browse Source
This commit is contained in:
Luis Cossío
2023-12-08 11:08:31 +01:00
committed by timvisee
parent 4a39a0c8b7
commit 6caab11f8f
1 changed files with 6 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/guides/distributed_deployment.md
+6 -2
View File
@@ -313,7 +313,7 @@ In this mode, the `shard_number` means the number of shards per shard key, where
Then you will have `1 * 10 * 2 = 20` total physical shards in the collection.
To specify the shard for each point, you need to provide the `shard_key` field in the point payload:
To specify the shard for each point, you need to provide the `shard_key` field in the upsert request:
```http
PUT /collections/{collection_name}/points
@@ -380,11 +380,15 @@ client
```
<aside role="alert">
When using custom sharding, IDs are only enforced to be unique within a shard key. This means that you can have multiple points with the same ID, if they have different shard keys.
Using the same point ID across multiple shard keys is __not supported<sup>*</sup>__ and should be avoided.
<strong><sup>*</sup></strong> When using custom sharding, IDs are only enforced to be unique within a shard key. This means that you can have multiple points with the same ID, if they have different shard keys.
This is a limitation of the current implementation, and is an anti-pattern that should be avoided because it can create scenarios of points with the same ID to have different contents. In the future, we plan to add a global ID uniqueness check.
</aside>
Now you can target the operations to specific shard(s) by specifying the `shard_key` on any operation you do. Operations that do not specify the shard key will be executed on __all__ shards.
### Shard transfer method
*Available as of v1.7.0*