A newer version of this documentation is available.

View Latest

Index Service nodes

A node running the Index Service must be sized properly to create and maintain secondary indexes and to perform index scan for N1QL queries.

Similarly to the nodes running the data service, there is a set of questions you need to answer to take care of your application needs:

  1. What is the length of the document key?

  2. Which fields need to be indexed?

  3. Will you be using simple or compound indexes?

  4. What is the minimum, maximum, or average value size of the index field?

  5. How many indexes do you need?

  6. How many documents need to be indexed?

  7. How often do you want compaction to run?

Answers to the above questions can help you better understand the capacity requirement of your cluster and provide a better estimation for sizing. At Couchbase, we looked at performance data and customer use cases to provide sizing calculations for each of the areas: CPU, Memory, Disk and Disk I/O.

Here is a disk size example:

Table 1. Disk sizes
Input variable Value

docID

20 bytes

Number of index fields

1

Secondary index

24 bytes

Number of documents to be indexed

20M

When we calculate disk usage for the above test cases, there are a few factors we need to keep in mind:

  1. Compaction is disabled. This case illustrates the worst-case scenario for disk usage.

  2. Couchbase Server uses an append-only storage format. Therefore, actual disk usage will be larger than data size.

  3. Fragmentation will affect the disk usage. The larger the fragmentation, the more disk you will need.

Based on our experiment, we noticed that the above index consumes 6GB of disk space.