Shard（分片）
为帮助您更好地规划表结构并优化性能，本文档详细介绍了 TcaplusDB 的 Shard（分片）分配核心规则与建议。
1. Shard 基本概念与限制
TcaplusDB 采用分片机制实现数据的分布式存储与访问。其核心机制是将每张表的数据划分为多个Shard，这些 Shard 分散在不同的存储节点（tcapsvr）上。数据的分布依据是通过对表的splittablekey（未指定时默认为主键）进行 Hash 计算，然后对 10000 取模（即 hash(splittablekey) % 10000）来确定其所属的 ShardID。每个表最多可划分为 10000 个分片（Shard）。
2. Shard 容量规划建议
合理的 Shard 容量规划是保障性能与稳定性的关键。
- 物理上限：单个 Shard 的数据量最大支持 256GB。超过会写入失败。
- 运营建议：为避免单 Shard 过大可能带来的性能与运维复杂度问题，建议在日常运营中，单个 Shard 的数据量维持在 30GB 以内。更小的 Shard 通常能获得更优的访问性能。同时，业务可以根据访问时延现况（一般地，1KB请求的平均访问时延在10ms内），来判断对应表Shard个数是否需要提升。
- 预分配内存：正式环境，每个 Shard 会默认预分配 1GB的内存空间用于缓存热数据。当数据量超过此阈值时，超出部分将存储在磁盘中。
3. Shard 数量规划原则
因每组存储资源的Shard个数有限， 因此一个表的 Shard 总数需综合数据总量和访问量、成本等因素来计算一个相对合理的值。
- 单表最小Shard数：1个。即每个表至少一个Shard， 通常加表时默认分配的也是1个Shard。
- 计算公式参考：您可以根据预期的总数据量和建议的单 Shard 容量（如 30GB）来估算所需的 Shard 数量。例如，预计总数据量为 3TB 的表，理论上需要 (3 * 1024) / 30 ≈ 103个 Shard。
- 访问性能考量：单个 Shard 能够支撑的 QPS 在万级别（具体数值会受记录大小、请求类型等因素影响）。对于预期访问量非常大的表，建议设置更多的 Shard，从而提升整体吞吐能力。
- 内存关联性：Shard 数量也与内存规划紧密相关。一个常见的服务器配置基准是：为一台拥有 128GB 物理内存的存储节点机器，默认分配约 112 个 Shard。这确保了每个 Shard 能有约 1GB 的预分配内存空间。
4. 总结与建议
| 评估维度 | 限制与建议 | 说明 |
|---|---|---|
| 单表最大 Shard 数 | 10000 个 | 表分片的上限 |
| 单 Shard 容量上限 | 256GB | 物理硬限制 |
| 单 Shard 运营建议容量 | ≤ 30GB | 为保障性能与易运维，推荐使用此标准；但对于访问量不大的表，一般超过30GB也没有问题。 |
| 单 Shard 预分配内存 | 1GB | 超出部分存于磁盘 |
| Shard 数据决定因素 | 数据总量 & 访问量(QPS） | 数据量定基础，访问量定分布。高QPS表建议更多Shard，更小单Shard尺寸 |
| 单 Shard 处理能力 | 约万级 QPS | 具体性能因记录大小和请求类型而异 |
| 内存配置参考 | 128GB 内存机器 ≈ 112 个 Shard | 确保每个Shard有约1GB内存 |
总而言之，Shard 分配需要在数据量、性能、成本之间取得平衡。通常建议您优先根据期望的单 Shard 数据量（如 30GB）来初步确定 Shard 总数，然后再评估该数量下的 Shard 是否能满足您的访问性能（QPS）要求， 同时满足Shard数不超过您购买的总量。 在不超过Shard总量的前提下，建议对业务的核心高频访问表分配更多的Shard数。
注意：以上给出的数值为通用参考，实际部署时可能会因具体配置和业务场景有所不同。