Re: Solr vs Hibernate Search (Huge number of DB DMLs)
Please suggest.. On Mon, Jul 4, 2011 at 10:37 PM, fire fox fyr3...@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 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.
Solr vs Hibernate Search (Huge number of DB DMLs)
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)
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.
