Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-15752

Range read concurrency factor didn't consider range merger

    XMLWordPrintableJSON

    Details

      Description

      During range read, coordinator computes concurrency factor which is the number of vnode ranges to contact in parallel for the next batch.

      But in RangeCommandIterator, vnode ranges are merged by RangeMerger if vnode ranges share enough replicas to satisfy consistency level. eg. vnode range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4, so they can be merged as range [a,c) with replica n2, n3 for Quorum.

      Currently it counts number of merged ranges towards concurrency factor. Coordinator may fetch more ranges than needed.


      Another issue is that when executing range read on table with very small amount of data, concurrency factor can be bumped to size of total vnode ranges, eg. 10k, depending on the num of vnodes and cluster size. As a result, coordinator will send large number of concurrent range requests, potentially slowing down the cluster.. We should cap the max concurrency factor..

        Attachments

          Activity

            People

            • Assignee:
              jasonstack Zhao Yang
              Reporter:
              jasonstack Zhao Yang
              Authors:
              Zhao Yang
              Reviewers:
              Andres de la Peña, Caleb Rackliffe
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: