That doesn't match the way we would like to scale NH search On Wed, Sep 2, 2009 at 9:57 AM, aterreno <[email protected]> wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
