Nope. There is no replication, as in replication of the indexed
document in the normal flow. The _raw_ document is forwarded to all
replicas and upon return from the replicas, the raw document has been
written to each individual transaction log on each replica.
"replication" implies the _indexed_ f
Dave
-Original Message-
From: Furkan KAMACI [mailto:furkankam...@gmail.com]
Sent: Monday, May 06, 2013 9:44 PM
To: solr-user@lucene.apache.org
Subject: Re: Indexing off of the production servers
Hi Erick;
Thanks for your answer. I have read that at somewhere:
I believe "redirect"
Hi Erick;
Thanks for your answer. I have read that at somewhere:
I believe "redirect" from replica to leader would happen only at
index time, so a doc first gets indexed to leader and from there it's
replicated to non-leader shards.
Is that true? I want to make clear the things in my mind otherw
On 5/6/2013 7:55 AM, Andre Bois-Crettez wrote:
> Excellent idea !
> And it is possible to use collection aliasing with the CREATEALIAS to
> make this transparent for the query side.
>
> ex. with 2 collections named :
> collection_1
> collection_2
>
> /collections?action=CREATEALIAS&name=collectio
ic might be right in that it's not worth the
effort if there isn't some existing strategy.
Dave
-Original Message-
From: Furkan KAMACI [mailto:furkankam...@gmail.com]
Sent: Monday, May 06, 2013 7:06 PM
To: solr-user@lucene.apache.org
Subject: Re: Indexing off of the product
---Original Message-
> From: Furkan KAMACI [mailto:furkankam...@gmail.com]
> Sent: Monday, May 06, 2013 7:06 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Indexing off of the production servers
>
> Hi Erick;
>
> I think that even if you use Map/Reduce you will not par
ought maybe something like that
>> followed into solr cloud. Eric might be right in that it's not worth the
>> effort if there isn't some existing strategy.
>>
>> Dave
>>
>>
>> -Original Message-
>> From: Furkan KAMACI [mailto:furkan
omething like that
> followed into solr cloud. Eric might be right in that it's not worth the
> effort if there isn't some existing strategy.
>
> Dave
>
>
> -Original Message-
> From: Furkan KAMACI [mailto:furkankam...@gmail.com]
> Sent: Monday, May 06,
ke that
> followed into solr cloud. Eric might be right in that it's not worth the
> effort if there isn't some existing strategy.
>
> Dave
>
>
> -Original Message-
> From: Furkan KAMACI [mailto:furkankam...@gmail.com]
> Sent: Monday, May 06, 2013 7:06 PM
the
effort if there isn't some existing strategy.
Dave
-Original Message-
From: Furkan KAMACI [mailto:furkankam...@gmail.com]
Sent: Monday, May 06, 2013 7:06 PM
To: solr-user@lucene.apache.org
Subject: Re: Indexing off of the production servers
Hi Erick;
I think that even if you use Map/
Hi Erick;
I think that even if you use Map/Reduce you will not parallelize you
indexing because indexing will parallelize as much as how many leaders you
have at your SolrCloud, isn't it?
2013/5/6 Erick Erickson
> The only problem with using Hadoop (or whatever) is that you
> need to be sure th
The only problem with using Hadoop (or whatever) is that you
need to be sure that documents end up on the same shard, which
means that you have to use the same routing mechanism that
SolrCloud uses. The custom doc routing may help here
My very first question, though, would be whether this is n
1-2) Your aim for using Hadoop is probably Map/Reduce jobs. When you use
Map/Reduce jobs you split your workload, process it, and then reduce step
takes into account. Let me explain you new SolrCloud architecture. You
start your SolrCluoud with a numShards parameter. Let's assume that you
have 5 sh
13 matches
Mail list logo
