Solr vs Hibernate Search (Huge number of DB DMLs)

[fire fox <fy...@gmail.com>]

Hi all,
       There were several places I could find a discussion on this but I
failed to find the suited one for me.

I'd like to be clear on my requirements, so that you may suggest me the
better solution.

-> A project deals with tons of database tables (with *millions *of records)
out of which some are to be indexed which should be searchable of-course. It
uses Hibernate for MySQL transactions.

 As per my knowledge, there could be two solutions to maintain sync between
index and database effectively.

--> There'd be a *huge number of transactions (DMLs) on the DB*, so I'm
wondering which one of the following will be able to handle it
effectively.

 1) Configure *Solr *server, query it to search / send events to update.
This might be better than handling Lucene solely which provides index
read/write and load balancing. The problem here could be to implement &
maintain sync between index and DB with no lag as the updations (DMLs on DB)
are very frequent. Too many events to be sent!

 2) Using *Hibernate Search*. I'm just wondering about its
*performance*considering high volume of transactions on DB every
minute.

Please suggest.

Thanks in advance.

Re: Solr vs Hibernate Search (Huge number of DB DMLs)

[fire fox <fy...@gmail.com>]

Please suggest..

On Mon, Jul 4, 2011 at 10:37 PM, fire fox <fy...@gmail.com> wrote:

> From my exploration so far, I understood that we can opt Solr straightaway
> if the index changes are kept to minimal. However, mine is absolutely the
> opposite. I'm still vague about the perfect solution for the scenario
> mentioned.
>
> Please share..
>
>
> On Mon, Jul 4, 2011 at 6:28 PM, fire fox <fy...@gmail.com> wrote:
>
>> Hi all,
>>        There were several places I could find a discussion on this but I
>> failed to find the suited one for me.
>>
>> I'd like to be clear on my requirements, so that you may suggest me the
>> better solution.
>>
>> -> A project deals with tons of database tables (with *millions *of
>> records) out of which some are to be indexed which should be searchable
>> of-course. It uses Hibernate for MySQL transactions.
>>
>>  As per my knowledge, there could be two solutions to maintain sync
>> between index and database effectively.
>>
>> --> There'd be a *huge number of transactions (DMLs) on the DB*, so I'm
>> wondering which one of the following will be able to handle it
>> effectively.
>>
>>  1) Configure *Solr *server, query it to search / send events to update.
>> This might be better than handling Lucene solely which provides index
>> read/write and load balancing. The problem here could be to implement &
>> maintain sync between index and DB with no lag as the updations (DMLs on DB)
>> are very frequent. Too many events to be sent!
>>
>>  2) Using *Hibernate Search*. I'm just wondering about its *performance*considering high volume of transactions on DB every minute.
>>
>> Please suggest.
>>
>> Thanks in advance.
>>
>
>

Re: Solr vs Hibernate Search (Huge number of DB DMLs)

[fire fox <fy...@gmail.com>]

>From my exploration so far, I understood that we can opt Solr straightaway
if the index changes are kept to minimal. However, mine is absolutely the
opposite. I'm still vague about the perfect solution for the scenario
mentioned.

Please share..

On Mon, Jul 4, 2011 at 6:28 PM, fire fox <fy...@gmail.com> wrote:

> Hi all,
>        There were several places I could find a discussion on this but I
> failed to find the suited one for me.
>
> I'd like to be clear on my requirements, so that you may suggest me the
> better solution.
>
> -> A project deals with tons of database tables (with *millions *of
> records) out of which some are to be indexed which should be searchable
> of-course. It uses Hibernate for MySQL transactions.
>
>  As per my knowledge, there could be two solutions to maintain sync between
> index and database effectively.
>
> --> There'd be a *huge number of transactions (DMLs) on the DB*, so I'm
> wondering which one of the following will be able to handle it
> effectively.
>
>  1) Configure *Solr *server, query it to search / send events to update.
> This might be better than handling Lucene solely which provides index
> read/write and load balancing. The problem here could be to implement &
> maintain sync between index and DB with no lag as the updations (DMLs on DB)
> are very frequent. Too many events to be sent!
>
>  2) Using *Hibernate Search*. I'm just wondering about its *performance*considering high volume of transactions on DB every minute.
>
> Please suggest.
>
> Thanks in advance.
>