Hola Manuel,
Eso depende del caso. En este hilo hay una buena explicación de mis compañeros.
Para ingesta, hay varias cosas a tener en cuenta.
- Si estás usando pipelines de ingesta, y estas ves que usan bastantes recursos (habitualmente CPU), se puede plantear tener nodos dedicados de ingesta. De forma que esas pipelines se ejecutaran allí. Eso descargaría los nodos de datos de realizar transformaciones, dejándoles solo la escritura. Si usas Logstash es poco probable que transformes en Elasticsearch usando pipelines de ingesta, quizás las transformaciones las haces ya en Logstash.
- Si no es el caso, recomendamos incluir nodos de coordinación en clusters grandes. Y aún así, hay que probar si tiene ventajas en tu caso concreto. 4 nodos sería un caso de cluster pequeño, y 12 es un cluster mediano/grande.
Lo que sí es importante, en cualquier caso, es que la ingesta no se dirija a los nodos masters dedicados, y que se reparta entre todos los nodos de datos o de coordinación dedicados.
Te recomendaría testear en tu caso si hay ventajas usando nodos de coordinación para la ingesta. Va a depender mucho de dónde esté el cuello de botella.
Si ves que el cuello de botella está en escritura en disco, por ejemplo, quizás sale mas a cuenta escalar añadiendo un nodo de datos que nodos dedicados de coordinación. Si está en la red, igual si los nodos de coordinación ayuden, ya que reducirían un poco el tráfico de red. Aun así, sin probarlo es difícil estimar el efecto que tendría en tu caso concreto.
En cualquier caso no lo complicaría demasiado separando la coordinación por fuente de ingesta. Si las fuentes balancean entre todos los nodos al ingestar, la carga de coordinación se reparte. Ya sea en nodos de datos que también coordinan, o en los nodos dedicados de coordinación.
El enrutado de documentos no será mas eficiente por tener pools dedicados de coordinación. Los documentos van a parar según su _id a un shard determinado, que vive en un nodo de datos. Ese nodo es el que hará el trabajo de escritura para cada shard.
Si no usas shard allocation filtering para que índices/shards de una fuente vayan a parar a nodos concretos, cosa que no suele ser habitual, no tendrías ganancias de escritura. Y en la parte de coordinación el trabajo que se hace por fuente es parecido (si no hay pipelines de ingesta complejas). Al final los datos se van a escribir en los nodos donde estén los shards, y estarán en cualquier nodo del cluster.
Al crecer un cluster, para casos de uso de series temporales, es recomendable considerar una arquitectura hot-warm-cold. Con nodos de más rendimiento para la ingesta y búsquedas en datos recientes, y nodos warm o cold para datos más antiguos / que se consultan menos.