Re: Results from More then One Cors?
Hi Jörg, You can use the "shards" parameter to search the cores you want. For example, say you have core0, core1, core2. You want to have results from all the cores. Then you could use the following example URL: http://localhost:8983/solr/core0/select?q=*:*&sort=myfield+desc&shards=localhost:8983/solr/core0,localhost:8983/solr/core1,localhost:8983/solr/core2 The core name you choose for the http://localhost:8983/solr/coreX part of the Uri doesn't matter. The distributed search feature will use only the cores you specify with the "shards" parameter. This will give you a transparent view of the indexes you have in the separate cores. Prost! Und viel Glück ;) - Janne 2010/8/13 Jörg Agatz > Sorry.. > > > I tryed it with more Details :-).. > > > So i have a lot of cors.. 10 to 20... now i search a way to get results > from > 5 to ten Cors at the same time.. > i need to sort ol results need view facet search out of the 10 cors at the > same time. > > So one query, one server with 20 Corrs and o result with the results from > all 20 Corrs.. > > i hope my question is clearly.. my english is not the best.. Sorry >
Realtime search and facets with very frequent commits
Hello, I have a log search like application which requires indexed log events to be searchable within a minute and uses facets and the statscomponent. Some stats: - The log events are indexed every 10 seconds with a "commitWithin" of 60 seconds. - 1M events / day (~75% are updates to previous events). - Faceting over 14 fields ( strings ). Usually TOP5 by numdocs but facets for all 14 fields at the same time. - Heavy use of StatsComponent ( stats over facets of ~36M documents ). The application is running a single Solr instance. All updates and queries are sent to the same instance. Faceting and the StatsComponent are both amazingly fast with that amount of documents *when* the caches are warm. The problem I'm now facing is that keeping the caches warm is too heavy compared to the frequency of updates. It takes over 60 seconds to warmup the caches to the level where facets and stats are returned in milliseconds. I have tested putting a second solr instance on the same server and sending the updates to that new instance. Warming up the new small instance is very fast while the large instance has very hot caches. I also put a third (empty) solr instance on the same server which passes the queries to the two instances with the "shards" parameters. This is mainly because the client app really doesn't have to know anything about the shards. The setup was easy to configure and responses are back in milliseconds and the updates are visible in seconds. That is, responses in milliseconds over 40M documents and a update frequency of 15 seconds on a single physical server. The (lab) server has 16g RAM and it is running win23k. Also, what I found out is that using the sharded setup I only need half the memory for the large instance. When indexing to the large instance the memory usage goes very fast up to the maximum allocated heap size and never goes down. My question is, is there a magic switch in SOLR to have that kind of update frequency while having the caches on fire ? Or is it just impossible to achieve facet counts and queries in milliseconds while updating the index every minute ? The second question is, the setup with a empty SOLR as a "coordinating" instance, a large SOLR instance with hot caches and a small SOLR instance with immediate updates, all on the same physical server, does it sound like a durable solution (until the small instance gets big) or is it something is braindead ? And the third question is, would it be a good idea to merge the small and the large index periodically so that a fresh and empty small instance would be available after the merge ? Any ideas ? Best Regards, Janne Majaranta
Re: Realtime search and facets with very frequent commits
Hey Jason, Do you use faceting with frequent commits ? And by turning off the caches you mean setting autowarmcount to zero ? I did try to turn off autowarming with a 36M documents instance but getting facets over those documents takes over 10 seconds. With a warm cache it takes 200ms ... -Janne 2010/2/11 Jason Rutherglen > Janne, > > I usually just turn the caches to next to nearly off for frequent commits. > > Jason > > On Thu, Feb 11, 2010 at 9:35 AM, Janne Majaranta > wrote: > > Hello, > > > > I have a log search like application which requires indexed log events to > be > > searchable within a minute > > and uses facets and the statscomponent. > > > > Some stats: > > - The log events are indexed every 10 seconds with a "commitWithin" of 60 > > seconds. > > - 1M events / day (~75% are updates to previous events). > > - Faceting over 14 fields ( strings ). Usually TOP5 by numdocs but facets > > for all 14 fields at the same time. > > - Heavy use of StatsComponent ( stats over facets of ~36M documents ). > > > > > > The application is running a single Solr instance. All updates and > queries > > are sent to the same instance. > > Faceting and the StatsComponent are both amazingly fast with that amount > of > > documents *when* the caches are warm. > > > > The problem I'm now facing is that keeping the caches warm is too heavy > > compared to the frequency of updates. > > It takes over 60 seconds to warmup the caches to the level where facets > and > > stats are returned in milliseconds. > > > > I have tested putting a second solr instance on the same server and > sending > > the updates to that new instance. > > Warming up the new small instance is very fast while the large instance > has > > very hot caches. > > > > I also put a third (empty) solr instance on the same server which passes > the > > queries to the two instances with the > > "shards" parameters. This is mainly because the client app really doesn't > > have to know anything about the shards. > > > > The setup was easy to configure and responses are back in milliseconds > and > > the updates are visible in seconds. > > That is, responses in milliseconds over 40M documents and a update > frequency > > of 15 seconds on a single physical server. > > The (lab) server has 16g RAM and it is running win23k. > > > > Also, what I found out is that using the sharded setup I only need half > the > > memory for the large instance. > > When indexing to the large instance the memory usage goes very fast up to > > the maximum allocated heap size and never goes down. > > > > My question is, is there a magic switch in SOLR to have that kind of > update > > frequency while having the caches on fire ? > > Or is it just impossible to achieve facet counts and queries in > milliseconds > > while updating the index every minute ? > > > > The second question is, the setup with a empty SOLR as a "coordinating" > > instance, a large SOLR instance with hot caches and a small SOLR instance > > with immediate updates, > > all on the same physical server, does it sound like a durable solution > > (until the small instance gets big) or is it something is braindead ? > > > > And the third question is, would it be a good idea to merge the small and > > the large index periodically so that a fresh and empty small instance > would > > be available > > after the merge ? > > > > Any ideas ? > > > > Best Regards, > > > > Janne Majaranta > > >
Re: Realtime search and facets with very frequent commits
Ok, Thanks Yonik and Otis. I already had static warming queries with facets turned on and autowarming at zero. There were a lot of other optimizations after that however, so I'll try with zero autowarming and static warming queries again. If that doesn't work, I'll go with 3 instances on the same server. BTW, does it sound like normal that when running updates every minute to a 36M index it takes all the available heap size after about 5 commits although there is not a single query executed to the index and autowarming is set to zero ? Just curious. -Janne 2010/2/11 Otis Gospodnetic > Janne, > > The answers to your last 2 questions are both yes. I've seen that done a > few times and it works. I don't have the answer to the always-hot cache > question. > > > Otis > > Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch > Hadoop ecosystem search :: http://search-hadoop.com/ > > > > - Original Message > > From: Janne Majaranta > > To: solr-user@lucene.apache.org > > Sent: Thu, February 11, 2010 12:35:20 PM > > Subject: Realtime search and facets with very frequent commits > > > > Hello, > > > > I have a log search like application which requires indexed log events to > be > > searchable within a minute > > and uses facets and the statscomponent. > > > > Some stats: > > - The log events are indexed every 10 seconds with a "commitWithin" of 60 > > seconds. > > - 1M events / day (~75% are updates to previous events). > > - Faceting over 14 fields ( strings ). Usually TOP5 by numdocs but facets > > for all 14 fields at the same time. > > - Heavy use of StatsComponent ( stats over facets of ~36M documents ). > > > > > > The application is running a single Solr instance. All updates and > queries > > are sent to the same instance. > > Faceting and the StatsComponent are both amazingly fast with that amount > of > > documents *when* the caches are warm. > > > > The problem I'm now facing is that keeping the caches warm is too heavy > > compared to the frequency of updates. > > It takes over 60 seconds to warmup the caches to the level where facets > and > > stats are returned in milliseconds. > > > > I have tested putting a second solr instance on the same server and > sending > > the updates to that new instance. > > Warming up the new small instance is very fast while the large instance > has > > very hot caches. > > > > I also put a third (empty) solr instance on the same server which passes > the > > queries to the two instances with the > > "shards" parameters. This is mainly because the client app really doesn't > > have to know anything about the shards. > > > > The setup was easy to configure and responses are back in milliseconds > and > > the updates are visible in seconds. > > That is, responses in milliseconds over 40M documents and a update > frequency > > of 15 seconds on a single physical server. > > The (lab) server has 16g RAM and it is running win23k. > > > > Also, what I found out is that using the sharded setup I only need half > the > > memory for the large instance. > > When indexing to the large instance the memory usage goes very fast up to > > the maximum allocated heap size and never goes down. > > > > My question is, is there a magic switch in SOLR to have that kind of > update > > frequency while having the caches on fire ? > > Or is it just impossible to achieve facet counts and queries in > milliseconds > > while updating the index every minute ? > > > > The second question is, the setup with a empty SOLR as a "coordinating" > > instance, a large SOLR instance with hot caches and a small SOLR instance > > with immediate updates, > > all on the same physical server, does it sound like a durable solution > > (until the small instance gets big) or is it something is braindead ? > > > > And the third question is, would it be a good idea to merge the small and > > the large index periodically so that a fresh and empty small instance > would > > be available > > after the merge ? > > > > Any ideas ? > > > > Best Regards, > > > > Janne Majaranta > >
Re: Realtime search and facets with very frequent commits
Hey Dipti, Basically query optimizations + setting cache sizes to a very high level. Other than that, the config is about the same as the out-of-the-box config that comes with the Solr download. I haven't found a magic switch to get very fast query responses + facet counts with the frequency of commits I'm having using one single SOLR instance. Adding some TOP queries for a certain type of user to static warming queries just moved the time of autowarming the caches to the time it took to warm the caches with static queries. I've been staging a setup where there's a small solr instance receiving all the updates and a large instance which doesn't receive the live feed of updates. The small index will be merged with the large index periodically (once a week or once a month). The two instances are seen by the client app as one instance using the sharding features of SOLR. The instances are running on the same server inside their own JVM / jetty. In this setup the caches are very HOT for the large index and queries are extremely fast, and the small index is small enough to get extremely fast queries without having to warm up the caches too much. Basically I'm able to have a commit frequency of 10 seconds in a 40M docs index while counting TOP5 facets over 14 fields in 200ms. In reality the commit frequency of 10 seconds comes from the fact that the updates are going into a 1M - 2M documents index, and the fast facet counts from the fact that the 38M documents index has hot caches and doesn't receive any updates. Also, not running updates to the large index means that the SOLR instance reading the large index uses about half the memory it used before when running the updates to the large index. At least it does so on Win2k3. -Janne 2010/2/15 dipti khullar > Hey Janne > > Can you please let me know what other optimizations are you talking about > here. Because in our application we are committing in about 5 mins but > still > the response time is very low and at times there are some connection time > outs also. > > Just wanted to confirm if you have done some major configuration changes > which have proved beneficial. > > Thanks > Dipti > >
Re: Realtime search and facets with very frequent commits
Hi, Yes, I did play with mergeFactor. I didn't play with mergePolicy. Wouldn't that affect indexing speed and possibly memory usage ? I don't have any problems with indexing speed ( 1000 - 2000 docs / sec via the standard HTTP API ). My problem is that I need very warm caches to get fast faceting, and the autowarming of the caches takes too long compared to the frequency of commits I'm having. So a commit every minute means less than a minute time to warm the caches. To give you a idea of what kind of queries needs to be autowarmed in my app, the logevents indexed as documents have timestamps with different granularity used for faceting. For example, to get count of logevents for every hour using faceting there's a timestamp field with the format mmddhh ( for example: 2010021808 meaning 2010-02-18 8am). One use case is to get hourly counts over the whole index. A non-cached query counting the hourly counts over the 40M documents index takes a while.. And to my understanding autowarming means something like that this kind of query would be basically re-executed against a cold cache. Probably not exactly how it works, but it "feels" like it would. Moving the commits to a smaller index while using sharding to have a transparent view to the index from the client app seems to solve my problem. I'm not sure if the (upcoming?) NRT features would keep the caches more persistent, probably not in a environment where docs get frequent updates / deletes. Also, I'm closely following the Ocean Realtime Search project AND it's SOLR integration. It sounds like it has the "dream features" to enable realtime updates to the index. -Janne 2010/2/18 Jan Høydahl / Cominvent > Hi, > > Have you tried playing with mergeFactor or even mergePolicy? > > -- > Jan Høydahl - search architect > Cominvent AS - www.cominvent.com > > On 16. feb. 2010, at 08.26, Janne Majaranta wrote: > > > Hey Dipti, > > > > Basically query optimizations + setting cache sizes to a very high level. > > Other than that, the config is about the same as the out-of-the-box > config > > that comes with the Solr download. > > > > I haven't found a magic switch to get very fast query responses + facet > > counts with the frequency of commits I'm having using one single SOLR > > instance. > > Adding some TOP queries for a certain type of user to static warming > queries > > just moved the time of autowarming the caches to the time it took to warm > > the caches with static queries. > > I've been staging a setup where there's a small solr instance receiving > all > > the updates and a large instance which doesn't receive the live feed of > > updates. > > The small index will be merged with the large index periodically (once a > > week or once a month). > > The two instances are seen by the client app as one instance using the > > sharding features of SOLR. > > The instances are running on the same server inside their own JVM / > jetty. > > > > In this setup the caches are very HOT for the large index and queries are > > extremely fast, and the small index is small enough to get extremely fast > > queries without having to warm up the caches too much. > > > > Basically I'm able to have a commit frequency of 10 seconds in a 40M docs > > index while counting TOP5 facets over 14 fields in 200ms. > > In reality the commit frequency of 10 seconds comes from the fact that > the > > updates are going into a 1M - 2M documents index, and the fast facet > counts > > from the fact that the 38M documents index has hot caches and doesn't > > receive any updates. > > > > Also, not running updates to the large index means that the SOLR instance > > reading the large index uses about half the memory it used before when > > running the updates to the large index. At least it does so on Win2k3. > > > > -Janne > > > > > > 2010/2/15 dipti khullar > > > >> Hey Janne > >> > >> Can you please let me know what other optimizations are you talking > about > >> here. Because in our application we are committing in about 5 mins but > >> still > >> the response time is very low and at times there are some connection > time > >> outs also. > >> > >> Just wanted to confirm if you have done some major configuration changes > >> which have proved beneficial. > >> > >> Thanks > >> Dipti > >> > >> > >
Re: Realtime search and facets with very frequent commits
Hi Otis, Ok, now I'm confused ;) There seems to be a bit activity though when looking at the "last updated" timestamps in the google code project wiki: http://code.google.com/p/oceansearch/w/list The Tag Index feature sounds very interesting. -Janne 2010/2/18 Otis Gospodnetic > Hi Janne, > > I *think* Ocean Realtime Search has been superseded by Lucene NRT search. > > Otis > > Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch > Hadoop ecosystem search :: http://search-hadoop.com/ > > > > ----- Original Message > > From: Janne Majaranta > > To: solr-user@lucene.apache.org > > Sent: Thu, February 18, 2010 2:12:37 AM > > Subject: Re: Realtime search and facets with very frequent commits > > > > Hi, > > > > Yes, I did play with mergeFactor. > > I didn't play with mergePolicy. > > > > Wouldn't that affect indexing speed and possibly memory usage ? > > I don't have any problems with indexing speed ( 1000 - 2000 docs / sec > via > > the standard HTTP API ). > > > > My problem is that I need very warm caches to get fast faceting, and the > > autowarming of the caches takes too long compared to the frequency of > > commits I'm having. > > So a commit every minute means less than a minute time to warm the > caches. > > > > To give you a idea of what kind of queries needs to be autowarmed in my > app, > > the logevents indexed as documents have timestamps with different > > granularity used for faceting. > > For example, to get count of logevents for every hour using faceting > there's > > a timestamp field with the format mmddhh ( for example: 2010021808 > > meaning 2010-02-18 8am). > > One use case is to get hourly counts over the whole index. A non-cached > > query counting the hourly counts over the 40M documents index takes a > > while.. > > And to my understanding autowarming means something like that this kind > of > > query would be basically re-executed against a cold cache. Probably not > > exactly how it works, but it "feels" like it would. > > > > Moving the commits to a smaller index while using sharding to have a > > transparent view to the index from the client app seems to solve my > problem. > > > > I'm not sure if the (upcoming?) NRT features would keep the caches more > > persistent, probably not in a environment where docs get frequent updates > / > > deletes. > > > > Also, I'm closely following the Ocean Realtime Search project AND it's > SOLR > > integration. It sounds like it has the "dream features" to enable > realtime > > updates to the index. > > > > -Janne > > > > > > 2010/2/18 Jan Høydahl / Cominvent > > > > > Hi, > > > > > > Have you tried playing with mergeFactor or even mergePolicy? > > > > > > -- > > > Jan Høydahl - search architect > > > Cominvent AS - www.cominvent.com > > > > > > On 16. feb. 2010, at 08.26, Janne Majaranta wrote: > > > > > > > Hey Dipti, > > > > > > > > Basically query optimizations + setting cache sizes to a very high > level. > > > > Other than that, the config is about the same as the out-of-the-box > > > config > > > > that comes with the Solr download. > > > > > > > > I haven't found a magic switch to get very fast query responses + > facet > > > > counts with the frequency of commits I'm having using one single SOLR > > > > instance. > > > > Adding some TOP queries for a certain type of user to static warming > > > queries > > > > just moved the time of autowarming the caches to the time it took to > warm > > > > the caches with static queries. > > > > I've been staging a setup where there's a small solr instance > receiving > > > all > > > > the updates and a large instance which doesn't receive the live feed > of > > > > updates. > > > > The small index will be merged with the large index periodically > (once a > > > > week or once a month). > > > > The two instances are seen by the client app as one instance using > the > > > > sharding features of SOLR. > > > > The instances are running on the same server inside their own JVM / > > > jetty. > > > > > > > > In this setup the caches are very HOT for the large index and queries > are > > > > extremely fast, an
Re: Realtime search and facets with very frequent commits
Ok, thanks. -Janne 2010/2/18 Jason Rutherglen > Janne, > > I don't think there's any activity happening there. > > SOLR-1606 is the tracking issue for moving to per segment facets and > docsets. I haven't had an immediate commercial need to implement > those. > > Jason > > On Thu, Feb 18, 2010 at 7:04 AM, Janne Majaranta > wrote: > > Hi Otis, > > > > Ok, now I'm confused ;) > > There seems to be a bit activity though when looking at the "last > updated" > > timestamps in the google code project wiki: > > http://code.google.com/p/oceansearch/w/list > > > > The Tag Index feature sounds very interesting. > > > > -Janne > > > > > > 2010/2/18 Otis Gospodnetic > > > >> Hi Janne, > >> > >> I *think* Ocean Realtime Search has been superseded by Lucene NRT > search. > >> > >> Otis > >> > >> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch > >> Hadoop ecosystem search :: http://search-hadoop.com/ > >> > >> > >> > >> - Original Message > >> > From: Janne Majaranta > >> > To: solr-user@lucene.apache.org > >> > Sent: Thu, February 18, 2010 2:12:37 AM > >> > Subject: Re: Realtime search and facets with very frequent commits > >> > > >> > Hi, > >> > > >> > Yes, I did play with mergeFactor. > >> > I didn't play with mergePolicy. > >> > > >> > Wouldn't that affect indexing speed and possibly memory usage ? > >> > I don't have any problems with indexing speed ( 1000 - 2000 docs / sec > >> via > >> > the standard HTTP API ). > >> > > >> > My problem is that I need very warm caches to get fast faceting, and > the > >> > autowarming of the caches takes too long compared to the frequency of > >> > commits I'm having. > >> > So a commit every minute means less than a minute time to warm the > >> caches. > >> > > >> > To give you a idea of what kind of queries needs to be autowarmed in > my > >> app, > >> > the logevents indexed as documents have timestamps with different > >> > granularity used for faceting. > >> > For example, to get count of logevents for every hour using faceting > >> there's > >> > a timestamp field with the format mmddhh ( for example: 2010021808 > >> > meaning 2010-02-18 8am). > >> > One use case is to get hourly counts over the whole index. A > non-cached > >> > query counting the hourly counts over the 40M documents index takes a > >> > while.. > >> > And to my understanding autowarming means something like that this > kind > >> of > >> > query would be basically re-executed against a cold cache. Probably > not > >> > exactly how it works, but it "feels" like it would. > >> > > >> > Moving the commits to a smaller index while using sharding to have a > >> > transparent view to the index from the client app seems to solve my > >> problem. > >> > > >> > I'm not sure if the (upcoming?) NRT features would keep the caches > more > >> > persistent, probably not in a environment where docs get frequent > updates > >> / > >> > deletes. > >> > > >> > Also, I'm closely following the Ocean Realtime Search project AND it's > >> SOLR > >> > integration. It sounds like it has the "dream features" to enable > >> realtime > >> > updates to the index. > >> > > >> > -Janne > >> > > >> > > >> > 2010/2/18 Jan Høydahl / Cominvent > >> > > >> > > Hi, > >> > > > >> > > Have you tried playing with mergeFactor or even mergePolicy? > >> > > > >> > > -- > >> > > Jan Høydahl - search architect > >> > > Cominvent AS - www.cominvent.com > >> > > > >> > > On 16. feb. 2010, at 08.26, Janne Majaranta wrote: > >> > > > >> > > > Hey Dipti, > >> > > > > >> > > > Basically query optimizations + setting cache sizes to a very high > >> level. > >> > > > Other than that, the config is about the same as the > out-of-the-box > >> > > config > >> > > > that come
Re: Solrsharp
Hi, I'm using solrnet with solr. It is *the* library to use with .NET and solr. For indexing I'm just sending the XML with the builtin HTTP libraries of the .NET BCL. Cheers, Janne 2010/2/27 Frederico Azeiteiro > Hi Saschin, > > Yes i had to make some patches too (range queries didn't work very good...) > and yes, i thought about changing the parameterjoin. > > I'm already using solrsharp for indexing without problems but i guess for > searches, I'm gonna give a try to solrnet mostly because the lack of > support/feedback with solrsharp... > > Does anyone around here uses c# with solr? What client do you use? > > Another ideia is perform the search directly on SOLR index using lucene > API. I previsouly used c# luceneAPI for a long time without any problems. > Maybe it's the quicker solution... > > Thanks for your feedback. > > > > De: Sachin [mailto:sachinni...@aim.com] > Enviada: sáb 27-02-2010 12:04 > Para: solr-user@lucene.apache.org > Assunto: Re: Solrsharp > > > > > solr# does not have built in support for "NOT" searches, you would have to > tweak the solr# library to do that (take a look at how the ParameterJoin is > used, add one for Not). I have faced quite a few issues with using solr# in > the past like unclosed TCP connections, no spellchecker, json support etc > and had to patch it quite frequently. I guess your best bet would be to take > a look at some other client like solr.net: > http://code.google.com/p/solrnet/. Disclaimer: I haven't evaluated > solr.net myself but it looks to be more robust than solr# and is more > actively maintained than solr#. > > S > > > > > > > > > -Original Message- > From: Frederico Azeiteiro > To: solr-user@lucene.apache.org > Sent: Fri, Feb 26, 2010 9:54 pm > Subject: Solrsharp > > > Hi, > > > > I don't know if this list includes this kind of help, but I'm using > Solrsharp with C# to operate SOLR. Please advise if this is off-topic > please. > > > > I'm having a little trouble to make a search with exclude terms using > the query parameters. > > > > Does anyone uses Solrsharp around here? Do you manage to exclude terms > on searches? > > > > Br > > Frederico > > > > > > > > > >
Re: Free Webinar: Mastering Solr 1.4 with Yonik Seeley
Do I need a U.S. phone number to view the recording / download the slides ? The registration form whines about invalid area code.. -Janne
Re: [ANN] Zoie Solr Plugin - Zoie Solr Plugin enables real-time update functionality for Apache Solr 1.4+
To my understanding it adds a in-memory index which holds the recent commits and which is flushed to the main index based on the config options. Not sure if it helps to get solr near real time. I am evaluating it currently, and I am really not sure if it adds anything because of the cache regeneration of solr on every commit ?? -Janne Lähetetty iPodista brad anderson kirjoitti 19.3.2010 kello 20.53: Indeed, which is why I'm wondering what is Zoie adding if you still need to commit to search recent documents. Does anyone know? Thanks, Brad On 18 March 2010 19:41, Erik Hatcher wrote: "When I don't do the commit, I cannot search the documents I've indexed." - that's exactly how Solr without Zoie works, and it's how Lucene itself works. Gotta commit to see the documents indexed. Erik On Mar 18, 2010, at 5:41 PM, brad anderson wrote: Tried following their tutorial for plugging zoie into solr: http://snaprojects.jira.com/wiki/display/ZOIE/Zoie+Server It appears it only allows you to search on documents after you do a commit? Am I missing something here, or does plugin not doing anything. Their tutorial tells you to do a commit when you index the docs: curl http://localhost:8983/solr/update/csv?commit=true --data-binary @books.csv -H 'Content-type:text/plain; charset=utf-8' When I don't do the commit, I cannot search the documents I've indexed. Thanks, Brad On 9 March 2010 23:34, Don Werve wrote: 2010/3/9 Shalin Shekhar Mangar I think Don is talking about Zoie - it requires a long uniqueKey. Yep; we're using UUIDs.
Re: Realtime search and facets with very frequent commits
Yeah, thanks for pointing this out. I'm not using any relevancy functions (yet). The data indexed for my app is basically log events. The most relevant events are the newest ones, so sorting by timestamp is enough. BTW, your book is great ;) -Janne 2010/3/31 Smiley, David W. > Janne, >Have you found your query relevancy to deteriorate with this setup? > Something to be aware of with distributed searches is that the relevancy of > each Solr core response is based on the local index to that core. So if > you're distributed Solr setup does not distribute documents randomly (as is > certainly the case for you) your relevancy scores will be poor. > > ~ David Smiley > Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/ > > On Feb 11, 2010, at 12:35 PM, Janne Majaranta wrote: > ... > > > > I have tested putting a second solr instance on the same server and > sending > > the updates to that new instance. > > Warming up the new small instance is very fast while the large instance > has > > very hot caches. > ... > > > > Best Regards, > > > > Janne Majaranta > >
