make region size dynamic #82

BusyJay · 2021-11-29T10:01:02Z

No description provided.

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

feitian124 · 2021-11-30T01:38:22Z

text/0082-dynamic-size-region.md

+### Dynamic size
+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions
+and 10GiB for cold regions. So there are two types of split, hotspot split and general size split. Hotspot


To make it simplified, we choose 512MiB for hot regions
and 10GiB for cold regions.

here is for simplify the description of the idea in this document, or simplify the implements?
512Mib is fixed?
so simplify here means hot region size is 1/2 of normal one? it is fixed or configable?
how much performance increase expected by reduce hot reigion size to 1/2 ?

Simplify implementation. I don't think it's 1/2, but rather 5%. It's configurable. Using a small size is to make it easy to schedule around and balance quickly.

sorry i misread it. 5% and configurable sounds reasonable.

feitian124 · 2021-11-30T02:05:33Z

text/0082-dynamic-size-region.md

+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate


does split buckets mean split region? what is your mean by scan. could you make bucket concept more clear?

I'm not sure why do you think it's related to split region. As described in text and image, buckets are logical segments of a region range.

as per your description, bucket is a logical concept.
no matter how you split buckets, they still in the same region. unless the owner region split, i am not sure how can a physical region splits into logic buckets improve performance.

no matter how you split buckets, they still in the same region.

Yes, it's exactly what it means.

Buckets are used for mainly two purpose: 1. collect access statistics, which can be used by PD to detect hotpots and decides to whether split a region; 2. TiKV side concurrency, a full scan request will be divided into smaller concurrent scan.

When a region becomes hot, does the bucket need to be re-split since it uses a different split policy?

Yes, works most like current region scan split.

text/0082-dynamic-size-region.md

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

bufferflies · 2021-11-30T08:12:13Z

text/0082-dynamic-size-region.md

+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions
+and 10GiB for cold regions. So there are two types of split, hotspot split and general size split. Hotspot
+split is triggered by PD. General size split is triggered by TiKV itself.


will it include hotspot and region size??

What does "it" mean?

it means PD.

No, PD only needs to do hotspot split.

Does it mean the current load base split logic will move to PD?

Yes, exact the key and statistics collection.

bufferflies · 2021-12-01T06:21:41Z

text/0082-dynamic-size-region.md

+
+### Flow report
+
+Buckets statistics are reported in a standalone stream. They will be reported more frequently


In past, TiKV seperates read and write in different channel. should it uniform them in one channel .

Either way is OK. It depends on the implementation difficulty.

hicqu · 2021-12-01T08:14:04Z

text/0082-dynamic-size-region.md

+controllable to let PD split hotspots and schedule to get balance.
+
+Now that a region can be in 10GiB, a full scan can make the response exceed the limit of gRPC,
+which is 4GiB. So instead of unary, we need to use server streaming RPC to return the response as


we need to user server streaming RPC

Is it confirmed or just a candidate solution? An alternative is make clients send ranges instead of Region, maybe we can discuss about which is better.

It's a candidate solution. I prefer client sends a unary request with the whole range. It's simple and efficient. Otherwise, TiDB may waste CPU at batch RPCs. A similar problem can be found here: tikv/client-go#342.

But streaming API is deprecated in TiDB

It would be much easier to retry if TiDB split the request into buckets, each bucket can be sent concurrently.

If there is leader change, a single bucket request can be send to the new leader, the previous succeed bucket requests don't need to retry.

If the request is split in TiKV side, snapshot is retrieved once, so there is no such case that retry some of the buckets due to leader change.

If TiKV is slow, and TiDB encounter frequently time out, retry the whole region request would make the situation much worse.

Then TiDB can change the behavior of retrying, it can know what ranges are missing easily.

I left unary vs streaming as an unresolved question and will make decision by evaluation on maintainability and performance.

BusyJay · 2021-12-01T08:22:20Z

/cc @solotzg you may also be interested in this RFC.

