Ankush, Your approach works. Fire a "in" query on the review index for all hotel ids you care about. Create a map of hotel to its reviews.
Cheers Avlesh On Wed, Apr 29, 2009 at 8:09 AM, Amit Nithian <anith...@gmail.com> wrote: > Ankush, > It seems that unless reviews are changing constantly, why not do what Erick > was saying in flattening your data by storing reviews with the hotel index > but re-index your hotels storing the top two reviews. I guess I am > suggesting computing the top two reviews for each hotel offline and store > them somewhere. > > You could store the top two reviews in an RDBMS and let whatever front end > you have retrieve the top two from the RDBMS after receiving results from > Solr based on your unique ID. > > HTH > Amit > > On Tue, Apr 28, 2009 at 3:14 PM, Ankush Goyal <ankush.go...@orbitz.com > >wrote: > > > Hi Erick, > > > > Thanks for response!...the solution I was talking about was same as your > > last solution to get reviews for only required hotel-ids and then parsing > > them in one go to make a hash-map, I guess I didn't explain correctly :) > > > > As far as putting reviews inside the hotel index is concerned, we thought > > about that solution, but we also need to sort the reviews and (let's say) > > show top 2 of maybe 50 reviews for a hotel, so we couldn't put reviews > > inside hotel doc itself. > > > > Now, this again poses another question for the solution we talked about-, > > as it seems like getting reviews for required hotel-ids and then making a > > hash-map corresponding to hotel-ids can improve the performance, but then > we > > also need to sort all the reviews for each hotel using a field/ score in > the > > review-doc itself, which seems like would lower down the performance > > drastically. > > > > Any ideas on a better solution? > > > > Thanks! > > -Ankush > > > > -----Original Message----- > > From: Erick Erickson [mailto:erickerick...@gmail.com] > > Sent: Tuesday, April 28, 2009 4:05 PM > > To: solr-user@lucene.apache.org > > Subject: Re: Multiple Queries > > > > Have you considered indexing the reviews along with the hotels right > > in the hotel index? That way you would fetch the reviews right along with > > the hotels... > > > > Really, this is another way of saying "flatten your data" <G>... > > > > Your idea of holding all the hotel reviews in memory is also viable, > > depending upon > > how many there are. you'd pay some startup costs, but that's what caching > > is > > all > > about. > > > > Given your current index structure, have you tried collecting the hotel > > IDs, > > and > > submitting a query to your review index that just ORs together all the > IDs > > and > > then parsing that rather than calling your review index for one hotel ID > at > > a time? > > > > Best > > Erick > > > > On Tue, Apr 28, 2009 at 4:32 PM, Ankush Goyal <ankush.go...@orbitz.com > > >wrote: > > > > > Hi, > > > > > > I have been trying to solve a performance issue: I have an index of > > hotels > > > with their ids and another index of reviews. Now, when someone queries > > for a > > > location, the current process gets all the hotels for that location. > > > And, then corresponding to each hotel-id from all the hotel documents, > it > > > calls the review index to fetch reviews associated with that particular > > > hotel and so on it repeats for all the hotels. This process slows down > > the > > > request significantly. > > > I need to accumulate reviews according to corresponding hotel-ids, so I > > > can't just fetch all the reviews for all the hotel ids and show them. > > Now, I > > > was thinking about fetching all the reviews for all the hotel-ids and > > then > > > parse all those reviews in one go and create a map with hotel-id as key > > and > > > list of reviews as values. > > > > > > Can anyone comment on whether this procedure would be better or worse, > or > > > if there's better way of doing this? > > > > > > --Ankush Goyal > > > > > >
