Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 68532 invoked from network); 11 Apr 2008 17:30:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Apr 2008 17:30:36 -0000 Received: (qmail 25884 invoked by uid 500); 11 Apr 2008 17:30:29 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 25848 invoked by uid 500); 11 Apr 2008 17:30:29 -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 25832 invoked by uid 99); 11 Apr 2008 17:30:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Apr 2008 10:30:29 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [206.190.49.253] (HELO web52006.mail.re2.yahoo.com) (206.190.49.253) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 11 Apr 2008 17:29:35 +0000 Received: (qmail 60190 invoked by uid 60001); 11 Apr 2008 17:29:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3MjxyZPM4kXYKPUxRDJfWxNcU1EDipAE9hNdK/sOAfcMCxx+9bGxaJA1EDCXh+zXyUBRtj5GvtbTkN2fTUx47t+CygvZfeyH25bT40RxQ/m4EiVE/GJNaRsR47AaCik3NvjbbFgFcjC+RRni6/st5NNvlHMu7Cm5wcvSrTQRNG0=; X-YMail-OSG: 1mb8KYMVM1nWbo0X9nrKhwxgoOaDVqc6NavLaxEf Received: from [12.162.3.126] by web52006.mail.re2.yahoo.com via HTTP; Fri, 11 Apr 2008 10:29:54 PDT Date: Fri, 11 Apr 2008 10:29:54 -0700 (PDT) From: Rajesh parab Subject: Re: Lucene index on relational data To: java-user@lucene.apache.org In-Reply-To: <47FF1C96.3040604@garambrogne.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <563358.35242.qm@web52006.mail.re2.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org Thanks for these pointers Mathieu. We have earlier looked at Compass, but the main issue with database index is DB vendor support for BLOB locator. I understand that Oracle provides has this support to get the partial data from BLOB, but I guess the simiar support is not available in SQL Server and DB2. Our application currently supports all these 3 databases. Secondly I am reading that search performance degrades drastically with database index. Will it be possible to partition data like main index and relationship index using File System Lucne index and search across these indexes? Regards, Rajesh --- Mathieu Lecarme wrote: > Have a look at Compass 2.0M3 > http://www.kimchy.org/searchable-cascading-mapping/ > > Your multiple index will be nice for massive write. > In a classical > read/write ratio, Compass will be much easier. > > M. > > Rajesh parab a écrit : > > Hi, > > > > We are using Lucene 2.0 to index data stored > inside > > relational database. Like any relational database, > our > > database has quite a few one-to-one and > one-to-many > > relationships. For example, let’s say an Object > A has > > one-to-many relationship with Object X and Object > Y. > > As we need to de-normalize relational data as > > key-value pairs before storing it inside Lucene > index, > > we have de-normalized these relationships (Object > X > > and Object Y) while building an index on Object A. > > > > We have large no of such object relationships and > most > > of the times, the related objects are modified > more > > frequently than the base objects. For example, in > our > > above case, objects X and Y are updated in the > system > > very frequently, whereas Object A is not updated > that > > often. Still, we will need to update Object A > entries > > inside the index, every time its related objects X > > and/or Y are modified. > > > > To avoid the above situation, we were thinking of > > having 2 separate indexes – first index will > only > > index data of base objects (Object A in above > example) > > and second index will contain data about its > > relationship objects (Object X and Y above), which > are > > updated more frequently. This way, the more > frequent > > updates to Object X and Y will only impact second > > index that stores relationship information and > reduce > > the cost to re-index object A. However, I don’t > think, > > MultiSearcher will be helpful if we want to search > for > > data which spans across both indexes (e.g. some > fields > > of Object A in first index and some fields of > Object X > > or Y in second index). > > > > Do we have any option in Lucene to handle such > > scenario? Can we search across multiple indexes > which > > have some relationships between them and search > for > > fields that span across these indexes? > > > > Regards, > > Rajesh > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > java-user-unsubscribe@lucene.apache.org > > For additional commands, e-mail: > java-user-help@lucene.apache.org > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: > java-user-help@lucene.apache.org > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org