mirror of
https://github.com/qdrant/landing_page.git
synced 2026-10-04 10:28:29 +02:00
Restructure Docs - Stage 4a (#2280)
* create Develop and Deploy tabs; move Operations; re-weight pages * move capacity planning page; create section dropdown content * added aliases to frontmatter * update link references to new canonical links; maintain anchoring * address remaining link issues and errors * fix outlier tutorial reference issue * Treat 'develop' and 'deploy' as a unified search space * fix some frontmatter aliases * add section header redirects * fix 'Operations' redirect to go to 'Deploy' tab * update redirects file for * pattern * add :splat to redirect references * Add wildcard to each entry in _redirects file --------- Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>
This commit is contained in:
kanungle
co-authored by
Abdon Pijpelink
Abdon Pijpelink
parent
7b463c5ae5
commit
544708f293
@@ -5,7 +5,7 @@ is_empty: false
|
||||
aliases:
|
||||
- how-to
|
||||
- tutorials
|
||||
partition: qdrant
|
||||
partition: develop
|
||||
---
|
||||
|
||||
### Operations & Scale Tutorials
|
||||
@@ -16,5 +16,5 @@ partition: qdrant
|
||||
|
||||
<!-- KEEP BELOW FOR REFERENCE -->
|
||||
|
||||
<!-- | [Qdrant Cloud Prometheus Monitoring](/documentation/tutorials-and-examples/managed-cloud-prometheus/) | Observability with Prometheus and Grafana. | <span class="pill">Prometheus</span> | 30m | <span class="text-yellow">Intermediate</span> | -->
|
||||
<!-- | [Self-Hosted Prometheus Monitoring](/documentation/tutorials-and-examples/hybrid-cloud-prometheus/) | Observability for hybrid/private cloud setups. | <span class="pill">Prometheus</span> | 30m | <span class="text-yellow">Intermediate</span> | -->
|
||||
<!-- | [Qdrant Cloud Prometheus Monitoring](/documentation/ops-monitoring/managed-cloud-prometheus/) | Observability with Prometheus and Grafana. | <span class="pill">Prometheus</span> | 30m | <span class="text-yellow">Intermediate</span> | -->
|
||||
<!-- | [Self-Hosted Prometheus Monitoring](/documentation/ops-monitoring/hybrid-cloud-prometheus/) | Observability for hybrid/private cloud setups. | <span class="pill">Prometheus</span> | 30m | <span class="text-yellow">Intermediate</span> | -->
|
||||
@@ -23,7 +23,7 @@ in this tutorial to create and download snapshots. When you [Restore from snapsh
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Let's assume you already have a running Qdrant instance or a cluster. If not, you can follow the [installation guide](/documentation/operations/installation/) to set up a local Qdrant instance or use [Qdrant Cloud](https://cloud.qdrant.io/) to create a cluster in a few clicks.
|
||||
Let's assume you already have a running Qdrant instance or a cluster. If not, you can follow the [installation guide](/documentation/installation/) to set up a local Qdrant instance or use [Qdrant Cloud](https://cloud.qdrant.io/) to create a cluster in a few clicks.
|
||||
|
||||
Once the cluster is running, let's install the required dependencies:
|
||||
|
||||
@@ -151,7 +151,7 @@ Qdrant exposes an HTTP endpoint to request creating a snapshot, but we can also
|
||||
Our setup consists of 3 nodes, so we need to call the endpoint **on each of them** and create a snapshot on each node. While using Python SDK, that means creating a separate client instance for each node.
|
||||
|
||||
|
||||
<aside role="status">You may get a timeout error, if the collection size is big. You can trigger the snapshot process in the background, without awaiting for the result, by using <code>wait=false</code> parameter. You can always <a href="/documentation/operations/snapshots/#list-snapshot">list all the snapshots through the API</a> later on.</aside>
|
||||
<aside role="status">You may get a timeout error, if the collection size is big. You can trigger the snapshot process in the background, without awaiting for the result, by using <code>wait=false</code> parameter. You can always <a href="/documentation/snapshots/#list-snapshot">list all the snapshots through the API</a> later on.</aside>
|
||||
|
||||
|
||||
```python
|
||||
@@ -276,7 +276,7 @@ curl -X POST 'https://node-2.my-cluster.com:6333/collections/test_collection_imp
|
||||
```
|
||||
|
||||
|
||||
**Important:** We selected `priority=snapshot` to make sure that the snapshot is preferred over the data stored on the node. You can read mode about the priority in the [documentation](/documentation/operations/snapshots/#snapshot-priority).
|
||||
**Important:** We selected `priority=snapshot` to make sure that the snapshot is preferred over the data stored on the node. You can read mode about the priority in the [documentation](/documentation/snapshots/#snapshot-priority).
|
||||
|
||||
Apart from Snapshots, Qdrant also provides the [Qdrant Migration Tool](https://github.com/qdrant/migration) that supports:
|
||||
- Migration between Qdrant Cloud instances.
|
||||
|
||||
@@ -19,7 +19,7 @@ In this tutorial, we will learn how to use the migration tool and walk through a
|
||||
|
||||
## Why use this instead of Qdrant’s Native Snapshotting?
|
||||
|
||||
Qdrant supports [snapshot-based backups](/documentation/operations/snapshots/), which are low-level disk operations built for same-cluster recovery or local backups. These snapshots:
|
||||
Qdrant supports [snapshot-based backups](/documentation/snapshots/), which are low-level disk operations built for same-cluster recovery or local backups. These snapshots:
|
||||
|
||||
* Require snapshot consistency across nodes.
|
||||
* Can be hard to port across machines or cloud zones.
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 35
|
||||
|
||||
When working with massive, fast-moving datasets, like social media or image/video streams, efficient storage and retrieval are critical. Often, only the most recent data is relevant, while older data can be archived or deleted. For instance, in sentiment analysis of social media posts, you might only need the last 7 days of data to capture current trends, with most queries focusing on the last 24 hours.
|
||||
|
||||
Storing everything in Qdrant collection with default sharding can lead to expensive re-indexing across the entire dataset when deleting old points, impacting performance. A better solution is **time-based sharding**, where points are routed to a specific [shard (or shards)](/documentation/operations/distributed_deployment/#sharding) based on timestamp. For use cases with a natural time-to-live (TTL) segmentation, sharding by a timestamp-based key enables efficient querying of recent data and allows users to seamlessly drop the old.
|
||||
Storing everything in Qdrant collection with default sharding can lead to expensive re-indexing across the entire dataset when deleting old points, impacting performance. A better solution is **time-based sharding**, where points are routed to a specific [shard (or shards)](/documentation/distributed_deployment/#sharding) based on timestamp. For use cases with a natural time-to-live (TTL) segmentation, sharding by a timestamp-based key enables efficient querying of recent data and allows users to seamlessly drop the old.
|
||||
|
||||
For example, with daily shards, today's data is stored in today's shard, yesterday's data in yesterday's shard, and so on. Queries can target specific shards (today's shard, for example) or multiple shards to cover a date range.
|
||||
|
||||
@@ -44,7 +44,7 @@ This tutorial assumes you are using [Qdrant Cloud Inference](/documentation/infe
|
||||
|
||||
## Create Collection
|
||||
|
||||
Create a collection with [user-defined sharding](/documentation/operations/distributed_deployment/#user-defined-sharding) by setting the sharding method to custom.
|
||||
Create a collection with [user-defined sharding](/documentation/distributed_deployment/#user-defined-sharding) by setting the sharding method to custom.
|
||||
|
||||
{{< code-snippet path="/documentation/headless/snippets/time-based-sharding/" block="create-collection" >}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user