I have a Node.js app that runs a N1QL query to create some indexes:
CREATE INDEX ix_1 ON test_bucket (field1) USING GSI;
CREATE INDEX ix_2 ON test_bucket (field2) USING GSI;
CREATE INDEX ix_3 ON test_bucket (field3) USING GSI;
Does this mean that ix_1 only exists on IP1, and not on IP2 and IP3? If a query is executed against IP2 or IP3, does a table scan happen? How do I explicitly create the index on a particular node from the Node.js driver?
My code:
var cluster = new couchbase.Cluster(“couchbase://IP1,IP2,IP3”);
var query = “CREATE INDEX ix_1 ON test_bucket (field1) USING GSI”;
var n1qlQuery = couchbase.N1qlQuery.fromString(query);
bucket.query(n1qlQuery, function (err, result) {});
The node specification when creating an index specifies which node in your cluster will contain the data for that index. You are free to query any of the nodes in the cluster and it will read from that index though (ie: querying from Node2 will still read an index that is on Node1).
I am still a bit confused. I thought GSI is located on each instance of the cluster that has the Query service. if querying node2 will read from the index that is located on node1, wouldn’t that require an extra network hop?
In EE releases, each node can have independent services. You need not have the index service on a query node.
You are correct about the extra network hop. It’s my understanding that there is not currently an optimization for using the closest index when the same index definition is in multiple locations.
Yes. Query will use the best fit Index irrespective of the location of the index. When multiple best fits exist (for example: several identical indexes), it will load balance. The link between N1QL and GSI uses an efficient binary format and maintains a connection pool, so local vs non-local should not have a noticeable impact unless the interconnect is unusually slow. For EE users (especially 4.5 memory optimized indexes), running Indexes on separate node(s) is usually the best topology choice.
(Note: It is possible to configure the load balancing to use a local index over a remote one if the interconnect is measurably slow; but it is almost never necessary, and may skew load balancing, so I won’t dive into that in detail)