明细模型有规律地按排序建批量DELETE

💬 StarRocks 用户问答 功能使用相关
#1

有个问题想请教一下，现在我们有一个场景，有一个记录业务指标的表，存量数据大约有1亿条，有排序键project_id，字符串类型的。大约有10000个projects，每个project有10000条数据。
现在需要在每天 通过DELETE from project_metrics where project_id = xxx + INSERT 方式更新 100个左右的项目，大约几百万条数据，目前使用的是明细模型，在starrocks文档里看到对明细模型的DELETE操作实际只是做了标记，并没有实际删除，有2个问题想问一下：

  1. 这种被标记删除的记录，会随着compaction自动清理掉吗？如果不能是不是就意味着该表的存储空间会不停增长？
  2. 按照排序键条件删除 where project_id = xxx ，性能如何？
#2

每天where project_id = xxx 几百万条记录。感觉您可以根据分区把数据truncate后，重新导入更好。

#3

感谢恢复，确实也考虑过按project_id分区，但是project_id的数量太多了，有几万个，测试发现如果分区数量超过几百个，查询性能下降的很厉害。

#4

分区过多的时候可以把buckets设置小一点，设置成BE节点数。

#5

几万个分区 可能性能会下降，就算按天分区 10年才3650个。

#6

嗯，是的，而且也不是每天把所有的project刷新一遍，每个project什么时候刷新数据是上游数据生产者决定的，如果每天刷新一次，还可以按天分区

#7

所以就想咨询一下，

  1. 明细模型里的DELETE数据是否会在 compaction的时候清理掉，这样不至于存储空间膨胀。
  2. 这种分批DELETE的模式，DELETE本身的性能怎样，project_id是排序建
#8

一个project_id大概有多少万数据？

#9

从几百到几十万不等，个别上百万，平均的话就是几万吧

#10

buckets设置为1 然后以project_id分区试一下

#11
  1. base compaction会将标记为delete的行进行删除合并。
    2.delete时，每批的数据量要几万起，不能一条条记录操作。
#12

按project_id分区好像不行，记得starrocks分区上限好像是4096

#13

感谢，这个是在哪里找到的，starrocks的文档里吗？

#14

4096是动态创建分区的限制吧。那个是我们看源代码学会的。

#15

厉害，我们现在的场景就是动态分区，project_id也是上游生成的，没有办法提前订好

#16

根据上游得到的project_id，写个程序通过add partition加分区就好叻

#17

谢谢，我们找时间测试一下

#18

好像delete操作是将数据预删除，有一个参数是配置保留时长，时间一过就会彻底删除。好像是trash_file_expire_time_sec

#19

收到，谢谢，我们把这个设小了试试。不过从配置名字看，好像是文件级别的，不知具体的机制是怎样的，是只有当整个文件包含的所有记录都被标记为删除时，才走这个逻辑，还是其他理解？

#21

这个你问一下starrocks的微信社区群，具体在核实一下。我们之前也有直接delete，频繁的删除大量数据就会导致磁盘膨胀。

京ICP备2022026421号-1