Region为什么要设置最大大小为96M

看了tidb in action,多个表的数据都会写入到rocksdb,意味着共用memtable的大小128M(flush的大小)。这么说,表的Region应该只是一个逻辑概念,实际上并没有物理上按照Region来保存数据(虽然实际上由于key的构造是按照表id+rowid来,导致最终同表同Region的数据排序后会放到一起)。那设置Region大小不超过96M有什么意义呢?只是为了以此出发Region分裂制造多个写入点吗?如果只是为了多个写入点,为什么不create table的时候增加Region的说明呢?另外,按照行数阈值触发Region分裂不会更好吗?单个Region的数据不形成独立的文件,那么统计其空间大小我感觉是不好做的(虽然我现在还不知道tikv是怎么统计一个region用了96MiB空间)。我是从应用开发角度来思考这个问题,感觉有点不解。

可能是基于性能与资源开销的平衡,可扩展性与灵活性以及限制条件等多方面因素的综合考虑。

  1. 性能平衡:适当大小的 Region 可以平衡数据分布和查询性能。过小的 Region 会导致 Region 数量过多,增加资源消耗和性能下降;过大的 Region 则可能导致性能不稳定和查询性能下降。
  2. 资源消耗:过大的 Region 可能导致资源消耗过多,影响 TiKV 的性能。
  3. Region 调度:过大的 Region 可能导致 Region 调度变慢,影响数据的均衡性和性能。

96 MiB 是一个推荐的默认值.
你可以根据实际情况和需求来调整 Region 的大小。根据文档建议,Region 大小的推荐范围是 [48MiB, 258MiB],常用的大小包括 96 MiB、128 MiB 和 256 MiB。避免将 Region 大小设置超过 1 GiB,以避免性能波动和查询性能下降的情况发生。

Region是个逻辑上的概念,rocksdb本身没有这个概念,数据存储也没有用到这个。
region是分布式数据库用来做调度的单位

这些都是笼统的说法,有没有实验数据说明这个Region的设置能够让系统性能更好呀。

我之所以提这个问题,是因为每个表的情况不一样,划分Region应该是根据表的情况来确定。譬如有些表它就是插入一次,然后就静态了,而且数量不多,你管他那么多,就放一个region里面就好了呀。有些表经常删减变动,需要大量导入数据,那肯定维持多个region,才能体现分布式效果。把这个region的设置放到db的层面是否有些鲁莽呀?

即使是静态表,就一个region的话,读取性能也会受影响。

region大小默认96M,region太大或太小都不太好。有合并或分割的情况。会有一个范围值,触发相应的操作。
理论联系实际,现实生活中也有许许多多的类似情况。

Region太大太小都不好,需要均衡考虑,其他分布式也类似,就比如MONGODB一个chunk大小是64M

肯定是“权衡”下的“建议”默认值,都也留了“口子”允许调整,做产品应该都是这思路,“按业务需求”调整 region 大小,数据库没有办法穷举

96M应该是默认设的值,不是一个新region初始的值。

96MB,来源于网络传输优化的经验,

1000MB 的网络,传输大概是 9.6 mb/s,
然后 1W MB 的网络,传输大概是 96 mb/s,
刚好是一个region 的大小,这样有利于调度和并发,不会超过这个界定的大小,避免受限于网络上的物理限制,是最大的优化方案。

所以,生产的tidb 集群推荐的是 双 W 兆的网卡。

供你参考!

5 个赞

原来如此,像大佬学习~!

关于为什么不在 CREATE TABLE 时指定 Region 的大小或按照行数阈值触发 Region 分裂,主要考虑如下:
灵活性:动态调整 Region 的大小和分布可以更好地适应不同工作负载的变化,而不需要预先知道每张表的数据特性和访问模式。
系统级优化:由系统自动管理 Region 的分裂和合并,可以避免用户需要深入理解底层存储细节,使得 TiDB 更易于使用和维护。
至于如何统计一个 Region 占用的空间,TiKV 通过监控每个 Region 的元数据信息(如已使用的存储空间)来实现。这包括跟踪每个 Region 的写入和删除操作,以及定期进行的垃圾回收过程。这些信息可以帮助系统实时了解每个 Region 的当前状态,并据此做出分裂或合并的决策。

1 个赞

其实就是经过多次尝试后找到的一个相对平衡点

马上默认大小就行1G了

2 个赞

系统的默认值是96M,可以修改参数改变这个默认值。

各位大佬的回答对我都很有帮助,谢谢各位大佬。

96m估计也是不断测试,找到的一个适合的值。

应该是 raft协议复制的考虑