CODEWITHSUNDEEP
elasticsearchluceneelasticsearch-5
Ali
Ali

Reputation: 1879

How to segregate Elasticsearch index and search path as much as possible

I am planning to segregate Elasticsearch index and search requests as much as possible to avoid any unnecessary delay in the indexing process. There is no such a thing as an Elasticsearch dedicated search node or index node. However, I was wondering if the following scenario is suitable. As far as I understood, I cannot segregate search requests from index requests completely because at the end both hit ES data nodes, but it is what I think can help a little:

In this case, the receiving data node will act as a coordinator node for indexing path and dedicated coordinator nodes will be used to route to a replica on data nodes. Data node unnecessary load due to search routing can be minimised.

I was wondering if there is another way to provide segregation at a higher level or I am insane to not use coordinator nodes for the indexing path as well.

P.S: My use case is heavy indexing and light/medium search

Upvotes: 0

Views: 465

Answers (1)

Thomas Decaux
Thomas Decaux

Reputation: 22701

You cant separate indexing and search operations, indexing will write on the primary shard, then on the replica shard, whereas search can be done only on primary shards.

If you care about write performance:

  • no replica
  • refresh_interval > 30s, keep analyzer simple
  • lot of shards (across data nodes)
  • send insert/update queries on data nodes directly
  • try to have a hot/cold data architecture (hot/cold indices)

Coordinator nodes can not improve search performance at all, this depends on your workload (aggs etc...).

As usually, all tuning stuff depend on your data and usage, you must find the good balance between indexation and searching performance, use the _node/stats endpoint to see whats going on.

Upvotes: 1

Related Questions