lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: Lucene Seaches VS. Relational database Queries
Date Sat, 15 Apr 2006 09:44:04 GMT
On Saturday 15 April 2006 03:36, Jeryl Cook wrote:
> 
> Im the co-worker who suggested to Ananth( I've think we have been debating
> this for 3 days now,from the post it seems he is winning :)... )
> 
> Anway, as Ananth stated I suggested this because I am wondering if  lucene
> could solve a bottle neck query that is taking a deathly long time to
> complete(read-only)....and the orginal design actually generated a threaded
> 60+ queries on the database to return results per userThread who hit our
> website for this view..., I know that this will kill our server when
> user-load increases...i know that lucene is built for speed and can handle a
> very large number of peopel searching(we are using singleton Searcher), and

One way to have more queries per second with a singleton Searcher is
by merging the retrievals of documents for multiple queries.
This will increase query throughput (less disk head movement) but it will
also increase the response time for the individual queries.

> the (threaded)results will be the "hits" returned from lucene.. , also this
> query will NOT be executed by any user in a text field , but rather in our
> application code only when user selects differnt parts of the site...if all
> values in this 1:n relationship we are trying to query in lucene then the
> "application-provided" query will return accurate results.  

To follow 1:n relationships avoid using Hits, use your own HitCollector
instead. From application code, try and use TermDocs from the index
reader.
 
> we are using Quartz, and not creating threads in servlets...
> 
> FINAL SOLUTION MAYBE?:
> if our client EVER gives us a requirement that says we must have accurate
> text-searching even if somthing on our index for  1:  "Jason" and "Jason
> Black" relationship, then we should just simply say we cannot implement this
> because  lucene search will yield inaccurate results correct???????
> 
> comments?

Assuming I understand the problem correctly, one can solve this by
indexing such fields twice: once as keyword to search for the specific
individual, and once with indexed terms to search for name(s). 
In both fields one could use an extra word from a relational db,
for example a client id.

Regards,
Paul Elschot


> View this message in context: 
http://www.nabble.com/Lucene-Seaches-VS.-Relational-database-Queries-t1434583.html#a3925693
> Sent from the Lucene - Java Users forum at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message