处理热点分片
内容提要
Neki 数据库分片按租户均匀分布时，大客户可能引发热点。借鉴 Slack 使用 Vitess 的经验，可先垂直扩容或隔离大租户，但根本方案是重新分片：分析查询模式，改用更合适的键（如频道而非工作区）分片，使关键查询在单分片完成。Neki 支持在线重分片，无需停机，建议优先解决当前最痛的表的分片问题。
延伸解读
从Slack案例看分片键选择
Slack最初按工作区ID分片消息表，但大工作区导致单分片过热。后来改为按频道ID分片，因为消息总是按频道查询，且频道ID已在主键中。这使关键查询在单分片完成，跨频道查询仅用于管理或批处理。Neki借鉴此经验，建议分析查询模式，选择使关键查询单分片完成的键。
垂直扩容与隔离大租户的局限
垂直扩容可为大租户分配独立配置，隔离则通过调整键范围将大租户数据集中到特定分片。但两者都只是临时缓解，不解决根本问题。隔离后，单个大租户可能产生超大表，存储和CPU压力依然存在。因此，这些方法适合争取时间，长期仍需重新分片。
在线重分片与声明式拓扑
Neki支持在线重分片，无需停机。重分片时，Reshard将现有行复制到新分片并流式处理写入，源分片继续服务，切换流量时应用无感知。数据拓扑是声明式配置，明确指定表的分片列和分片范围，避免自动分片的不确定性，便于人和代理理解数据位置。
优先解决当前最痛的表
重新分片不必一次性处理所有表。应调查应用访问模式和查询形状，找出常按共同列连接的表，将它们一起分片。除非规模极大，用户表通常无需分片。建议先分片当前最痛的表，避免等待完美方案导致多个表同时超出原分片键，增加变更复杂度。
Q&A
Neki 数据库分片出现热点分片的原因是什么？
当 Neki 按租户均匀分布分片时，如果某些大租户的数据量或访问量远高于其他租户，就会导致其所在分片负载过高，形成热点分片。
处理热点分片有哪些临时缓解方法？
可以垂直扩容，为热点分片分配独立资源配置；也可以隔离大租户，将其数据范围单独划分到特定分片。这两种方法能暂时缓解压力，但未解决根本问题。
Neki 如何实现在线重分片而不停机？
Neki 支持在线重分片：通过 Reshard 操作将现有行复制到新分片，同时流式传输正在进行的写入，源分片继续服务查询。切换流量时，Neki 将读写迁移到新位置，应用无需离线。
Slack 是如何解决消息表热点问题的？
Slack 最初按工作区 ID 分片消息表，导致大工作区热点。后来改用 Vitess，将消息表按频道 ID 分片，因为消息总是按频道查询，且频道 ID 已在主键中。这样频道及其消息的查询可在单分片完成，跨频道查询仅用于管理或批处理，从而冷却热点并释放 CPU 和存储资源。
Neki 的数据拓扑是什么？与自动分片有何不同？
Neki 的数据拓扑是一种声明式配置，明确定义了哪些表按哪些列分片以及每个分片接收的值范围。与自动分片由数据库决定数据放置不同，数据拓扑让代理和人类都能清晰推理数据写入和读取的位置，避免意外放置。
进行重分片时，应该优先处理哪些表？
应优先解决当前最痛的表的分片问题，即那些因分片键不当导致热点或性能瓶颈的表。不要等待完美方案，先对最需要重分片的表进行调整，其余表按需逐步处理。
