Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[store/tikv] support batch coprocessor for TiFlash (#16030) #16226

Merged
merged 2 commits into from
Apr 9, 2020

Conversation

sre-bot
Copy link
Contributor

@sre-bot sre-bot commented Apr 9, 2020

cherry-pick #16030 to release-4.0


What problem does this PR solve?

Send batch coprocessor request which contains multiple regions to TiFlash Engine

Problem Summary:

What is changed and how it works?

What's Changed:
In old time, tidb sends requests to tiflash in the way of per region per requests. But most queries that send to tiflash will involves massive regions, which have huge overhead. And tiflash cannot decide the concurrency of runtime by itself.

How it Works:

  • Firstly, we squash multiple copTask to a huge batchCopTask, and compile it to protocal coprocessor.BatchRequest.
  • Then, It recieve request in a grpc streaming.
  • Notably, TiFlash will process RegionError and Lock Error by itself, and only return Other Error that cannot retry.

Related changes

we update kvproto pingcap/kvproto#586

####Side effects

We use a system variable tidb_allow_batch_cop to switch the batch cop mode. It has no effect on requests that send to tikv. For TiFlash, it only effects queries like 'Aggregation' and 'TopN' by default. In conclusion, its risk is very low.

**TPCH 50G Benchmark result **

old new
q1 14s 11.5s
q6 3.7s 2.6s

Release note

@sre-bot sre-bot requested a review from a team as a code owner April 9, 2020 05:02
@sre-bot
Copy link
Contributor Author

sre-bot commented Apr 9, 2020

/run-all-tests

Copy link
Contributor

@lzmhhh123 lzmhhh123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lzmhhh123 lzmhhh123 added the status/LGT1 Indicates that a PR has LGTM 1. label Apr 9, 2020
Copy link
Contributor

@wshwsh12 wshwsh12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@wshwsh12 wshwsh12 added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Apr 9, 2020
@zz-jason zz-jason added the status/can-merge Indicates a PR has been approved by a committer. label Apr 9, 2020
@sre-bot
Copy link
Contributor Author

sre-bot commented Apr 9, 2020

Your auto merge job has been accepted, waiting for 16053

@sre-bot
Copy link
Contributor Author

sre-bot commented Apr 9, 2020

/run-all-tests

@sre-bot sre-bot merged commit b55b619 into pingcap:release-4.0 Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/execution SIG execution status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/4.0-cherry-pick
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants