mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-27 06:58:30 +02:00
Grammar 🤦
This commit is contained in:
@@ -20,7 +20,7 @@ The ideal number of Qdrant nodes depends on how much you value cost-saving, resi
|
||||
- Performance: Limited to the resources of a single server.
|
||||
|
||||
- **Prioritizing resilience**: If resilience is most important to you, run a Qdrant cluster with three or more nodes and two or more shard replicas. Clusters with three or more nodes and replication can perform all operations even while one node is down. Additionally, they gain performance benefits from load-balancing and they can recover from the permanent loss of one node without the need for backups or snapshots (but backups are still strongly recommended). This is most recommended for production environments. Drawbacks:
|
||||
- Cost: Larger clusters are be more costly than smaller clusters, which is the only drawback of this configuration.
|
||||
- Cost: Larger clusters are 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 users find this drawback to be negligible.
|
||||
|
||||
Reference in New Issue
Block a user