We are testing with 3 FTS servers with 1 index that has 1 replica and 6 partition.
- How is the index distributed across the servers?
- How is the partition work across multiple servers?
- What is the benefit of increasing the partition?
- Firstly here’s how your couchbase cluster with 3 nodes running FTS service for an index with 1 replica and 6 partitions would look …
NODE 1 NODE 2 NODE 3
+-----------------+ +-----------------+ +-----------------+
| Active: 1 | | Active: 3 | | Active: 5 |
| Active: 2 | | Active: 4 | | Active: 6 |
| Replica: 5 | | Replica: 1 | | Replica: 3 |
| Replica: 6 | | Replica: 2 | | Replica: 4 |
+-----------------+ +-----------------+ +-----------------+
-
Active and Replica partitions for an index are uniformly distributed across all nodes in your cluster - with a replica not residing on the same node as an active. When a search request arrives at one of the nodes - the coordinating node becomes the orchestrator which scatters the request across all the nodes carrying the active partitions. All the results from each of the active partitions are collected and merged at the coordinating node which are then returned to the user. Replica partitions remain available for the sole purpose of high availability when any of the active partitions become unavailable.
-
One can view partitions not only as a way to distribute your index across several nodes, but also as a way to increase the index build time. Each partition is it’s own sub index that can simultaneously index content. Be aware that by increasing the partition count - you would incur additional resource consumption (network/connections) as each partition sets up its’ own set of connections to the nodes that host the couchbase bucket. Also, a search request could potentially run a bit slower due to higher cost of merging results from more active partitions.