anchor.diff:  
   For the vast majority of cases, using only one node on the {es} side should pose no problem - if the network is not saturated, {es} can ingest the data just fine. However, for cases where this happens (again benchmark first instead of guessing), we are working on using multiple nodes based on the available index.
   
  +[[arch-colocation]]
  +[float]
   === Data co-location
   
   Whenever possible, {eh} shares the {es} cluster information with Hadoop to facilitate data co-location. In practice, this means whenever data is read from {es}, the source nodes IPs are passed on to Hadoop to optimize task execution. If co-location is desired/possible, hosting the {es} and Hadoop clusters within the same rack will provide significant network savings.
positive.code: 
  A common concern (read optimization) for improving performance is to increase the number of shards and thus increase the number of tasks on the Hadoop side. Unless such gains are demonstrated through benchmarks, we recommend against such a measure since in most cases, an {es} shard can *easily* handle data streaming to a Hadoop task.
  
  === Writing to {es}
  
  Writing to {es} is driven by the number of input splits (or Hadoop tasks) available. In the current form, {eh} uses only one node on the {es} side to handle the writing which acts as a proxy within the {es} cluster: as data flows in, based on its identity and cluster setting, {es} will route it to the appropriate shard.
  
negative.code: 
  TIP: Hadoop `splits` as well as {es} `shards` play an important role regarding a system behavior - we recommend familiarizing with the two concepts to get a better understanding of your system runtime semantics.
  
  [[arch-reading]]
  [float]
  === Reading from {es}
  
  Shards play a critical role when reading information from {es}. Since it acts as a source, {eh} will create one Hadoop `InputSplit` per {es} shard; that is given a query that works against index `I`, {eh} will dynamically discover the number of shards backing `I` and then for each shard will create an input split (which will determine the number of Hadoop tasks to be executed).
  