为帮助您更好地规划表结构并优化性能，本文档详细介绍了 TcaplusDB 的 Shard（分片）分配核心规则与建议。
Shard 基本概念与限制
TcaplusDB 采用分片机制实现数据的分布式存储与访问。其核心机制是将每张表的数据划分为多个 Shard，这些 Shard 分散在不同的存储节点（tcapsvr）上。数据的分布依据是通过对表的 splittablekey（未指定时默认为主键）进行 Hash 计算，然后对10000取模（即 hash(splittablekey) % 10000）来确定其所属的 ShardID。每个表最多可划分为10000个分片（Shard）。
Shard 容量规划建议
合理的 Shard 容量规划是保障性能与稳定性的关键。
物理上限：单个 Shard 的数据量最大支持256GB。超过会写入失败。
运营建议：为避免单 Shard 过大可能带来的性能与运维复杂度问题，建议在日常运营中，单个 Shard 的数据量维持在30GB以内。更小的 Shard 通常能获得更优的访问性能。同时，业务可以根据访问时延现况（一般地，1KB请求的平均访问时延在10ms内），来判断对应表 Shard 个数是否需要提升。
预分配内存：正式环境，每个 Shard 会默认预分配1GB的内存空间用于缓存热数据。当数据量超过此阈值时，超出部分将存储在磁盘中。
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的预分配内存空间。
总结与建议
|
单表最大 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 数。