text/0082-dynamic-size-region.md

...and improvement on replication Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

solotzg · 2021-12-01T10:17:55Z

What's the conclusion about tikv/pd#4326? Will PD split region by placement rules or not? @disksing

BusyJay · 2021-12-01T11:11:45Z

In the long term, I think the answer is Yes, especially when all system without tiflash have less regions and perform better. But in the short term, we can hold the task to avoid too much work.

coocood · 2021-12-02T03:05:38Z

text/0082-dynamic-size-region.md

+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate
+range size. Every bucket should have the size about 128MiB. Their ranges and stats are all reported to PD. PD


If all the bucket stats are reported to PD, it would consume a lot of memory.
We only need to report bucket stats when read/write workload exceed a threshold.

So for most of the regions, we only need to report the range of buckets.
The total memory on PD would be greatly reduced.

The bucket size is about 128MiB, which means it can consume as much as the memory current small regions use. As far as I know, it's not an issue yet.

@coocood Good point. Do you know what's the roughly memory consumption per region in PD today?
For 128MB bucket and 1PB total database size, it's about 800 million buckets.

@BusyJay For bucket stats report, will both leader and follower need to report their buckets? And I guess it's very likely for the same region, the bucket range may be different. If only leader reports the buckets stats, then PD will have to add the follower buckets stats when calculating the machine level stats, or report machine level stats separately.

Currently, the small region will report statistics on both the leader and follower. the TopN(1000) hot region's stats of this node will be reported not all. may buckets can keep the same behavior.

...the bucket range may be different.

It doesn't matter. Only leader's buckets are used and follower's stats will be merged into leaders using similar algorithm described in flow report section.

the TopN(1000) hot region's stats of this node will be reported not all.

I'm worried about accuracy and message layout. I prefer to report all metrics and do filter on the PD side. Let's see how it performs first.

coocood · 2021-12-02T03:10:46Z

text/0082-dynamic-size-region.md

+
+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket


Do we need to introduce a bucket version field in metapb::Region?
So each time we update the buckets, the bucket version increases.

No, buckets are not shared by regions. It's a peer's own property. So metapb::Region should not be modified. I'm not sure if version is useful, as final consistency is acceptable.

If the buckets is not included in metapb::Region then there should be a new type metapb::RegionBuckets.
TiDB can query this info from PD, and use them to build requests.

coocood · 2021-12-02T03:23:22Z

text/0082-dynamic-size-region.md

+apply to make single region apply logs faster. Since unorder apply is a standalone feature, I’m not
+going into details here.
+
+For read hotspots, split should be triggered by PD, which can utilize the global statics from all


s/statics/stats

nolouch · 2021-12-02T03:40:51Z

text/0082-dynamic-size-region.md

+
+### Dynamic size
+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions


I wonder 512 is too big if the hotspot is small tables.will the split size set a lower limit?

512 is too big if the hotspot is small tables

It's configurable. As long as only a small number of hotspots are maintained, the size of hotspot doesn't matter.

will the split size set a lower limit?

Yes, and it's configured as 512MiB for now.

Do we use the same heartbeat interval for both cold and hot regions?

It's unspecified. Either hibernate or awake feel good to me.

nolouch · 2021-12-02T03:49:09Z

text/0082-dynamic-size-region.md

+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate
+range size. Every bucket should have the size about 128MiB. Their ranges and stats are all reported to PD. PD
+can detect hot buckets from all regions and decide whether need to split new hotspots and schedules them to


I think this part need more supplements. cc @bufferflies.

BTW, Is it recommend only split the region from the boundaries of buckets? the split key is more reasonable determined by query statistics, the key may from query.

I think this part need more supplements

It's covered at https://github.com/tikv/rfcs/pull/82/files#diff-ec76198abf750cd69e94e0e14564aea21f6f2de06d0bf85829d6d68969f36d20R107-R110.

...from the boundaries of buckets

