Please excuse the naivety here. I'm trying to translate from a SOLR
background, where we had up a ton of read-only query slaves, and a couple
masters to handle the write traffic.
Here is our situation:
We have a set of REST-based web services that act as a thin translation
layer on top of Elastic Search. Those web services are hosted in
DropWizard (Jetty). From those JVMs, we connect to Elastic Search using
the Elastic Search Java API. We are trying to figure out the best
deployment topology to scale out the system.
We've seen mention of using non-data nodes to handle the incoming queries.
Those nodes front the actual data nodes, handling the HTTP traffic. We've
also seen mention of making those the master nodes. What is the best
practice here? Something like this...?
HTTP -> Jetty -> HTTP Load Balancer -> Non-Data Nodes (Masters) -> Data
We were wondering, if we just create non-data embedded nodes within the
JVM's hosting the REST services, does this achieve the same goal of
offloading the HTTP connections from the data nodes? Effectively, the JVM
hosting the REST-based services becomed the buffer between the HTTP
connections and the data nodes. In this scenario we would have...
HTTP -> Jetty w/ Embedded ES node -> Data Nodes
This seems reasonable, but we weren't sure the impact as we scale the # of
REST hosts (and consequently, the # of ES nodes)
Anyone have any links, or advice you can share?
thanks -- still a noob at scaling ES,
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.