Change No. of pindex

Full Text Search
1

Hi, I understand that the "total " value in FTS response is no. of pindex.

 "status": {
        "total": 6,
        "failed": 0,
        "successful": 6
    }

Is there anyway we can change it’s value? And how does it affect FTS performance?

2

Hi @Rajeev_Bhat,

If you are using the recent versions like 6.5, then one can edit this “numPartitions” in the index definition edit page.
Also, one can always update this over the index create/update endpoint.
ref - https://docs.couchbase.com/server/current/rest-api/rest-fts-indexing.html

One may use the below field to edit this attribute,
“planParams”: {
“maxPartitionsPerPIndex”: 171,

1024 (vbucket number) / 171 = 6 partitions.
ie maxPartitionsPerPIndex acts as the dividing factor to 1024 to compute the number of index partitions.

Given one has enough hardware resources to parallelise the work load, this helps in distributing the search/index work load. Too many partitions would also have the downside of heavy scatter gather costs.

If you have at least 1 core to spare per partition for search or indexing, then its a reasonable point to start with.

Cheers!

3

Thanks @sreeks.
Rajeev

4

Hi @sreeks I have 3 nodes in a cluster, each node has 10 processors, I want that at the time of a query, each processor addresses a partition of an FTS index. In theory If I have 3 homogenic nodes, and configure 30 partitions for an index, in each node there are 10 and in theory each query is parallelized between the 3 nodes and the 10 processors of each node, this is true?

5

@nelsonxx1 If you have 3 nodes with 10 partitions residing on each node, and a query comes in at one of the nodes - the request is propagated to each of the partitions in parallel as part of the scatter-gather operation.

Couchbase’s search service is implemented in golang - each of these subqueries is executed via a go routine.
The FTS process sets golang runtime’s GOMAXPROCS to the number of processors available on the node (unless explicitly overridden).
So in theory - yes it’s possible for subqueries on each node to be handled by all 10 processors in parallel.

Please be advised, that each node will wait on the sub queries of all its resident partitions - to merge the results and return them to the coordinating node (part of the scatter gather operation). The coordinating node is that node in the cluster where the query is received - where an additional results merging overhead is incurred.

We recommend that the application distribute it’s query workload uniformly across every node (hosting the search service) in the cluster. If you were to use one of the SDKs that couchbase provides to access the FTS service - then the SDK automatically does this for you.

6

OK @ABHINAV, I’m using the Python SDK 3.1. Then I do not have to worry about the load of the servers, that is, if I connect one and throw a N1QL or FTS query, I do not worry about pointing to the node that is most unemployed, since the DSK does that job for me. this is true?

7

@nelsonxx1, that is right!

8

Thanks @sreeks for responding. I have a problem and is that I am doing a dashboard and each statistic shown is an endpoint that makes a consultation for that statistic, by ending a count, a sum, a top 5, etc. I have problems with the amount of petitions that Control to the database to at the same time . I am currently working with version 6.6.0 Community and Law that the Free version only accepts 4 queries at the same time. I am use FTS Index to make statistics calculations based on a search parameter in several text compounds. Is there any way to optimize the response time in the FTS Index? The option to place the indications in memory is not available in the free version.