Yes, the split key is chosen from the boundaries of buckets. As long as hotspots are not split into two accidentally, I think it's not worse than query statistics. And query statistics is unpredictable and changed frequently, makes buckets hard to maintain.

nolouch · 2021-12-02T04:03:28Z

text/0082-dynamic-size-region.md

+
+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket


Currently the query stat is collect by region-level, such as the range scan [start_key, end_key], may cover bucket 1 to10 in this region, how to split it by buckets?
If the scan will divide into sub-scan in buckets, and we only know the stats in buckets. It will make us cannot know the split cost. for example, the scan request in this region may split into two scan requests or still only one scan request(region-level), it's decided by the split key whether in the range scan.

Scan request will be split into buckets and access statistics are collected at bucket level.

I'm not sure what does "split cost" mean.

split will make RPC increase, in some scenarios we need to make a trade-off.

I don't think we need to consider the RPC count for now. But I agree there might be many choices on choosing split keys. I don't think we can get a best solution without a lot of experiments. The RFC avoid describing concrete algorithm on purpose to not make false assumptions.

rleungx · 2021-12-02T09:55:26Z

text/0082-dynamic-size-region.md

+
+### Dynamic size
+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions


Do we use the same heartbeat interval for both cold and hot regions?

rleungx · 2021-12-02T09:56:34Z

text/0082-dynamic-size-region.md

+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions
+and 10GiB for cold regions. So there are two types of split, hotspot split and general size split. Hotspot
+split is triggered by PD. General size split is triggered by TiKV itself.


Does it mean the current load base split logic will move to PD?

text/0082-dynamic-size-region.md

rleungx · 2021-12-03T04:26:38Z

text/0082-dynamic-size-region.md

+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate


When a region becomes hot, does the bucket need to be re-split since it uses a different split policy?

rleungx · 2021-12-03T04:34:57Z

text/0082-dynamic-size-region.md

+- GC will still wake up all regions and cause periodical high usage.
+
+There are two source of region creations: size/keys split and table split. Table split is disabled by
+default in TiKV. Even if it splits a lot of regions, small one will be merged later.


We may need more details about merge, e.g. should we try to move a smaller region instead of a larger region.

It depends on the emergency. If it's hotspot, then it should be split first and then moved. Otherwise, no need to split unless impossible to get size balance.

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

5kbpers · 2021-12-07T08:39:45Z

text/0082-dynamic-size-region.md

@@ -61,6 +61,20 @@ balance.

 ![dynamic size buckets](../media/dynamic-size-buckets.png)

