Hi!
I am looking for some advice on an sharding strategy that will produce
optimal performance in the NRT search case for my setup. I have come up
with a strategy that I think will work based on my experience, testing, and
reading of similar questions on the mailing list, but I was hoping to run
Query-heavy (100 queries per sec)
scenario?
Thanks & Regards,
Bhaumik Joshi
From: Shawn Heisey
Sent: Tuesday, April 12, 2016 7:37 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr Sharding Strategy
On 4/11/2016 6:31 AM, Bhaumik Joshi wrote:
>
On 4/11/2016 6:31 AM, Bhaumik Joshi wrote:
> We are using solr 5.2.0 and we have Index-heavy (100 index updates per
> sec) and Query-heavy (100 queries per sec) scenario.
>
> *Index stats: *10 million documents and 16 GB index size
>
>
>
> Which sharding strategy is best
user@lucene.apache.org
Subject: Re: Solr Sharding Strategy
On Tue, 2016-04-12 at 05:57 +, Bhaumik Joshi wrote:
> //Insert Document
> UpdateResponse resp = cloudServer.add(doc, 1000);
>
Don't insert documents one at a time, if it can be avoided:
https://lucidworks.com/blog/2015/10/05/re
On Tue, 2016-04-12 at 05:57 +, Bhaumik Joshi wrote:
> //Insert Document
> UpdateResponse resp = cloudServer.add(doc, 1000);
>
Don't insert documents one at a time, if it can be avoided:
https://lucidworks.com/blog/2015/10/05/really-batch-updates-solr-2/
Try pausing the indexing fully when y
oshi
From: Daniel Collins
Sent: Monday, April 11, 2016 8:12 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr Sharding Strategy
I'd also ask about your indexing times, what QTime do you see for indexing
(in both scenarios), and what commit times are you using (which Tok
ildsen wrote:
> On Mon, 2016-04-11 at 11:23 +, Bhaumik Joshi wrote:
> > We are using solr 5.2.0 and we have Index-heavy (100 index updates per
> > sec) and Query-heavy (100 queries per sec) scenario.
>
> > Index stats: 10 million documents and 16 GB index size
>
>
On Mon, 2016-04-11 at 11:23 +, Bhaumik Joshi wrote:
> We are using solr 5.2.0 and we have Index-heavy (100 index updates per
> sec) and Query-heavy (100 queries per sec) scenario.
> Index stats: 10 million documents and 16 GB index size
> Which sharding strategy is best sui
Hi,
We are using solr 5.2.0 and we have Index-heavy (100 index updates per sec) and
Query-heavy (100 queries per sec) scenario.
Index stats: 10 million documents and 16 GB index size
Which sharding strategy is best suited in above scenario?
Please share reference resources which states
Hi,
We are using solr 5.2.0 and we have Index-heavy (100 index updates per sec) and
Query-heavy (100 queries per sec) scenario.
Index stats: 10 million documents and 16 GB index size
Which sharding strategy is best suited in above scenario?
Please share reference resources which states
le that enu will be routed to shard1 while deu goes
> to shard2, and esp and chs gets indexed in either of them. Or, all of them
> can potentially end up getting indexed in the same shard, either 1 or 2,
> leaving one shard under-utilized.
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-Cloud-sharding-strategy-tp4262274p4262336.html
> Sent from the Solr - User mailing list archive at Nabble.com.
abble.com/Solr-Cloud-sharding-strategy-tp4262274p4262336.html
Sent from the Solr - User mailing list archive at Nabble.com.
n grow up to half a TB from its current state.
>> Honestly, my perception of "big" index is still vague :-) . All I'm trying
>> to make sure is that decision I take is scalable in the long term and will
>> be able to sustain the growth without compromising the performance.
>>
>>
>>
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Solr-Cloud-sharding-strategy-tp4262274p4262304.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
Honestly, my perception of "big" index is still vague :-) . All I'm trying
> to make sure is that decision I take is scalable in the long term and will
> be able to sustain the growth without compromising the performance.
>
>
>
> --
> View this message in context:
472066.n3.nabble.com/Solr-Cloud-sharding-strategy-tp4262274p4262304.html
Sent from the Solr - User mailing list archive at Nabble.com.
20M docs is actually a very small collection by the "usual" Solr
standards unless they're _really_ large documents, i.e.
large books.
Actually, I wouldn't even shard to begin with, it's unlikely that it's
necessary and it adds inevitable overhead. If you _must_ shard,
just go with <1>, but again I
Hi,
I'm trying to figure the best way to design/allocate shards for our Solr
Cloud environment.Our current index has around 20 million documents, in 10
languages. Around 25-30% of the content is in English. Rest are almost
equally distributed among the remaining 13 languages. Till now, we had to
user@lucene.apache.org"
Sent: Tuesday, June 9, 2009 7:07:47 AM
Subject: Sharding strategy
Hi all,
I'm trying to figure out how to shard our index as it is growing
rapidly and we
want to make our solution scalable.
So, we have documents that are most commonly sorted by their date. M
ay, June 9, 2009 7:07:47 AM
> Subject: Sharding strategy
>
> Hi all,
> I'm trying to figure out how to shard our index as it is growing rapidly and
> we
> want to make our solution scalable.
> So, we have documents that are most commonly sorted by their date. My initi
Hi all,
I'm trying to figure out how to shard our index as it is growing rapidly
and we want to make our solution scalable.
So, we have documents that are most commonly sorted by their date. My
initial thought is to shard the index by date, but I wonder if you have
any input on this and how
20 matches
Mail list logo
