[
https://issues.apache.org/jira/browse/SOLR-16348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606591#comment-17606591
]
David Smiley commented on SOLR-16348:
-------------------------------------
Perhaps the first implementation doesn't need to cap the number of splits
occurring on the node at the same time. That requirement made the
implementation proposal more complicated. Besides, the split "link" method is
cheap. Also, a skew factor could be used to reduce number of simultaneous
shards that would be splitting, assuming that many shards are likely to cross
the threshold at the same time. It would need to be computed in a consistently
random way such that, say, a shard name's hash is the seed of the random used
to compute the skew. WDYT [~broustant]?
> New SplitShard UpdateRequestProcessor
> -------------------------------------
>
> Key: SOLR-16348
> URL: https://issues.apache.org/jira/browse/SOLR-16348
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
> Reporter: David Smiley
> Priority: Major
>
> The
> [SplitShard|https://solr.apache.org/guide/solr/latest/deployment-guide/shard-management.html#splitshard]
> command is used to split a shard into smaller shards to get better query
> scalability, especially across multiple machines. The most practical way to
> use it is to split shards larger than a configured size. Of course shards
> don't just grow by themselves; they grow when data is added. Here I propose
> a new UpdateRequestProcessor that splits based on the shard size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
