Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 60993 invoked from network); 15 Apr 2006 09:44:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Apr 2006 09:44:33 -0000 Received: (qmail 87172 invoked by uid 500); 15 Apr 2006 09:44:28 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 87134 invoked by uid 500); 15 Apr 2006 09:44:27 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 87123 invoked by uid 99); 15 Apr 2006 09:44:27 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Apr 2006 02:44:27 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [194.109.24.33] (HELO smtp-vbr13.xs4all.nl) (194.109.24.33) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Apr 2006 02:44:26 -0700 Received: from k8l.lan (porta.xs4all.nl [80.127.24.69]) by smtp-vbr13.xs4all.nl (8.13.6/8.13.6) with ESMTP id k3F9i5Zp096333 for ; Sat, 15 Apr 2006 11:44:05 +0200 (CEST) (envelope-from paul.elschot@xs4all.nl) From: Paul Elschot To: java-user@lucene.apache.org Subject: Re: Lucene Seaches VS. Relational database Queries Date: Sat, 15 Apr 2006 11:44:04 +0200 User-Agent: KMail/1.8.2 References: <3925693.post@talk.nabble.com> In-Reply-To: <3925693.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604151144.04830.paul.elschot@xs4all.nl> X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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