为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】生产
【概述】
主键和唯一索引
Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID
普通二级索引
Key: tablePrefix{TableID}_indexPrefixSep{IndexID}indexedColumnsValue{RowID}
Value: null
请问在TIDB中,单表的数据量特别大时,是否还需要对表进行分表?否则单表数据量很大,会存在大量相同的tablePrefix{TableID},这里寻址也会增加查询时间
【问题】 是否需要分表?
【业务影响】
【TiDB 版本】 5.4
【应用软件及版本】
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。
1 个赞
虽然他们都有同一个table_id ,但是他们会根据tikv数量将region平均分布到每个tikv,对于数据操作也是以region为单位进行操作的,所以我认为不需要对表进行拆分。
1 个赞
数据小黑
(数据小黑)
3
这里有具体的原理介绍:https://pingcap.com/zh/blog/tidb-internal-2
数据库有很多优化措施,在分表之前,做适当的分区,增加二级索引等等都会让表的索引扫描效率得到优化。TiDB的架构决定了单表可以有比较高的数据装载,最近在做的测试,在官方最小机器配置下部署,单表1亿,全表扫的情况下,查询速度仍然能够接受。当然这样的说法也比较绝对,可以在适当的场景描述下,做一些讨论,脱离场景不好描述。
1 个赞
h5n1
(H5n1)
4
表key: txxx_rxxxxx ,索引key: txxx_ixxx, 表数据间不会插入索引key,即使全表扫描也不会读取到index key
那在索引上,如果单个Table数据量较少时,REGION数量也会少,应该会可快速定位到INDEX_ROW的索引吧?表的数据是按照RowId排序在region上的,RowID单个表内唯一,如果表数据量较少,那么Row顺序读可能性会更大?
tidb的特点就是横向扩展,对业务透明,分表是单机承载有上限的MySQL才要考虑的
1 个赞
啦啦啦啦啦
7
不需要吧,本来很多从mysql迁移到tidb就是为了不分表增加业务的复杂度,如果在分表就本末倒置了吧,tidb单表用合适的分区和索引就能解决大部分问题。
2 个赞
逍遥_猫
8
理论上来说是不需要,但是我感觉如果数据量很大,还是要根据不同的业务需要
数据小黑
(数据小黑)
9
我举得那个例子,业务老大主动说按地域分表,按时间分区,每个地域总的数据量在3-5亿之间。其实如果业务不嫌麻烦,合适数据量的表,还是比较好维护的,虽然这并不是tidb的能力上限,基于新业务保守一点可以规避风险的原因,我没有反对分表,
TiDB就是要解决大数据量的数据处理的,本身实现上会拆分到不同的Region中
3 个赞
边城元元
(边城元元)
12
tidb特性之一就是解决了 大表在mysql下要采用分库分表的痛点
如果在tidb再考虑分表的话,相当没有必要。
如果在不影响业务的话,可以作为冷数据隔离到历史表中(后期做离线),但是通常使用tidb都是为了全量数据的实时处理,总之一句话没有必要考虑分表。
4 个赞
逍遥_猫
14
TIDB是可以处理海量数据,不过也要分不同的业务场景 和业务需求,每天大量的数据 批处理 感觉 无论从风险还是 从 避免大量 region 的调度来说,还是分区比较合适
数据小黑
(数据小黑)
15
确实是这样,TiDB在一定程度上可以认为缓解了分库分表的问题,但单表的分区对性能来说仍然是个很好的选择,除了维表之外,我们大部分事实表也都是分区的。
JiekeXu
(徐小强)
16
是否需要分表也是相对而言的,如果单表出现性能问题,那么首先要考虑的是性能问题的优化,热点问题打散、建索引、分区 等等,分库、分表都是已经没有了可优化的手段出现的最后考虑策略,按照现在 TiDB 的性能,还是不考虑分表为好。
db_user
(Db User)
17
我觉得优先考虑分区,如果分表,然后再借助中间件,那和传统数据库也没啥区别了,没有tidb的优势了
h5n1
(H5n1)
18
tidb就是分库分表终结者,上了tidb就不要考虑分库分表了,目前tug上看到的最大集群有300多T的,还是考虑分区,不过现在List分区 和动态分区裁剪还没GA,也影响分区表关联使用索引
TiDB已经是range默认分了,分布式数据库就是解决这个问题的。所以不需要
system
(system)
关闭
20
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。