mcpField
D
db-partitioning-sharding

db-partitioning-sharding

github.com/hainrixz数据与数据库2169 次安装3 天前更新
代码仓库

关于 db-partitioning-sharding

db-partitioning-sharding 是用于评估数据库分区与分片设计的审计技能，面向数据库架构审查。它检查分区需求、热点与倾斜，以及缺乏规模依据的过早分片，并要求用运行时数据验证规模判断。

主要功能

  1. 01识别适合分区的大型表
  2. 02检查分区键热点与倾斜
  3. 03发现缺乏依据的过早分片
  4. 04使用目录查询验证表大小
  5. 05按性能维度输出审计发现

适用场景

  1. 01审查日志或事件表的分区方案
  2. 02检查分区键是否造成写入集中
  3. 03评估现有分片是否有规模依据
  4. 04用 PostgreSQL 查询验证候选表

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/hainrixz/claude-db --skill db-partitioning-sharding

安装后在 Claude Code 中输入/db-partitioning-sharding确认已加载。

详细介绍

db-partitioning-sharding (M16)

扩展拓扑属于性能与规模（轴 performance）；关联关系型 Escala w12（与 M17/M2/M9 共用），以及 NoSQL 配置文件中的 Shard-key / Partición&hot 类别。两个失误方向是对称的：扩展太迟（本应分区的巨型表）和扩展太早（5 GB 的数据库单节点即可轻松处理，却进行了分片）。

检查内容

  1. 分区适用性 — 大型仅追加型 / 时序表（事件、日志、指标），这类表可通过 Postgres 声明式范围 / 列表分区受益（低成本裁剪、快速删除保留期数据），但目前仍是单个堆表。
  2. 热分区 / 键倾斜 — 分区键或分片键的基数较低，或存在时间倾斜（例如按 tenant_id 分区，但某个租户占了 90% 的流量，或所有写入都命中“今天”的分区）。在宽列存储中，事件表上的无界 / 热分区属于 severity:5（性能），但必须有实时写入速率证据；否则为 directional。
  3. 过早分片 — 引入应用层分片 / 多个分片，却没有规模或吞吐量方面的依据，徒增跨分片查询和重新均衡成本，毫无收益。

评分 / 轴

仅影响 performance（关系型 Escala w12；Shard-key 文档型 / Partición&hot KV+WC / Escala 向量型+图数据库）。

Tier-0（静态）

检测分区 DDL（PARTITION BY、分区子表）、选用的分区 / 分片键及其表观基数、根据命名 / 列识别的大表候选（时间戳 + 高写入意图），以及分片扇出代码。表的大小、行数和每个分区的写入速率属于运行时数据 → Tier-0 时标记为 needs_api（绝不静默通过）。

Tier-1/2（验证查询，Postgres）

-- partition inventory + sizes (Tier-1):
SELECT inhparent::regclass AS parent, inhrelid::regclass AS partition,
       pg_size_pretty(pg_total_relation_size(inhrelid)) AS sz
FROM pg_inherits ORDER BY pg_total_relation_size(inhrelid) DESC;
-- candidate (unpartitioned) large tables:
SELECT relname, pg_size_pretty(pg_total_relation_size(oid)) AS sz, reltuples::bigint AS est_rows
FROM pg_class WHERE relkind='r' ORDER BY pg_total_relation_size(oid) DESC LIMIT 20;

方法 schema_introspect / query_stat。大型未分区表可确认分区适用性问题，标记为 established；分区倾斜需要 Tier-2 写入统计数据——缺少这些数据时，热分区问题为 directional，且绝不构成上限。

发现项

按 schema/finding.schema.json 输出发现项。示例：

  • M16.events.unpartitioned_large_table — 大型仅追加型表仍是单个堆表（severity:3、warn、轴 performance，置信度：Tier-1 为 established / Tier-0 为 needs_api，fixable: advisory）。
  • M16.metrics.hot_partition_today — 所有写入都命中当前分区 / 键倾斜（静态时为 severity:3、warn、directional / Tier-2 时为 established；宽列存储事件表仅在有实时写入速率数据时才为 severity:5，fixable: advisory）。
  • M16.app.premature_sharding — 分片没有规模 / 吞吐量方面的依据（severity:2、warn、directional、fixable: advisory）。

每个发现项：evidence.observed 原样引用 DDL / 分片代码 / 目录行；verification.reproduce 为上述引用 $DATABASE_URL 的查询；expected_impact 必须注明影响区间和置信度（不得只给出百分比）。

诚信原则

  • 分区确实会带来开销（规划时间、跨分区约束）——只有表确实很大，或确实需要保留期管理 / 裁剪时才建议分区，绝不能将其视为默认方案。
  • 绝不编造行数或表大小来支持（或反驳）分区建议——规模判断需要 Tier-1 数据；缺少时，输出 needs_api。
  • 热分区的 sev-5 需要实时写入速率证据；基于静态键基数的猜测只能标记为 directional，且不能构成上限。
  • 这些都属于架构变更 → 标记为 advisory（具体的声明式分区迁移方案可标记为 proposed），绝不能标记为 auto。

评论

支持 Markdown