I'm new to ElasticSearch but come from a fair amount of experience
with another HTTP wrapper for Lucene which shall remain nameless. I
gather from earlier mailing list posts that ES has a plugin
architecture, but I can't for the life of me find a shred of
documentation on it. In particular, I'm looking for basics like what
endpoints in the HTTP API are available to plugin authors, basic
plugin configuration, etc. Is there anything out there someone can
point me to?
I'm new to Elasticsearch but come from a fair amount of experience
with another HTTP wrapper for Lucene which shall remain nameless. I
gather from earlier mailing list posts that ES has a plugin
architecture, but I can't for the life of me find a shred of
documentation on it. In particular, I'm looking for basics like what
endpoints in the HTTP API are available to plugin authors, basic
plugin configuration, etc. Is there anything out there someone can
point me to?
I think that you're thinking of plugins in the wrong way. They are not
the equivalent of solr's request handlers. They are used to extend the
core functionality of Elasticsearch itself, eg adding thrift transport,
or scripting via javascript etc
Unlike solr, you send your search requests directly to Elasticsearch,
either over HTTP (using one of the many APIs that are available for eg
Perl, Ruby, Python, PHP etc) or via the Java API, which speaks
Elasticsearch's own protocol.
Thanks for the response. So an example of something I was hoping to
use the plugin architecture for is to add support equivalent to Solr's
TermsComponent -- to expose a bit of Lucene functionality that ES
currently doesn't. Are plugins not the correct avenue to take for
something like that? If not, does ES give me an option there, other
than patching the project itself?
I'm new to Elasticsearch but come from a fair amount of experience
with another HTTP wrapper for Lucene which shall remain nameless. I
gather from earlier mailing list posts that ES has a plugin
architecture, but I can't for the life of me find a shred of
documentation on it. In particular, I'm looking for basics like what
endpoints in the HTTP API are available to plugin authors, basic
plugin configuration, etc. Is there anything out there someone can
point me to?
I think that you're thinking of plugins in the wrong way. They are not
the equivalent of solr's request handlers. They are used to extend the
core functionality of Elasticsearch itself, eg adding thrift transport,
or scripting via javascript etc
Unlike solr, you send your search requests directly to Elasticsearch,
either over HTTP (using one of the many APIs that are available for eg
Perl, Ruby, Python, PHP etc) or via the Java API, which speaks
Elasticsearch's own protocol.
Thanks for the response. So an example of something I was hoping to
use the plugin architecture for is to add support equivalent to Solr's
TermsComponent -- to expose a bit of Lucene functionality that ES
currently doesn't. Are plugins not the correct avenue to take for
something like that? If not, does ES give me an option there, other
than patching the project itself?
Plugins probably are the right place to do this, but I'm not a Java
programmer, so take anything I say with a pinch of salt.
From what I've seen though, exposing these things is not always as
simple as it may seem, as it has to take the distributed nature of ES
into account. YMMV.
Thanks for the response. So an example of something I was hoping to
use the plugin architecture for is to add support equivalent to Solr's
TermsComponent -- to expose a bit of Lucene functionality that ES
currently doesn't. Are plugins not the correct avenue to take for
something like that? If not, does ES give me an option there, other
than patching the project itself?
Plugins probably are the right place to do this, but I'm not a Java
programmer, so take anything I say with a pinch of salt.
From what I've seen though, exposing these things is not always as
simple as it may seem, as it has to take the distributed nature of ES
into account. YMMV.
You can write something like the terms API as a plugin. The design of elasticsearch is quite open, basically, any API could have been written as a plugin). You can bind your own transport APIs, own REST endpoints, serialization, and so on. "Getting" those is also simple, as its all wired using Guice.
The thing that is not that simple, at least at the beginning, is getting familiar enough with the elasticsearch codebase to understand how all of this fits....
-shay.banon
On Friday, July 8, 2011 at 4:03 PM, Matthew A. Brown wrote:
Thanks for the response. So an example of something I was hoping to
use the plugin architecture for is to add support equivalent to Solr's
TermsComponent -- to expose a bit of Lucene functionality that ES
currently doesn't. Are plugins not the correct avenue to take for
something like that? If not, does ES give me an option there, other
than patching the project itself?
Plugins probably are the right place to do this, but I'm not a Java
programmer, so take anything I say with a pinch of salt.
From what I've seen though, exposing these things is not always as
simple as it may seem, as it has to take the distributed nature of ES
into account. YMMV.
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.