We are migrating our Lucene based search codebase to Elasticsearch. The
major problem we encountered is how we should migrate our QueryParsers.
In our old solution, the QueryParsers take in a human input query string,
and transform that to Lucene's Query object, which is then fed into
Lucene's IndexSearcher. However, in Elasticsearch we don't directly
interact with IndexSearcher, instead we can only build the queries in the
client side using Query DSL http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html and
send the JSON to Elasticsearch server. Elasticsearch server then (possibly)
rewrites/analyses the JSON query to build a Lucene query.
To make use of our existing and sophisticated logic in QueryParsers, we
decided that we can stick to our old approach by:
Explicitly tell Elasticsearch to NOT analyze any query in the
search time.
Do ALL the query related analysis (tokenizing, synonym, etc) in the
Java client.
Believe that Elasticsearch's Query DSL is kind of a one-to-one
mapping to Lucene's Query
The questions are:
Is this approach feasible?
What are the potential problems in doing so?
What is the best practice?
By the way, don't worry about the scoring process, we are writing our
scorer scripts as a Elasticsearch plugin.
Thank you!
Odin
On Friday, June 6, 2014 3:36:54 PM UTC+8, Jörg Prante wrote:
Please ask your question here. Thanks.
Jörg
On Fri, Jun 6, 2014 at 9:28 AM, ohw <o...@zhihu.com <javascript:>> wrote:
Hi folks
I just asked a question in StackOverflow, please have a look if you have
encountered similar problem or have some input to it.
The Query DSL is not equivalent to Lucene Query but close to, with
enhancements.
If you want to make use of Lucene Query, and you already decided to write a
plugin for scoring, so why don't you just add your query parsers to the
plugin?
Jörg
On Fri, Jun 6, 2014 at 9:39 AM, ohw ohw@zhihu.com wrote:
Sure, here it is:
We are migrating our Lucene based search codebase to Elasticsearch. The
major problem we encountered is how we should migrate our QueryParsers.
In our old solution, the QueryParsers take in a human input query string,
and transform that to Lucene's Query object, which is then fed into
Lucene's IndexSearcher. However, in Elasticsearch we don't directly
interact with IndexSearcher, instead we can only build the queries in the
client side using Query DSL http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html and
send the JSON to Elasticsearch server. Elasticsearch server then (possibly)
rewrites/analyses the JSON query to build a Lucene query.
To make use of our existing and sophisticated logic in QueryParsers, we
decided that we can stick to our old approach by:
Explicitly tell Elasticsearch to NOT analyze any query in the
search time.
Do ALL the query related analysis (tokenizing, synonym, etc) in
the Java client.
Believe that Elasticsearch's Query DSL is kind of a one-to-one
mapping to Lucene's Query
The questions are:
Is this approach feasible?
What are the potential problems in doing so?
What is the best practice?
By the way, don't worry about the scoring process, we are writing our
scorer scripts as a Elasticsearch plugin.
Thank you!
Odin
On Friday, June 6, 2014 3:36:54 PM UTC+8, Jörg Prante wrote:
Please ask your question here. Thanks.
Jörg
On Fri, Jun 6, 2014 at 9:28 AM, ohw o...@zhihu.com wrote:
Hi folks
I just asked a question in StackOverflow, please have a look if you have
encountered similar problem or have some input to it.
Thanks in advance!
--
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 elasticsearc...@googlegroups.com.
The Query DSL is not equivalent to Lucene Query but close to, with
enhancements.
If you want to make use of Lucene Query, and you already decided to write
a plugin for scoring, so why don't you just add your query parsers to the
plugin?
Jörg
On Fri, Jun 6, 2014 at 9:39 AM, ohw ohw@zhihu.com wrote:
Sure, here it is:
We are migrating our Lucene based search codebase to Elasticsearch. The
major problem we encountered is how we should migrate our QueryParsers.
In our old solution, the QueryParsers take in a human input query string,
and transform that to Lucene's Query object, which is then fed into
Lucene's IndexSearcher. However, in Elasticsearch we don't directly
interact with IndexSearcher, instead we can only build the queries in the
client side using Query DSL http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html and
send the JSON to Elasticsearch server. Elasticsearch server then (possibly)
rewrites/analyses the JSON query to build a Lucene query.
To make use of our existing and sophisticated logic in QueryParsers, we
decided that we can stick to our old approach by:
Explicitly tell Elasticsearch to NOT analyze any query in the
search time.
Do ALL the query related analysis (tokenizing, synonym, etc) in
the Java client.
Believe that Elasticsearch's Query DSL is kind of a one-to-one
mapping to Lucene's Query
The questions are:
Is this approach feasible?
What are the potential problems in doing so?
What is the best practice?
By the way, don't worry about the scoring process, we are writing our
scorer scripts as a Elasticsearch plugin.
Thank you!
Odin
On Friday, June 6, 2014 3:36:54 PM UTC+8, Jörg Prante wrote:
Please ask your question here. Thanks.
Jörg
On Fri, Jun 6, 2014 at 9:28 AM, ohw o...@zhihu.com wrote:
Hi folks
I just asked a question in StackOverflow, please have a look if you
have encountered similar problem or have some input to it.
Thanks in advance!
--
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 elasticsearc...@googlegroups.com.
the basic entry point code for how search works is in
org.elasticsearch.rest.action.search.RestSearchAction, if you want to
expose an enhanced search to REST
building the query works with
org.elasticsearch.search.builder.SearchSourceBuilder which has a convenient
method query(queryBuilder) for Java API
org.elasticsearch.indices.query.IndicesQueriesModule is responsible for
managing the query parsers, there are addQuery() and addFilter methods(),
these methods must be invoked at plugin initialization time
so you can write a pair of My...QueryBuilder and My...QueryParser for
each of your query in your plugin
copy/paste RestSearchAction to something like My...RestSearchAction with
a custom endpoint, for example _mysearch, and then you can use your query
implementation, wrapped in JSON, just like you would do in _search REST
action. The new REST endpoint must be registered in the plugin
initialization
for studying implementation details, the existing standard query
parser/builder impls in org.elasticsearch.index.query are useful
Jörg
On Fri, Jun 6, 2014 at 11:19 AM, Heng Wang ohw@zhihu.com wrote:
Thank you Jörg, I didn't realize that I can plug the query parsers into
elasticsearch, would you please elaborate more on this?
The Query DSL is not equivalent to Lucene Query but close to, with
enhancements.
If you want to make use of Lucene Query, and you already decided to write
a plugin for scoring, so why don't you just add your query parsers to the
plugin?
Jörg
On Fri, Jun 6, 2014 at 9:39 AM, ohw ohw@zhihu.com wrote:
Sure, here it is:
We are migrating our Lucene based search codebase to Elasticsearch. The
major problem we encountered is how we should migrate our QueryParsers.
In our old solution, the QueryParsers take in a human input query
string, and transform that to Lucene's Query object, which is then fed
into Lucene's IndexSearcher. However, in Elasticsearch we don't directly
interact with IndexSearcher, instead we can only build the queries in the
client side using Query DSL http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html and
send the JSON to Elasticsearch server. Elasticsearch server then (possibly)
rewrites/analyses the JSON query to build a Lucene query.
To make use of our existing and sophisticated logic in QueryParsers, we
decided that we can stick to our old approach by:
Explicitly tell Elasticsearch to NOT analyze any query in the
search time.
Do ALL the query related analysis (tokenizing, synonym, etc) in
the Java client.
Believe that Elasticsearch's Query DSL is kind of a one-to-one
mapping to Lucene's Query
The questions are:
Is this approach feasible?
What are the potential problems in doing so?
What is the best practice?
By the way, don't worry about the scoring process, we are writing our
scorer scripts as a Elasticsearch plugin.
Thank you!
Odin
On Friday, June 6, 2014 3:36:54 PM UTC+8, Jörg Prante wrote:
Please ask your question here. Thanks.
Jörg
On Fri, Jun 6, 2014 at 9:28 AM, ohw o...@zhihu.com wrote:
Hi folks
I just asked a question in StackOverflow, please have a look if you
have encountered similar problem or have some input to it.
Thanks in advance!
--
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 elasticsearc...@googlegroups.com.
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.