+A new bucket metadata will be added to kvproto:
+```
+message Buckets {


Should we allocate an ID for each bucket to reduce the size of requests from clients?

The ID could consist of term and version of the region and a number.

...reduce the size of requests from clients?

I don't get it. Client should send the range it wants to scan, so it has to be precisely start key and end key. How can ID reduce the size?

Bucket is supposed to be changed independently from region. For example, client can re-use last overlapping buckets even a region split.

It can optimize for queries that need to scan the whole bucket.

Because bucket keys are generated by even split, so the range of a query is probably different from the bucket edges.

rleungx · 2021-12-07T09:27:10Z

text/0082-dynamic-size-region.md

+### Compatibility
+
+As buckets don't modify existing metadata, so it's backward compatible. When upgrading from small
+regions, PD may trigger a lot of merge to get a large region size. This procedure should be made


If we have some regions with heavy requests in different stores, we don't need to merge it until it cools down. But the calculation way of statistics of the bucket may be different which may encounter problems.

nolouch

As the Region is bigger, the access pattern in one region will more complicated. especially on read-write pattern, it will make hot region have read-write conflicts. I think how to better split and help scheduling to solve the problem of read-write conflict is a more complicated and challenging problem that we will encounter in the follow-up.

nolouch · 2021-12-07T10:03:08Z

text/0082-dynamic-size-region.md

+
+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket


split will make RPC increase, in some scenarios we need to make a trade-off.

nolouch · 2021-12-07T10:08:01Z

text/0082-dynamic-size-region.md

+than original region heartbeats, which is 60s. The new stream is expected to be reported every
+10 seconds when have changes.
+
+PD will maintain top N hot spot buckets and split all of those buckets that exceed P of


I think

The Bucket needs to have a unique identifier. and it should like region split, use right derive. otherwise PD cannot know it is a stable hot bucket or it is a traffic peak.

In most cases, it can be split from the boundary key of the bucket. but still need make load-base split key strategy or other strategy by PD can be accept.

... it should like region split, use right derive

This can be very complicated. How about handling load trace on PD side? For example, if the buckets are [a, d), [d, f) in the past, and the new version is [a, c), [c, e), [e, f). Then history H[a, d) should be inherited by both [a, c) and [c, e), history H[d, f) is inherited by both [c, e) and [e, f). The overlapped histories should be sum up. And the inherited history statistic can be optionally multiply by a factor like 0.8 to make process smoothly.

...make load-base split key strategy or other strategy by PD...

It's up to PD to split by any keys. It's recommended to choose bucket boundary.

I think this method also complicated. Do you mean that the bucket boundary may be different every time? [a, d)[d ,f) change to [a, c), [c, e), [e, f); d is gone.

It can change, but it only changes when there are many updates.

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

nolouch

lgtm

nolouch · 2021-12-08T13:46:43Z

text/0082-dynamic-size-region.md

+    uint64 region_id = 1;
+    uint64 version = 2; // A hint indicate if keys have changed.
+    repeated bytes keys = 3;
+    repeated uint64 read = 4;


How about using a separate message inside here, we may add other statics.

repeated BucketStats stats = 3

The goal is to reduce the flow. If using a message, the overhead will become 1 * field count * bucket count + actual number length + 2 * bucket count. If using separate arrays, the overhead become 2 * field count + actual number length.

5kbpers

LGTM

tonyxuqqi · 2021-12-08T18:14:11Z

LGTM

tonyxuqqi · 2021-12-01T00:04:16Z

text/0082-dynamic-size-region.md

+### Dynamic size
+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions
+and 10GiB for cold regions. So there are two types of split, hotspot split and general size split. Hotspot


Suggestion: "hotspot split" can be renamed with existing term: "load based split". Don't introduce new terms whenever possible.

tonyxuqqi · 2021-12-01T00:06:25Z

text/0082-dynamic-size-region.md

+### Dynamic size
+
+The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions
+and 10GiB for cold regions. So there are two types of split, hotspot split and general size split. Hotspot


At this point, since we haven't done extensive test regarding region size comparison, I think the numbers such as 512MB, 10GB are not finalized.

Yes, it's mentioned that they are configurable.

tonyxuqqi · 2021-12-01T00:19:11Z

text/0082-dynamic-size-region.md

+### Bucket
+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate


"buckets are split" is confusing---we never split a bucket. I guess "buckets are created" are better.

tonyxuqqi · 2021-12-01T00:20:19Z

text/0082-dynamic-size-region.md

+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate
+range size. Every bucket should have the size about 128MiB. Their ranges and stats are all reported to PD. PD


Why it's not 96MB?

Recap the offline discussion here. There's another option that can achieve similar function but more scale and less complexity to PD.
TiKV handles bucket traffic details and PD are only aware bucket key range but not traffic stats. And TiKV does the split itself with its local data, with some threshold PD generates periodically from the global view of traffic by collection machine level traffic stats.
The concern I have for current solution is that in a 1PB database, that means PD needs to collect and process 8 million entries at sub-seconds level interval. Today PD is essentially single node component (followers do not take requests). Not sure the impact to PD.

tonyxuqqi · 2021-12-01T02:15:13Z

text/0082-dynamic-size-region.md

+For read hotspots, split should be triggered by PD, which can utilize the global statics from all
+regions and nodes. For normal read requests, TiKV will need to split its range into smaller buckets
+according to statics to increase concurrency. When TiDB wants to do a scan, it sends the RPC once,
+and TiKV will split the requests into smaller concurrent jobs.


For a large region and stale read is enabled, I think it might be better to distribute the read load among followers. It's up to TiDB to make the choice.

tonyxuqqi · 2021-12-01T02:21:44Z

text/0082-dynamic-size-region.md

+and TiKV will split the requests into smaller concurrent jobs.
+
+In the past design, follower read has also been discussed to offload works from leader. But TiDB
+can’t predict the progress of a follower, so latency can also become unpredictable. It’s more


In follower read, can TiDB skip these peers who are obviously behind the leader more than a threshold?

I think it can, but it doesn't.

tonyxuqqi · 2021-12-08T18:23:24Z

text/0082-dynamic-size-region.md

+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate
+range size. Every bucket should have the size about 128MiB. Their ranges and stats are all reported to PD. PD


@coocood Good point. Do you know what's the roughly memory consumption per region in PD today?
For 128MB bucket and 1PB total database size, it's about 800 million buckets.

tonyxuqqi · 2021-12-08T18:28:56Z

text/0082-dynamic-size-region.md

+
+A region is split into several buckets logically. We will collect query stats by buckets and report the bucket
+to PD. For hotspot regions, buckets are split by scan. For cold regions, buckets are split by approximate
+range size. Every bucket should have the size about 128MiB. Their ranges and stats are all reported to PD. PD


@BusyJay For bucket stats report, will both leader and follower need to report their buckets? And I guess it's very likely for the same region, the bucket range may be different. If only leader reports the buckets stats, then PD will have to add the follower buckets stats when calculating the machine level stats, or report machine level stats separately.

tonyxuqqi · 2021-12-08T18:31:31Z

text/0082-dynamic-size-region.md

+
+A new bucket metadata will be added to kvproto:
+```
+message Buckets {


Should it be renamed as BucketStats?
Also where's the key range definition?

It's defined as the third field keys.

tonyxuqqi · 2021-12-08T21:04:42Z

text/0082-dynamic-size-region.md

+may be complicated. And we rely on further designs like separating LSM tree to optimize the cost
+for all.
+
+### Compatibility


If we implement the feature in the way that buckets are just optional and optimization for big region size, then by its nature it's backward compatible.
And there's nothing prevent user from using small region, so this should be well supported in the long term as well. For small to medium size cluster, it's likely user will keep the small region size.

tonyxuqqi · 2021-12-08T21:07:32Z

text/0082-dynamic-size-region.md

+
+10GiB is just an example, it's allowed to change to a bigger or smaller value.
+
+### Bucket


Since we measure the read/write load at bucket level, which means it's about 128MB size. How can we further split a hot bucket? Today we have load-based split, which may cut the small region by the access pattern.

I don't have a clear idea now. I will leave it as an unresolved question. Maybe we can split the bucket further. For example, besides controlling the size of a bucket, also require the minimal count of a bucket. So even a region becomes small, it can still be split further.

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

Signed-off-by: Jay Lee <BusyJayLee@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com>

* RFC: RawKV Batch Export (#76) Signed-off-by: pingyu <yuping@pingcap.com> * rawkv bulk load: add description for pause merge (#74) * rawkv bulk load: add description for pause merge Signed-off-by: Peng Guanwen <pg999w@outlook.com> * Update text/0072-online-bulk-load-for-rawkv.md Co-authored-by: Liangliang Gu <marsishandsome@gmail.com> Signed-off-by: Peng Guanwen <pg999w@outlook.com> * Add future improvements Signed-off-by: Peng Guanwen <pg999w@outlook.com> Co-authored-by: Liangliang Gu <marsishandsome@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * ref pd#4112: implementation detail of PD Signed-off-by: pingyu <yuping@pingcap.com> * ref pd#4112: implementation detail of PD Signed-off-by: pingyu <yuping@pingcap.com> * remove raw cf Signed-off-by: Andy Lok <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * update Signed-off-by: Andy Lok <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * update pd design Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * revert to keyspace_next_id Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * RFC: Improve the Scalability of TSO Service (#78) Signed-off-by: pingyu <yuping@pingcap.com> * make region size dynamic (#82) Signed-off-by: Jay Lee <BusyJayLee@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * update pd url Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * address comment Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * resolve pd flashback problem Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * update rfcs Signed-off-by: Andy Lok <andylokandy@hotmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * RFC: In-memory Pessimistic Locks (#77) * RFC: In-memory Pessimistic Locks Signed-off-by: Yilin Chen <sticnarf@gmail.com> * clarify where to delete memory locks after writing a lock CF KV Signed-off-by: Yilin Chen <sticnarf@gmail.com> * Elaborate transfer leader handlings and add correctness section Signed-off-by: Yilin Chen <sticnarf@gmail.com> * add an addition step of proposing pessimistic locks before transferring leader Signed-off-by: Yilin Chen <sticnarf@gmail.com> * clarify about new leaders of region split Signed-off-by: Yilin Chen <sticnarf@gmail.com> * Add tracking issue link Signed-off-by: Yilin Chen <sticnarf@gmail.com> * update design and correctness analysis of lock migration Signed-off-by: Yilin Chen <sticnarf@gmail.com> * add configurations Signed-off-by: Yilin Chen <sticnarf@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * propose online unsafe recovery (#91) Signed-off-by: Connor1996 <zbk602423539@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * physical isolation between region (#93) Signed-off-by: Jay Lee <BusyJayLee@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com> * wip Signed-off-by: pingyu <yuping@pingcap.com> * update Signed-off-by: pingyu <yuping@pingcap.com> * update Signed-off-by: pingyu <yuping@pingcap.com> * Apply suggestions from code review Co-authored-by: Xiaoguang Sun <sunxiaoguang@users.noreply.github.com> Signed-off-by: pingyu <yuping@pingcap.com> * fix case Signed-off-by: pingyu <yuping@pingcap.com> Signed-off-by: pingyu <yuping@pingcap.com> Signed-off-by: Andy Lok <andylokandy@hotmail.com> Signed-off-by: andylokandy <andylokandy@hotmail.com> Signed-off-by: Jay Lee <BusyJayLee@gmail.com> Signed-off-by: Yilin Chen <sticnarf@gmail.com> Signed-off-by: Connor1996 <zbk602423539@gmail.com> Co-authored-by: Liangliang Gu <marsishandsome@gmail.com> Co-authored-by: Peng Guanwen <pg999w@outlook.com> Co-authored-by: Andy Lok <andylokandy@hotmail.com> Co-authored-by: JmPotato <ghzpotato@gmail.com> Co-authored-by: Jay <BusyJay@users.noreply.github.com> Co-authored-by: Yilin Chen <sticnarf@gmail.com> Co-authored-by: Connor <zbk602423539@gmail.com> Co-authored-by: Xiaoguang Sun <sunxiaoguang@users.noreply.github.com>

make region size dynamic

c5b39f8

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

BusyJay added the Initial Comment Period This RFC is in the initial comment period, and has quite some time to give input on. label Nov 29, 2021

BusyJay requested review from hicqu and zhangjinpeng87 November 29, 2021 10:01

update pull request ID

0551d13

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

feitian124 reviewed Nov 30, 2021

View reviewed changes

5kbpers reviewed Nov 30, 2021

View reviewed changes

text/0082-dynamic-size-region.md Show resolved Hide resolved

BusyJay mentioned this pull request Nov 30, 2021

Tracking issue for making region size dynamic tikv/tikv#11515

Open

11 tasks

add tracking issue

28c46cc

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

bufferflies reviewed Nov 30, 2021

View reviewed changes

bufferflies reviewed Dec 1, 2021

View reviewed changes

hicqu reviewed Dec 1, 2021

View reviewed changes

text/0082-dynamic-size-region.md Show resolved Hide resolved

hicqu reviewed Dec 1, 2021

View reviewed changes

text/0082-dynamic-size-region.md Show resolved Hide resolved

explain how to split hotspot

8cd492d

...and improvement on replication Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

coocood reviewed Dec 2, 2021

View reviewed changes

nolouch reviewed Dec 2, 2021

View reviewed changes

rleungx reviewed Dec 2, 2021

View reviewed changes

rleungx reviewed Dec 3, 2021

View reviewed changes

BusyJay added 4 commits December 6, 2021 14:07

address comment

1166921

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

tidb side split and bucket metadata

f99c489

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

more on client side split

0e794b8

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

add page response

8e15e6e

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

coocood approved these changes Dec 7, 2021

View reviewed changes

fix spell

01dedde

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

5kbpers reviewed Dec 7, 2021

View reviewed changes

rleungx reviewed Dec 7, 2021

View reviewed changes

nolouch reviewed Dec 7, 2021

View reviewed changes

inheriting hisotry and delay merge

a3a0126

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

nolouch reviewed Dec 8, 2021

View reviewed changes

5kbpers approved these changes Dec 8, 2021

View reviewed changes

tonyxuqqi reviewed Dec 8, 2021

View reviewed changes

BusyJay and others added 2 commits December 9, 2021 18:56

address comment

8b0edda

Signed-off-by: Jay Lee <BusyJayLee@gmail.com>

Merge branch 'master' into dynamic-size

f8358ee

BusyJay added Final Comment Period This RFC is in the final comment period, and has a limited amount of time to give input on. and removed Initial Comment Period This RFC is in the initial comment period, and has quite some time to give input on. labels Dec 9, 2021

hicqu approved these changes Dec 9, 2021

View reviewed changes

BusyJay merged commit 8bd15f2 into tikv:master Dec 9, 2021

BusyJay deleted the dynamic-size branch December 9, 2021 16:57

BusyJay mentioned this pull request Jan 18, 2022

kvproto: add buckets related definitions --- ref #11759 pingcap/kvproto#849

Merged

YuJuncen mentioned this pull request Apr 22, 2022

br: adapt the new dynamic region feature pingcap/tidb#34167

Closed

2 tasks

lichunzhu mentioned this pull request May 10, 2022

lightning: adapt the new dynamic region feature pingcap/tidb#34536

Closed

BusyJay mentioned this pull request Jun 2, 2022

physical isolation between region #93

Merged

pingyu pushed a commit to pingyu/tikv-rfcs that referenced this pull request Nov 4, 2022

make region size dynamic (tikv#82)

242df0e

Signed-off-by: Jay Lee <BusyJayLee@gmail.com> Signed-off-by: pingyu <yuping@pingcap.com>


		### Flow report

		Buckets statistics are reported in a standalone stream. They will be reported more frequently


		### Bucket

		A region is split into several buckets logically. We will collect query stats by buckets and report the bucket


		### Dynamic size

		The hotter a region is, the smaller its size becomes. To make it simplified, we choose 512MiB for hot regions


		10GiB is just an example, it's allowed to change to a bigger or smaller value.

		### Bucket

make region size dynamic #82

make region size dynamic #82

Conversation

BusyJay commented Nov 29, 2021

feitian124 Nov 30, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hicqu Dec 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BusyJay commented Dec 1, 2021

solotzg commented Dec 1, 2021

BusyJay commented Dec 1, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nolouch Dec 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nolouch Dec 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nolouch Dec 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rleungx Dec 7, 2021 • edited Loading

Choose a reason for hiding this comment

nolouch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nolouch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feitian124 Nov 30, 2021 •

edited

Loading

hicqu Dec 1, 2021 •

edited

Loading

nolouch Dec 9, 2021 •

edited

Loading

nolouch Dec 2, 2021 •

edited

Loading

nolouch Dec 2, 2021 •

edited

Loading

rleungx Dec 7, 2021 •

edited

Loading