Tribe node - performance cost?

(DH) #1

Hi, everyone.

I have a few questions regarding that new feature, the tribe nodes.
It seems, at first glance, incredibly usefull, offering great scalability.
(why would I bring new nodes to my cluster, when I can bring a whole new
cluster instead?)

What I'm worried about is the performance cost of using such a node.
In our project, here, we have a really big cluster, full of really
complicated documents. (many fields, collections and sub-collection).
There are actually two kinds of docs, and we never have to request on the
two kinds at the same time. However, to request on those documents, we need
info (I'll call them "metadata") located in the cluster.

Thats why I'm currently considering splitting my cluster in 3. Two big ones
(data 1 and data 2) and a small one (metadata).
That would, I think, increase the availability of my data. If data 1 were
to fail, I could still request on data 2, so only half of my application
would be inaccessible.

However, I'm wondering about the tribe node .. must it be powerfull? More
than or less than my data nodes?
And, more importantly, the requests need to be fast (and boy, are they
fast) .. would the use of a tribe node slows them?
Does anyone have any experience to share with that feature?


You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit
For more options, visit

(system) #2