Searching is very fast with Solr, but no way as fast as keying into a map. There is possibly disk I/O if your document isn't cached. Your situation sounds unique enough I think you're going to need to prototype to see if it meets your demands. Figure out how 'fast' is 'fast' for your application, and then see if you can hit your targets. Once you have some real numbers and queries you'll be able to get more meaningful feedback from the community I imagine.
-Kallin Nagelberg -----Original Message----- From: Thomas J. Buhr [mailto:t...@superstringmedia.com] Sent: Wednesday, May 26, 2010 11:30 AM To: solr-user@lucene.apache.org Subject: Re: How real-time are Solr/Lucene queries? What about my situation? My renderers need to query the index for fast access to layout and style info as I already described about 3 messages ago on this thread. Another scenario is having automatic queries triggered as my midi player iterates through the model. As the player encounters trigger tags it needs to make a query quickly so that the next notes played will have the context they are meant to have. Basically, I need to know that issuing searches to a local index will not be slower than searching a hashmap or array. How different or similar will the performance be? Thom On 2010-05-26, at 9:41 AM, Walter Underwood wrote: > On May 25, 2010, at 11:24 PM, Amit Nithian wrote: > >> 2) What are typical/accepted definitions of "Real Time" vs "Near Real Time"? > > Real time means that an update is available in the next query after it > commits. Near real time means that the delay is small, but not zero. > > This is within a single server. In a cluster, there will be some > communication delay. > >> 3) I could understand POSTing a document to a server and then turning around >> and searching for it on the same server but what about a replicated >> environment and how do you prevent caches from being blown and constantly >> re-warmed (hence performance degradation)? > > You need a different caching design, with transaction-aware caches that are > at a lower level, closer to the indexes. > > wunder > -- > Walter Underwood > Lead Engineer > MarkLogic > > >
