ElasticSearch is incredibly well architectured and easy to use.
To simplify data center operations, I am considering switching my current
app architecture from separated processes (app server instances separated
from elasticsearch instances) to each elasticsearch instance being embedded
inside an app server instance.
To clusterize app server instances, I was using until now JGroup. However I
don't need the full power of JGroups, my needs are very limited: be
notified of cluster changes, and send messages reliably across the cluster.
Also, having within the same java process 2 different ways to clusterize
the operations (jgroups and elasticsearch internal mechanism) and as a
consequence 2 different cluster states at the same time seem to me very
unnatural, and maybe bug-prone.
As a consequence, I am researching reusing elasticsearch cluster management
functionalities.
With that objective, be notified of cluster changes seems ok, but sending
messages across the cluster seems challenging: it seems there is no way to
leverage the cluster API of elastic search to send new types of messages?
I know this goes far from the initial elastic search mandate, but it shows
a general direction about elasticsearch making java stacks simpler:
elasticsearch was focused on full text search, then some people are using
it as a document store (like us), so the next step would be to leverage its
cluster capabilities instead of rebuilding it separately.
On the same topic, is there a programmatic way to retrieve the netty
instance initialized by elasticsearch?
Very interesting. We are considering using the embedded ES approach in one
of our products, too, though I don't think we need cluster awareness in the
apps.
If I understand what you are asking whether ES can provide, wouldn't that
be a bit like (reimplementing) Apache ZooKeeper?
On Wednesday, January 16, 2013 2:32:47 PM UTC-5, Raphael Geronimi wrote:
Hello,
Elasticsearch is incredibly well architectured and easy to use.
To simplify data center operations, I am considering switching my current
app architecture from separated processes (app server instances separated
from elasticsearch instances) to each elasticsearch instance being embedded
inside an app server instance.
To clusterize app server instances, I was using until now JGroup. However
I don't need the full power of JGroups, my needs are very limited: be
notified of cluster changes, and send messages reliably across the cluster.
Also, having within the same java process 2 different ways to clusterize
the operations (jgroups and elasticsearch internal mechanism) and as a
consequence 2 different cluster states at the same time seem to me very
unnatural, and maybe bug-prone.
As a consequence, I am researching reusing elasticsearch cluster
management functionalities.
With that objective, be notified of cluster changes seems ok, but sending
messages across the cluster seems challenging: it seems there is no way to
leverage the cluster API of Elasticsearch to send new types of messages?
I know this goes far from the initial Elasticsearch mandate, but it shows
a general direction about elasticsearch making java stacks simpler:
elasticsearch was focused on full text search, then some people are using
it as a document store (like us), so the next step would be to leverage its
cluster capabilities instead of rebuilding it separately.
On the same topic, is there a programmatic way to retrieve the netty
instance initialized by elasticsearch?
However our initial goal was to simplify the software stack, not add extra
components in the architecture. Because, from a functional point of view,
we don't need the extra power of JGroup or ZooKeeper (in fact 80% of the
cluster projects I have seen do not need that level of features).
We just need a simple foundation to:
-Store documents
-Full text index them
-Publish pages through a Netty instance
-In an elastic cluster of server (cloud) with cross-servers messaging
Surprisingly, we discovered that elasticsearch is 2 inches away from that.
We are just looking for a solution to cover the last 2 inches.
Raphael
On Thursday, 17 January 2013 15:41:43 UTC+1, Otis Gospodnetic wrote:
Hello Raphael,
Very interesting. We are considering using the embedded ES approach in
one of our products, too, though I don't think we need cluster awareness in
the apps.
If I understand what you are asking whether ES can provide, wouldn't that
be a bit like (reimplementing) Apache ZooKeeper?
On Wednesday, January 16, 2013 2:32:47 PM UTC-5, Raphael Geronimi wrote:
Hello,
Elasticsearch is incredibly well architectured and easy to use.
To simplify data center operations, I am considering switching my current
app architecture from separated processes (app server instances separated
from elasticsearch instances) to each elasticsearch instance being embedded
inside an app server instance.
To clusterize app server instances, I was using until now JGroup. However
I don't need the full power of JGroups, my needs are very limited: be
notified of cluster changes, and send messages reliably across the cluster.
Also, having within the same java process 2 different ways to clusterize
the operations (jgroups and elasticsearch internal mechanism) and as a
consequence 2 different cluster states at the same time seem to me very
unnatural, and maybe bug-prone.
As a consequence, I am researching reusing elasticsearch cluster
management functionalities.
With that objective, be notified of cluster changes seems ok, but sending
messages across the cluster seems challenging: it seems there is no way to
leverage the cluster API of Elasticsearch to send new types of messages?
I know this goes far from the initial Elasticsearch mandate, but it
shows a general direction about elasticsearch making java stacks simpler:
elasticsearch was focused on full text search, then some people are using
it as a document store (like us), so the next step would be to leverage its
cluster capabilities instead of rebuilding it separately.
On the same topic, is there a programmatic way to retrieve the netty
instance initialized by elasticsearch?
Hello, I know this topic is very old, and es is way ahead now, but I'm having the same problem to solve. I'd like to have a simple cluster which would do a simple thing:
one node asks everybody - do you have this?
if someone replied - I do, the requester say directly to the node - give it to me.
if no node has it, it will create it, and next time if someone would ask, it could provide it.
The critical part of the Custer is autodiscovery, since nodes could be added and removed constantly. And ES is great with autodiscovery.
Currently, I'm using JGroups, and I'm not an expert in networking and protocols, so, I'm kind of lost here, because everything works on my local envirement, but when I deploy on machines from data center it doesn't. And I was told that the reason is the DC network doesn't work with multicast. I suspect that I can do something about it in jgroups, but on another hand ES just works on the same network with no problem.
So, if you figure out the way how to use ES clustering functionality without using indexing and searching, please share your ideas, or even maybe some examples.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.