[jira] [Commented] (SOLR-12509) Improve SplitShardCmd performance and reliability

["Andrzej Bialecki (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-12509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16549474#comment-16549474 ] 

Andrzej Bialecki  commented on SOLR-12509:
------------------------------------------

This patch implements a new method for shard splitting that uses {{HardLinkCopyDirectoryWrapper}}. The old method is still available and used by default, and the new method may be selected by using {{splitMethod=link}} request parameter (the old method can be explicitly selected with {{splitMethod=rewrite}}).

There's also support for a new {{timing}} parameter - when set to true the SPLITSHARD command returns a "timing" section with elapsed times for each internal phase of the command execution.

I've been testing the new implementation locally and on a cluster of 5 physical nodes, using collections ranging from 2 mln up to 22 mln documents (15 GB index size). The new method consistently outperforms the old method by a factor of 3 to 5, depending on the index size and number of replicas.

The downside of the new method is that the resulting sub-shards initially have the same size as the original shard - on the shard leader these files are hard-linked so they don't consume additional space, but replica nodes still need to fetch all that data, which affects the network IO and the initial disk consumption on replica nodes.

Here are example timings for the old method:
{code}
  "timing":{
    "time":1547111.0,
    "checkDiskSpace":{
      "time":14.0},
    "fillRanges":{
      "time":2.0},
    "createSubSlicesAndLeadersInState":{
      "time":4439.0},
    "waitForSubSliceLeadersAlive":{
      "time":1009.0},
    "splitParentCore":{
      "time":1538986.0},
    "applyBufferedUpdates":{
      "time":7.0},
    "identifyNodesForReplicas":{
      "time":1.0},
    "createReplicaPlaceholders":{
      "time":7.0},
    "createCoresForReplicas":{
      "time":2173.0},
    "finalCommit":{
      "time":462.0}},
{code}
After that, sub-shard shard1_0 recovered in 220753 ms, so the total time was ca. 1770 sec.

 
And the timings for the new method, with exactly the same initial data layout, hardware, etc:
{code}
  "timing":{
    "time":15633.0,
    "checkDiskSpace":{
      "time":5.0},
    "fillRanges":{
      "time":2.0},
    "createSubSlicesAndLeadersInState":{
      "time":4411.0},
    "waitForSubSliceLeadersAlive":{
      "time":2.0},
    "splitParentCore":{
      "time":9005.0},
    "identifyNodesForReplicas":{
      "time":0.0},
    "createReplicaPlaceholders":{
      "time":2.0},
    "createCoresForReplicas":{
      "time":2105.0},
    "finalCommit":{
      "time":95.0}},
{code}
After that, sub-shard shard1_0 recovered in 443350 ms, so the total time was ca. 600 sec.


> Improve SplitShardCmd performance and reliability
> -------------------------------------------------
>
>                 Key: SOLR-12509
>                 URL: https://issues.apache.org/jira/browse/SOLR-12509
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>            Reporter: Andrzej Bialecki 
>            Assignee: Andrzej Bialecki 
>            Priority: Major
>         Attachments: SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so the splitting has to involve several carefully orchestrated steps, making sure that new sub-shard placeholders are properly created and visible, and then also applying buffered updates to the split leaders and performing recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively being updated or can tolerate a little downtime - we could put the shard "offline", ie. disable writing while the splitting is in progress (in order to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by hard-linking existing index segments, and then applying deletes to the documents that don't belong in a sub-shard. However, the resulting index slices that replicas would have to pull would be the same size as the whole shard.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org