lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mathieu <math...@garambrogne.net>
Subject Re: Lucene vs. Database
Date Wed, 01 Oct 2008 12:38:23 GMT

Crawling a DB is not a good idea. Indexing while writing/deleting is
clever.
Doing it inside the DB is a solution.
Java users like ORM. Compass plug Lucene indexation in the ORM's
transaction. If it's wrote or deleted, Lucene is aware.
Compass is opensource.

M.
On Wed, 1 Oct 2008 09:12:41 -0300, "Marcelo Ochoa"
<marcelo.ochoa@gmail.com> wrote:
> Hi Zoran:
>   One of the biggest issues with Lucene DB integration is the network
> traffic consumed as consequence of indexing or updating operation,
> apart from transactionalbilty which can be relaxed in some
> application.
>   During our Oracle Open World presentation we present some of these
> issues comparing performance during indexing time (integrated solution
> versus middle tier solution), network traffic, executions plans and
> others.
>   Obviously its based on Oracle databases but the concepts are similar
> for any other solutions.
>   You can download the complete presentation from:
> http://www28.cplan.com/cbo_export/208/PS_S298820_298820_208-1_v1.pdf
> http://www28.cplan.com/cbo_export/208/PS_S298820_298820_208-1_v2.pdf
>   To download presentations, please enter the following when prompted.
> Note the Username and Password are case sensitive.
> Username: cboracle
> Password: oraclec6
>   Or you can see on-line only the Oracle Lucene integration details
> using Google docs at:
> http://docs.google.com/Presentation?id=ddgw7sjp_156gf9hczxv
>   Best regards, Marcelo.
> 
> On Wed, Oct 1, 2008 at 4:43 AM, agatone <zoran.zoki@gmail.com> wrote:
>>
>> Hi,
>> I asked this question already on "lucene-general" list but also got
> advised
>> to ask here too.
>>
>> I'm working on a project that has big database in the background (some
>> tables have about 1500000 rows). We decided to use Lucene for "faster"
>> search. Our search works similar as all searches: you write search
> string,
>> get list of hits with detail link. But there is dilemma if we should
> store
>> more data into index than it's needed.
>>
>> One side of developing team insists that we should use lucene index as
>> somekind of storage for data so when you get hit, you go onto details
> and
>> then again use lucene to find document that matches the selected ID and
> take
>> the data from Lucene index. So in the end you end with copying complete
>> database tables into the lucene index.
>>
>> Other side insists on storing to index only data that is displayed
> directly
>> to the user when showing the search results list and needed for search
>> criteria. When you go onto details, you have the matching ID so you can
>> pickup that row from database by that ID rather than search it inside
> Lucene
>> index.
>>
>> Can someone please describe drawbacks and advantages of both approaches.
>> Actually can someone write down what's the actual profit, where and when
> of
>> the Lucene itself in real production env.
>>
>> IT would be great if there is anyone who could write his experience with
>> indexing and searching large amount of data.
>>
>>
>> Thank you
>> --
>> View this message in context:
> http://www.nabble.com/Lucene-vs.-Database-tp19755932p19755932.html
>> Sent from the Lucene - Java Users mailing list archive at Nabble.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


Mime
View raw message