Cool, thanks a lot for sharing your experience and thoughts! I will run a test like you suggested.
However, I've got some questions. The facet list I would retrieve for step 1 - it would 'only' contain the field values for what I faceted on such as Hotel-ID, right? How do I receive hotelname, description, price, etc. then? By issuing further solr requests for each facetlist-item? Would I be able to sort and paginate over this list? You see, to end users I would need to show a hotel list sorted by e.g. price(with only one search hit per hotel), showing the cheapest price fitting to e.g. the user-specified date range for each hotel. Would I still go the facet way with these requirements? Thanks again! Carsten On Thu, Sep 10, 2009 at 9:07 AM, Constantijn Visinescu <baeli...@gmail.com>wrote: > I'd run look into faceting and run a test. > > Create a schema, index the data and then run a query for *:* facteted by > hotel to get a list of all the hotels you want followed by a query that > returns all documents matching that hotel for your 2nd usecase. > > You're probably still going to want a SQL database to catch the > reservations > made tho. > > in my experience implementing Solr is more work then implementing a normal > SQL database, and loosing the relational part of a relational database is > something you have to wrap your head around to see how it affects your > application. > > That said solr on my 4 year old single core laptop outperforms our new dual > xeon database server running IBM DB2 when it comes to running a query on a > 10 million record dataset and retuning the total amount of documents that > match. > > Once you get it up and running properly and you need querys that are like > "give me the total number of documents that match these criteria, > optionally > facted by this and that" it's amazingly fast. > > Note that this advantage only becomes apparent when dealing with large data > sets. anything under a coulpe 100k records (guideline, depends heavily on > the type of record) and a normal SQL server should also be able to give you > the results you need near instantly. > > Hope this helps ;) > > > On Wed, Sep 9, 2009 at 5:33 PM, Carsten Kraus <carsten.kr...@gmail.com > >wrote: > > > Hi all, > > > > I'm about to develop a travel website and am wondering if Solr might fit > to > > be used as the search solution. > > Being quite the opposite of a db guru and new to Solr, it's hard for me > to > > judge if for my use-case a relational db should be used in favor of > Solr(or > > similar indexing server). Maybe some of you guys would share their > opinion > > on this? > > > > The products being searched for would be travel packages. That is: hotel > > room + flight combined into one product. > > I receive the products via a csv file, where each line defines a travel > > package with concrete departure/return, accommodation and price data. > > > > For example one csv row might represent: > > Hotel Foo in Paris, flight departing 10/10/09 from London, ending > 10/20/09, > > mealplan Bar, pricing $300 > > ..while another one might look like: > > Hotel Foo in Paris, flight departing 10/10/09 from Amsterdam, ending > > 10/30/09, mealplan Eggs :), pricing $400 > > > > Now searches should show results in 2 steps: first step showing results > > grouped by hotel(so no hotel appears twice) and second one all > > date-airport-mealplan combinations for the hotel selected by the user in > > step 1. > > > > From some first little tests, it seems to me as if I at least would need > > the > > collapse patch(SOLR-236) to be used in step 1 above?! > > > > What do you think? Does Solr fit into this scenario? Thoughts? > > > > Sorry for the lengthy post & thanks a lot for any pointer! > > Carsten > > >
