Rather than having a centralized search my impression is that the best approach will be to have each cluster node to in memory index the database...
At least, that would work in a scenario similar to ours (relatively small data set, using full text search mostly to improve the performances of an autosuggest box). I'm not sure how to approach indexing lots of large documents (i.e. can't do in memory), perhaps a central service here is the best solution, with all the cluster nodes asking for data and talking continuously (REST?) with the service. On Sep 1, 9:54 am, Ayende Rahien <[email protected]> wrote: > Yep, That is pretty much what I had in mind. > Except, we need a design that has to work when using a web farm. > How do Hibernate Search deal with this? > > On Tue, Sep 1, 2009 at 11:47 AM, Antonio Terreno > <[email protected]>wrote: > > > Hi, > > thanks for your real time reply :-) > > > Our solution now works in this way: we recycle an IndexSearcher (it's in > > the IOC container). > > > As you said the results are not in real time what's on the DB... > > We are planning to reindex in memory with a service every 5 to N minutes > > (depends on what performances we can get there..). > > > For us it's ok, it's a good compromise in order to obtain a fast search > > with autocomplete. > > > Some sort of "second level cache" for the Lucene Index can be a good > > solution maybe: automatically invalidated and reindexed and queried when > > needed. > > > On Tue, Sep 1, 2009 at 9:36 AM, Ayende Rahien <[email protected]> wrote: > > >> There is also the other side of that, searchers are only limited to seeing > >> what the index was at the time of opening the searcher. We probably need > >> to provide some strategy to decide how we can share the index searchers. > > >> On Tue, Sep 1, 2009 at 11:20 AM, aterreno <[email protected]>wrote: > > >>> Hi all, > >>> after some enthusiasm on NHibernate.Search we incurred in some bad > >>> performances issues, especially searching and sorting (two fields > >>> sort) entities. > > >>> We decided to implement our search using plain Lucene.Net and writing > >>> our custom code to persist and find the NHibernate objects. > > >>> However now I would like to understand why the search was so slow. > > >>> We had a look to the NH.Search code and one piece of code seemed to be > >>> "the bottleneck" > > >>> The method "public override void List(IList list)" in > >>> FullTextQueryImpl Opens (at the beggining) and finally closes (at > >>> least that's my impression) a IndexSearcher every time it's called. > > >>> IndexSearcher searcher = BuildSearcher(); > > >>> //... do stuff > > >>> finally > >>> { > >>> CloseSearcher(searcher); > >>> } > > >>> Reading Lucene in Action at some point the author says that first > >>> query is always slow on the IndexSearcher (in fact he suggests to > >>> "warm up" the application performing a search). > > >>> With that close (and therefore the necessary open) it's impossible for > >>> Lucene to cache the objects and every call is expensive and reads on > >>> the disk... > > >>> Am I wrong? > > >>> Thanks for reading my rant! > > >>> toni > > > -- > >http://www.the-arm.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NHibernate Contrib - Development Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com.ar/group/nhcdevs?hl=en -~----------~----~----~----~------~----~------~--~---
