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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
