每天约千万数据增量,是否有必要分表

🛰️ 应用开发者专区
1

每天约千万数据增量,是否有必要分表. 现有数据类似saas模式,每个表中有一个字段a, 不同a的数据归属到不同租户. 每天约1千万+新数据,这种情况是继续分表好点,同一张表tidb能处理得过来吗?

【应用框架及开发适配业务逻辑】
mybatis-plus
【TiDB 版本】 v8.5.3
硬件配置:
3台tidb-kv(4T ssd,16核,64G),3台pd(8核,48G) 3台tidb, 2台tiflash

2

和应用处理数据的逻辑有关系吧，如果分区后能让应用通过增加分区条件降低中间结果集，那分区有好处。如果不是，分区表也有很多问题，比如统计信息的收集。 TiDB 的分区表功能出发点是快速、简单删数

3

你的意思是按a字段的值进行分表？还是按时间分表？

4

按a字段

5

因为主键是auto_random, 分区的话,分区键必须必须包含主键吧? 单纯用a字段分没法分

6

这个量级tidb是处理不过来的，，能不能根据租户分区得看租户数

7

这种按照租户分表撒

8

用分区表替代物理分表是更优选择：既能让 TiDB 原生承载千万级日增量单表无压力，又能通过租户分区保障查询性能，同时降低运维和开发复杂度。若未来单租户数据量超 10 亿条，可考虑对该租户的分区再做子分区

9

既能利用 TiDB 分布式优势承载海量数据，又能满足 SaaS 租户隔离的性能需求

10

主键是auto_random, 用a字段分区, 分区键怎么做?

11
  • 可以观察目前应用压力，看看是否已经到达瓶颈
  • 若租户数据量差异大，用 Hash 分区；若需按时间归档，可结合 Range 分区（如按日期 + 租户）。
12

可以分表啊，就是业务逻辑要改了，不同的组合查询不同的表

13

数据量这么大，最好重新设计下业务逻辑吧，最好还是分

14

最好是分表把，数据量大

15

partition by key is good idea

1 个赞
16

同意，分区才是正确的打开方式吧，分表不是又回到老路子上去了吗？要不会入侵应用程序，要不需要分表中间件，提高了SQL编写的难度，且复杂SQL，如：多层子查询，多层连接等目前均无法实现分表查询呢

17

分区吧

18

分表对应用程序代码的影响有点大吧，估计要额外做不少判断逻辑。

19

分好一点