lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mathieu <>
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
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.

On Wed, 1 Oct 2008 09:12:41 -0300, "Marcelo Ochoa"
<> 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:
>   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:
>   Best regards, Marcelo.
> On Wed, Oct 1, 2008 at 4:43 AM, agatone <> 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:
>> Sent from the Lucene - Java Users mailing list archive at
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message