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
Shawn this seems to be a great implementation work.
I am also trying to do something similar. But i am planning to use
SolrCloud which manages shards and replication automatically,pls make me
correct if i am wrong. I had explored mongoDB and cassandra too and mongoDB
was fair enough to be used, b
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
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 way or Solr / SolrJ way?
-dmitry
On Mon, Oc
On 10/29/2012 7:55 AM, Dmitry Kan wrote:
Hi everyone,
at this year's Berlin Buzz words conference someone (sematext?) have
described a technique of a hot shard. The idea is to have a slim shard to
maximize the update throughput during a day (when millions of docs need to
be posted) and make sure
