mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-27 06:58:30 +02:00
Merge pull request #719 from qdrant/fix/mac/grammar1
Fix grammar in two places, and mention client version compatibility
This commit is contained in:
@@ -17,7 +17,7 @@ Please read more about collections, isolation, and multiple users in our [Multit
|
||||
### My search results contain vectors with null values. Why?
|
||||
|
||||
By default, Qdrant tries to minimize network traffic and doesn't return vectors in search results.
|
||||
But you can force Qdrant to do so by setting the `with_vector` parameter of the Search/Scroll to `true`.
|
||||
But you can force Qdrant to do so by setting the `with_vector` parameter of the Search/Scroll to `true`.
|
||||
|
||||
If you're still seeing `"vector": null` in your results, it might be that the vector you're passing is not in the correct format, or there's an issue with how you're calling the upsert method.
|
||||
|
||||
@@ -47,13 +47,13 @@ What Qdrant doesn't plan to support:
|
||||
- Query analyzers and other NLP tools
|
||||
|
||||
Of course, you can always combine Qdrant with any specialized tool you need, including full-text search engines.
|
||||
Read more about [our approach](../../../articles/hybrid-search/) to hybrid search.
|
||||
Read more about [our approach](../../../articles/hybrid-search/) to hybrid search.
|
||||
|
||||
### How do I upload a large number of vectors into a Qdrant collection?
|
||||
|
||||
Read about our recommendations in the [bulk upload](../../tutorials/bulk-upload/) tutorial.
|
||||
|
||||
### Can I only store quantized vectors and discard full precision vectors?
|
||||
### Can I only store quantized vectors and discard full precision vectors?
|
||||
|
||||
No, Qdrant requires full precision vectors for operations like reindexing, rescoring, etc.
|
||||
|
||||
@@ -68,15 +68,14 @@ But in some cases, we might be able to help you with that through manual interve
|
||||
|
||||
### Do you support downgrades?
|
||||
|
||||
We does not support downgrading a cluster on any of our products. If you deploy a newer version of Qdrant, your
|
||||
We do not support downgrading a cluster on any of our products. If you deploy a newer version of Qdrant, your
|
||||
data is automatically migrated to the newer storage format. This migration is not reversible.
|
||||
|
||||
### How do I avoid issues when updating to the latest version?
|
||||
|
||||
We only guarantee compatibility if you update between consequent versions. You would need to upgrade versions one at a time: `1.1 -> 1.2`, then `1.2 -> 1.3`, then `1.3 -> 1.4`.
|
||||
We only guarantee compatibility if you update between consecutive versions. You would need to upgrade versions one at a time: `1.1 -> 1.2`, then `1.2 -> 1.3`, then `1.3 -> 1.4`.
|
||||
|
||||
### Do you guarantee compatibility across versions?
|
||||
|
||||
In case your version is older, we guarantee only compatibility between two consecutive minor versions.
|
||||
In case your version is older, we only guarantee compatibility between two consecutive minor versions. This also applies to client versions. Ensure your client version is never more than one minor version away from your cluster version.
|
||||
While we will assist with break/fix troubleshooting of issues and errors specific to our products, Qdrant is not accountable for reviewing, writing (or rewriting), or debugging custom code.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ The ideal number of Qdrant nodes depends on how much you value cost-saving, resi
|
||||
- Cost: Larger clusters are be more costly than smaller clusters, which is the only drawback of this configuration.
|
||||
|
||||
- **Balancing cost, resilience, and performance**: Running a two-node Qdrant cluster with replicated shards allows the cluster to respond to most read/write requests even when one node is down, such as during maintenance events. Having two nodes also means greater performance than a single-node cluster while still being cheaper than a three-node cluster. Drawbacks:
|
||||
- Resilience (uptime): The cluster cannot perform operations on collections when one node is down. Those operations require >50% of nodes to be running, so this is only possible in a 3+ node cluster. Since creating, editing, and deleting collections are usually rare operations, many user find this drawback to be negligible.
|
||||
- Resilience (uptime): The cluster cannot perform operations on collections when one node is down. Those operations require >50% of nodes to be running, so this is only possible in a 3+ node cluster. Since creating, editing, and deleting collections are usually rare operations, many users find this drawback to be negligible.
|
||||
- Resilience (data integrity): If the data on one of the two nodes is permanently lost or corrupted, it cannot be recovered aside from snapshots or backups. Only 3+ node clusters can recover from the permanent loss of a single node since recovery operations require >50% of the cluster to be healthy.
|
||||
- Cost: Replicating your shards requires storing two copies of your data.
|
||||
- Performance: The maximum performance of a Qdrant cluster increases as you add more nodes.
|
||||
|
||||
Reference in New Issue
Block a user