>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 <fyr3...@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. >
