Basically I expect you're falling afoul of a very common misunderstanding;
It's not that Solr is slower, it's that the client isn't feeding Solr
as fast as it
should.
If you profile your Solr server, my suspicion is that you're not
driving it very hard.
You'll probably see 4 spikes in CPU activity
Actually I can see a problem in your question…
Lucene and Solr are not competitor technologies.
Solr is a Search Server that internally uses the Lucene library and offers
easy to use configuration and REST API.
Lucene is a library that implements tons of search algorithms and features.
You can see
Great answer Robert.
On Fri, Mar 9, 2012 at 12:06 PM, Robert Stewart wrote:
> Split up index into say 100 cores, and then route each search to a specific
> core by some mod operator on the user id:
>
> core_number = userid % num_cores
>
> core_name = "core"+core_number
>
> That way each index co
On the other hand, I'm aware of the fact that if I go with Lucene approach,
failover is something that I will have to support manually! which is a
nightmare!
On Fri, Mar 9, 2012 at 2:13 PM, Alireza Salimi wrote:
> This solution makes sense, but I still don't know if I can use solrCloud
> with
> t
This solution makes sense, but I still don't know if I can use solrCloud
with
this configuration or not.
On Fri, Mar 9, 2012 at 2:06 PM, Robert Stewart wrote:
> Split up index into say 100 cores, and then route each search to a
> specific core by some mod operator on the user id:
>
> core_number
Split up index into say 100 cores, and then route each search to a specific
core by some mod operator on the user id:
core_number = userid % num_cores
core_name = "core"+core_number
That way each index core is relatively small (maybe 100 million docs or less).
On Mar 9, 2012, at 2:02 PM, Glen
probably, and besides that, how can I use the features that SolrCloud
provides (i.e. high availability and distribution)?
The other solution would be to use SolrCloud and keep all of the users'
information in single collection and use NRT. But on the other hand
the frequency of updates on that big
millions of cores will not work...
...yet.
-glen
On Fri, Mar 9, 2012 at 1:46 PM, Lan wrote:
> Solr has no limitation on the number of cores. It's limited by your hardware,
> inodes and how many files you could keep open.
>
> I think even if you went the Lucene route you would run into same hardw
Solr has no limitation on the number of cores. It's limited by your hardware,
inodes and how many files you could keep open.
I think even if you went the Lucene route you would run into same hardware
limits.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Lucene-vs-Solr-desig
Sorry I didn't mention that, the number of users can be millions!
Meaning that millions of cores! So I'm not sure if it's a good idea.
On Fri, Mar 9, 2012 at 1:35 PM, Lan wrote:
> Solr has cores which are independent search indexes. You could create a
> separate core per user.
>
> --
> View this
Solr has cores which are independent search indexes. You could create a
separate core per user.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Lucene-vs-Solr-design-decision-tp3813457p3813489.html
Sent from the Solr - User mailing list archive at Nabble.com.
Is that right?
On Tue, Oct 19, 2010 at 11:08 PM, findbestopensource <
findbestopensou...@gmail.com> wrote:
> Hello all,
>
> I have posted an article Lucene vs Solr
> http://www.findbestopensource.com/article-detail/lucene-vs-solr
>
> Please feel free to add your comments.
>
> Regards
> Aditya
> w
12 matches
Mail list logo
