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

article improvements and imagery

Browse Source
This commit is contained in:
David Myriel
2024-02-12 18:24:53 +01:00
parent a004c5c26a
commit 0bd57f4444
9 changed files with 40 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/articles/multitenancy.md
+34 -25
View File
@@ -16,37 +16,44 @@ keywords:
- vector database
---
Whether you're building a fraud-detection analytics app, a RAG solution for e-commerce sites, or a healthcare portal for the government - you need to leverage a multitenant architecture and ensure access to your data is controlled. In the world of SaaS and large-scale enterprise solutions, this setup is the norm and it will considerably increase performance and lower your hosting costs. A single Qdrant cluster has the potential to support all of your customers, while each one of them would only see their own data. At times, if this data is location-sensitive, Qdrant gives you the option to divide your cluster by region or other criteria.
We are seeing the topics of [multitenancy](https://qdrant.tech/documentation/guides/multiple-partitions/) and [distributed deployment](https://qdrant.tech/documentation/guides/distributed_deployment/#sharding) pop-up daily on our [Discord support channel](https://qdrant.to/discord). This tells us that many of you are looking to scale Qdrant along with the rest of your machine learning setup.
We are seeing the topics of multitenancy and distributed deployment pop-up daily on our [free support Discord](https://qdrant.to/discord) channel, which tells us that users are looking to scale Qdrant along with the rest of their ML setup. If you are currently mulling over your vector database implementation and are thinking of creating multiple collections for each user, read on.
Whether you are building a bank fraud-detection system, RAG for e-commerce, or services for the federal government - you will need to leverage a multitenant architecture to scale your product.
In the world of SaaS and enterprise apps, this setup is the norm. It will considerably increase your application's performance and lower your hosting costs.
[Multitenancy](https://qdrant.tech/documentation/guides/multiple-partitions/) is one of the most useful features Qdrant can offer, whereby you can partition one database instance for a vast number of users. Combining this with [Custom Sharding](https://qdrant.tech/documentation/guides/distributed_deployment/#user-defined-sharding) will result in an efficiently-partitioned architecture that further leverages the convenience of a single Qdrant cluster. This article will briefly explain the benefits and show how you can get started using both features.
We have developed two major features just for this. __You can now scale a single Qdrant cluster and support all of your customers worldwide.__ Under [multitenancy](https://qdrant.tech/documentation/guides/multiple-partitions/), each customer's data is completely isolated and only accessible by them. At times, if this data is location-sensitive, Qdrant also gives you the option to divide your cluster by region or other criteria that further secure your customer's access. This is called [custom sharding](https://qdrant.tech/documentation/guides/distributed_deployment/#user-defined-sharding).
## Multitenancy: one collection, many users
Combining these two will result in an efficiently-partitioned architecture that further leverages the convenience of a single Qdrant cluster. This article will briefly explain the benefits and show how you can get started using both features.
Multitenant architectures are almost required when scaling out your service and we recommend our multitenancy feature to most users. Under this setup you can upsert all your data to a single Qdrant collection, and then partition each vector via its payload. This means that all your users are leveraging the power of a single Qdrant cluster, but their data is still kept separate.
## One collection, many tenants
**Figure 1:** Each individual vector is assigned a specific payload that denotes which user it belongs to. This is how a large number of different users can share a single Qdrant collection.
When working with Qdrant, you can upsert all your data to a single collection, and then partition each vector via its payload. This means that all your users are leveraging the power of a single Qdrant cluster, but their data is still isolated within the collection. Let's take a look at a two-tenant collection:
**Figure 1:** Each individual vector is assigned a specific payload that denotes which tenant it belongs to. This is how a large number of different tenants can share a single Qdrant collection.
![Qdrant Multitenancy](/articles_data/multitenancy/multitenancy-single.png)
As a vector search engine, Qdrant is built to excel in multitenant environments. You should only create multiple collections when you have a limited number of users and you need isolation. Creating numerous collections may result in resource overhead and may cause dependencies. You always need to ensure that they do not affect each other in any way, including performance-wise.
Qdrant is built to excel in a single collection with a vast number of tenants. You should only create multiple collections when your data is not homogenous or if users' vectors are created by different embedding models. Creating too many collections may result in resource overhead and cause dependencies. This can increase costs and affect overall performance.
## Defining your deployment via Custom Sharding
## Sharding your database
Qdrant lets you specify a shard for each point individually. This feature is useful if you want to control where your data is kept in the cluster. Your operations will be able to hit only the subset of shards they actually need. In massive-scale deployments, this can significantly improve the performance of operations that do not require the whole collection to be scanned.
With Qdrant, you can also specify a shard for each vector individually. This feature is useful if you want to [control where your data is kept in the cluster](https://qdrant.tech/documentation/guides/distributed_deployment/#sharding). For example, one set of vectors can be assigned to one shard on its own node, while another set can be on a completely different node.
During vector search, your operations will be able to hit only the subset of shards they actually need. In massive-scale deployments, __this can significantly improve the performance of operations that do not require the whole collection to be scanned__.
This works in the other direction as well. Whenever you search for something, you can specify a shard or several shards and Qdrant will know where to find them. It will avoid asking all machines in your cluster for results. This will minimize overhead and maximize performance.
### Common use cases
A clear use-case for this feature is managing a multitenant collection, where each tenant (let it be a user or organization) is assumed to be segregated, so they can have their data stored in separate shards. Sharding solves the problem of region-based data placement, whereby certain data needs to be kept within specific locations. To do this, however, you will need to [move your shards between nodes](https://qdrant.tech/documentation/guides/distributed_deployment/#moving-shards).
**Figure 2:** Users can both upsert and query shards that are relevant to them, all within the same collection. Regional sharding can help avoid cross-continental traffic.
![Qdrant Multitenancy](/articles_data/multitenancy/shards.png)
A clear use-case for this feature is managing a multitenant collection, where each tenant (let it be a user or organization) is assumed to be segregated, so they can have their data stored in separate shards. Sharding solves the problem of region-based data placement, whereby certain data needs to be kept within specific locations.
Custom sharding also gives you precise control over other use cases. A time-based data placement means that data streams can index shards that represent latest updates. If you organize your shards by date, you can have great control over the recency of retrieved data. This is relevant for social media platforms, which greatly rely on time-sensitive data.
## Before I go any further.....how secure is my user data?
By design, Qdrant offers three levels of isolation. We initially introduced collection-based isolation, but your scaled setup has to move beyond this level. In this scenario, you will leverage payload-based isolation (from multitenancy) and resource-based isolation (from sharding). The ultimate goal is to have a single collection, where you can manipulate and customize placement of shards inside your cluster more precisely and avoid any kind of overhead.
By design, Qdrant offers three levels of isolation. We initially introduced collection-based isolation, but your scaled setup has to move beyond this level. In this scenario, you will leverage payload-based isolation (from multitenancy) and resource-based isolation (from sharding). The ultimate goal is to have a single collection, where you can manipulate and customize placement of shards inside your cluster more precisely and avoid any kind of overhead. The diagram below shows the arrangement of your data within a two-tier isolation arrangement.
**Figure 3:** Users can query the collection based on two filters: the `group_id` and the individual `shard_key_selector`. This gives your data two additional levels of isolation.
![Qdrant Multitenancy](/articles_data/multitenancy/multitenancy.png)
@@ -62,15 +69,17 @@ client.create_collection(
sharding_method=models.ShardingMethod.CUSTOM,
# ... other collection parameters
)
client.create_shard_key("{collection_name}", "canada", "usa")
client.create_shard_key("{collection_name}", "canada", "germany")
```
In this example, your cluster is divided between USA and Canada. Canadian law is much more stringent when it comes to international data transfer. Let's say you are creating a RAG application that supports the healthcare industry. Your Canadian customer data will have to be clearly separated for compliance purposes. Sharding and multitenancy can be combined to create a powerful scalable solution for real businesss.
In this example, your cluster is divided between Germany and Canada. Canadian and German law differ when it comes to international data transfer. Let's say you are creating a RAG application that supports the healthcare industry. Your Canadian customer data will have to be clearly separated for compliance purposes from your German customer.
Even though it is part of the same collection, data from each shard is isolated from other shards and can be retrieved as such. For additional examples on shards and retrieval, consult [Qdrant Client specification](https://python-client.qdrant.tech) and our [Distributed Deployments](https://qdrant.tech/documentation/guides/distributed_deployment/) documentation.
## Configure a multitenant setup for users
Let's continue and start adding data. As you upsert your vectors to your new collection, you can add a `group_id` field to each vector. If you do this, Qdrant will assign each vector to its respective group.
Additionally, each vector can now be allocated to a shard. You can specify the `shard_key_selector` for each individual vector. In this example, you are upserting data belonging to `user_1` to the Canadian region.
Additionally, each vector can now be allocated to a shard. You can specify the `shard_key_selector` for each individual vector. In this example, you are upserting data belonging to `tenant_1` to the Canadian region.
```python
client.upsert(
@@ -78,14 +87,14 @@ client.upsert(
points=[
models.PointStruct(
id=1,
payload={"group_id": "user_1"},
payload={"group_id": "tenant_1"},
vector=[0.9, 0.1, 0.1],
shard_key_selector="canada",
),
],
)
```
Keep in mind that the data for each `group_id` is isolated. In the example below, `user_1` vectors are kept separate from `user_2`. The first user will be able to access their data in the Canadian portion of the cluster, while `user_2 `might only be able to retrieve USA-based information.
Keep in mind that the data for each `group_id` is isolated. In the example below, `tenant_1` vectors are kept separate from `tenant_2`. The first tenant will be able to access their data in the Canadian portion of the cluster, while `tenant_2 `might only be able to retrieve information hosted in Germany.
```python
client.upsert(
@@ -93,21 +102,21 @@ client.upsert(
points=[
models.PointStruct(
id=1,
payload={"group_id": "user_1"},
payload={"group_id": "tenant_1"},
vector=[0.9, 0.1, 0.1],
shard_key_selector="canada",
),
models.PointStruct(
id=2,
payload={"group_id": "user_1"},
payload={"group_id": "tenant_1"},
vector=[0.1, 0.9, 0.1],
shard_key_selector="canada",
),
models.PointStruct(
id=3,
payload={"group_id": "user_2"},
payload={"group_id": "tenant_2"},
vector=[0.1, 0.1, 0.9],
shard_key_selector="usa",
shard_key_selector="germany",
),
],
)
@@ -125,7 +134,7 @@ client.search(
models.FieldCondition(
key="group_id",
match=models.MatchValue(
value="user_1",
value="tenant_1",
),
),
]
@@ -174,11 +183,11 @@ client.create_payload_index(
## Next steps
Qdrant is ready to support a massive-scale architecture for your machine learning project. If you are just getting started with our vector database, you should try the [quickstart tutorial](https://qdrant.tech/documentation/quick-start/) or read our [documentation](https://qdrant.tech/documentation/).
Qdrant is ready to support a massive-scale architecture for your machine learning project. If you want to see whether our vector database is right for you, try the [quickstart tutorial](https://qdrant.tech/documentation/quick-start/) or read our [docs and tutorials](https://qdrant.tech/documentation/).
To spin up a free instance of Qdrant, sign up for [Qdrant Cloud](https://qdrant.to/cloud) - it is forever free.
To spin up a free instance of Qdrant, sign up for [Qdrant Cloud](https://qdrant.to/cloud) - no strings attached.
For support, or to swap ideas, join our [Discord](https://qdrant.to/discord) community, where we talk about vector search and similarity learning, publish other examples and demos of machine learning applications and vector database setups.
Get support or share ideas in our [Discord](https://qdrant.to/discord) community. This is where we talk about vector search theory, publish examples and demos and discuss vector database setups.