请问超大doris集群里，单个tablet体积有强限制吗？官方说要1-10g，感觉太小了。

关于3并发就开始compaction score上升的问题，破案了，原因是压测工具写入的数据，里面时间戳因为是预置的所以是乱序的。但是建表的时候，duplicate key里设置的又包含时间戳。

我改成压测数据的时间戳是按真实时间有序的就没这问题了，写入速度很快，而且compaction score在300以下。

deepseek分析
为什么“乱序”会拖垮性能？
存储引擎的“有序”执念：Doris 的存储层（LSM-Tree 架构）在设计上，非常依赖于数据按照 主键/排序键（即你建表时指定的 Duplicate Key）的顺序写入。当数据有序写入时，新数据会自然地追加到已有数据的末尾，Compaction 合并时也只需做顺序的归并，开销很小。

乱序写入的“蝴蝶效应”：当你用乱序的时间戳写入时，每一批数据都可能落在整个数据集的任意位置（比如新数据的时间比历史数据还早）。这会导致：

写入变为随机 I/O：Doris 为了把一条“旧”数据插入到正确的位置，需要进行大量的随机磁盘读写来定位和修正索引。

Compaction 成为“噩梦”：后台 Compaction 需要合并这些散落在各处的数据版本，原本高效的顺序归并变成了复杂的交叉合并，需要扫描和处理的数据范围急剧扩大，CPU 和 I/O 开销成倍增加。这直接导致了你观察到的 Compaction Score 飙升至 4000 以上。

有序写入的“康庄大道”：当你把时间戳改为真实时间（即有序递增）后，写入就变成了纯粹的追加（Append）操作。数据顺序写入，Compaction 轻量高效，资源消耗自然就降下来了。

💡 关键启示与后续建议
这个案例给你带来的核心启示是：

时间戳等递增字段，非常适合作为排序键的第一列。它能最大程度地保证数据写入的有序性，是 Doris 高性能写入的基石。

如果你的业务数据天然就是乱序的（比如回填历史数据），可以考虑使用 UNIQUE KEY 模型，并结合 REPLACE 或 AGGREGATE 等机制来处理，但这通常会伴随额外的性能开销。

对于 DUPLICATE KEY 模型，为了保证写入性能，排序键的第一列最好是一个能保证单调递增的字段，比如数据产生的时间、自增 ID 等。

很高兴你这么快就定位到了根因。这个经验非常宝贵，它说明在设计 Doris 表结构时，排序键的选择和数据的实际写入顺序，是决定性能的关键因素，其重要性甚至超过了单纯调整并发度或缓冲区大小。

这个项目是真实已经上线的项目，150TB 是压缩前的数据量，实际上到Doris中进一步压缩后没有这么大，大概能有4倍的压缩比。

单节点的写入量和你的配置相关。你可以关注下这个榜单的数据，都是标准的测试数据集，sf1000 是1TB的数据量。