OpenSearch nodes, indices, shards, and replicas
Understand the main concepts of the OpenSearch database: nodes, indices, shards, and replicas.
OpenSearch do not use the
term database
, but search and analytics suite
. For simplicity, in API Connect the terms
analytics database
or OpenSearch database
are used
instead of search and analytics suite
.
The term OpenSearch
cluster
is used when referring to the analytics subsystem of a multi-replica API Connect deployment.
- Nodes
- An OpenSearch cluster is
made up of separate OpenSearch
nodes. On Kubernetes, an analytics storage pod replica runs a single OpenSearch node.
You control the number of OpenSearch nodes that you have when you select your API Connect deployment profile: A one replica deployment has one OpenSearch node. A three replica deployment has three OpenSearch nodes.
If you installed a three replica deployment on Kubernetes or OpenShift, you can enable the dedicated storage feature to increase your number of OpenSearch nodes above three.
- Indices
- Your analytics API event data is stored in OpenSearch indices. The creation and
management of your analytics indices is time-based. By default, your OpenSearch database creates
a new index each day to be used for storing the API events that arrive that day; so on the day of
installation your analytics subsystem has 1 index for API event data, and after 10 days your
subsystem has 10 API event data indices. The maximum number of days that API event data is stored
depends on your deployment profile, see Retention and rollover.
API Connect also creates indices for shared queries and for API summary data. By default API summary indices are kept for 1 year.
You can configure the retention and rollover periods for API event and summary data to suit your requirements and available storage space.
- Shards
- To efficiently distribute the data in OpenSearch indices across a cluster,
the indices are subdivided into what are called
shards
, which can be stored in different nodes of the cluster. - Replicas
-
In a three node OpenSearch deployment, each shard (known as the
primary shard
) has 2 replica shards that contain a copy of the data that is in the primary shard. OpenSearch stores the primary shard and each replica on different nodes to ensure that all data is available on all nodes, and to provide high-availability if one node fails.A single node OpenSearch deployment has no replica shards, since no other nodes are available to store them.