Hi Shawn,
Too much technical details are often better, than too little, to my taste
of course :-)
You approach to sharding is apparently hashing based. And that's why you
need to maintain doc did values that come from MySQL in a separate storage
and decide on split point. That's totally legit. And
heavy load of update on index.
Can you pls suggest any alternate for this to maintain index up to date,
along with needs your input on how to manage ACL ?
Thanks a lot.
--
View this message in context:
http://lucene.472066.n3.nabble.com/hot-shard-concept-tp4016676p4017491.html
Sent from the Solr
On 10/30/2012 5:05 AM, Dmitry Kan wrote:
Hi Shawn,
Thanks for sharing your story. Let me get it right:
How do you keep the incremental shard slim enough over time, do you
periodically redistribute the documents from it onto cold shards? If yes,
how technically you do it: the Lucene low-level wa
index is being partitioned low level using Lucene's
>> IndexReader / IndexWriter with the implementation based on [1], [2] and
>> customized to logical (time-based) sharding.
>>
>>
>> The question is: is doing index partitioning low-level a good way of
>> imple
artitioning low-level a good way of
implementing the hot shard concept? That is, is there anything better
operationally-wise from the point of view of disaster recovery / search
cluster support? Am I missing some obvious SOLR-ish solution?
Doing instead the periodical hot shard cleaning and re-posting its s
cold shard. And for that...
3) hot shard index is being partitioned low level using Lucene's
IndexReader / IndexWriter with the implementation based on [1], [2] and
customized to logical (time-based) sharding.
The question is: is doing index partitioning low-level a good way of
implementing
