Neki 进入平台预览：PlanetScale 开始探索分片 Postgres

预计阅读时间：7 分钟

PlanetScale 宣布 Neki 进入平台预览。它被定义为一项分片 Postgres 服务，意味着团队希望把水平扩展能力带进开发者熟悉的 PostgreSQL 生态。现阶段公开信息仍然有限，因此比功能清单更值得关注的是：应用应该如何为分片建模，以及平台预览阶段适合验证什么。

分片改变的不只是数据库部署方式

单机或主从架构中的 PostgreSQL 通常允许应用把数据库视为一个整体。引入分片后，数据会按照某种规则分布到不同节点，分片键也就进入了应用的数据模型。

以多租户 SaaS 为例，tenant_id 往往是一个自然的候选键。同一租户的数据如果能够稳定落在同一分片，大量查询便可以在局部完成；反过来，缺少租户条件的全局查询可能需要跨分片聚合，成本和复杂度都会上升。

这会影响几个日常决策：

主键是否只需在单个分片内唯一，还是必须全局唯一；
唯一约束能否包含分片键；
事务是否会跨越多个租户或分片；
报表、搜索和后台任务是否依赖全局扫描；
数据增长后能否调整分片分布，以及调整期间应用会看到什么行为。

这些问题不代表 Neki 已经公开承诺了某种具体实现，而是评估任何分片 Postgres 平台时都需要验证的工程边界。

用贴近分片的方式设计表和查询

在没有更多 Neki 接口细节的情况下，可以先用标准 PostgreSQL SQL 检查现有模型是否适合按租户路由。下面的示例可直接交给 psql 执行：

CREATE TABLE tenants (
    id uuid PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE projects (
    tenant_id uuid NOT NULL REFERENCES tenants(id),
    id uuid NOT NULL,
    name text NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (tenant_id, id),
    UNIQUE (tenant_id, name)
);

CREATE INDEX projects_tenant_created_idx
    ON projects (tenant_id, created_at DESC);

INSERT INTO tenants (id, name)
VALUES ('11111111-1111-1111-1111-111111111111', 'Acme');

INSERT INTO projects (tenant_id, id, name)
VALUES (
    '11111111-1111-1111-1111-111111111111',
    '22222222-2222-2222-2222-222222222222',
    'billing-api'
);

SELECT id, name, created_at
FROM projects
WHERE tenant_id = '11111111-1111-1111-1111-111111111111'
ORDER BY created_at DESC
LIMIT 20;

这里把 tenant_id 放进项目表的主键、唯一约束和常用索引。这样做的目的，是让数据归属和查询路由保持显式。实际接入 Neki 时，应根据平台公开的分片键、约束和路由规则修改这个模型，不能假定示例中的复合主键会自动触发平台分片。

应用连接层也应保持可替换。下面是一个可以改造的 Python 连通性测试，假设平台提供 PostgreSQL 兼容连接串；连接参数名称和 TLS 要求需要以预览环境实际配置为准。

python -m venv .venv
. .venv/bin/activate
pip install 'psycopg[binary]'
export DATABASE_URL='postgresql://USER:PASSWORD@HOST:5432/DBNAME?sslmode=require'
python check_db.py

# check_db.py
import os
import psycopg

url = os.environ["DATABASE_URL"]

with psycopg.connect(url, connect_timeout=10) as conn:
    with conn.cursor() as cur:
        cur.execute("SELECT current_database(), version()")
        database, version = cur.fetchone()
        print({"database": database, "version": version})

不要把预览环境的凭据写入源码或提交到仓库。生产应用还应配置连接池、超时、重试和可观测性，并确认它们与平台提供的连接方式兼容。

平台预览阶段应该测什么

预览阶段更适合做有边界的验证，而不是立即承载关键生产流量。测试数据应尽量模拟真实租户分布，因为平均负载很容易掩盖热点租户。

建议记录以下指标：

带分片键的点查询和分页查询延迟；
不带分片键的查询是否被允许，以及执行代价；
单分片事务与潜在跨分片事务的语义；
高并发连接、连接池和故障恢复行为；
大租户造成的数据倾斜及热点；
备份、恢复、迁移和数据导出路径；
PostgreSQL 扩展、驱动、ORM 与迁移工具的兼容范围。

测试时还要区分“PostgreSQL 协议兼容”和“所有 PostgreSQL 行为都完全一致”。分片系统通常会在事务、约束、扩展或运维能力上形成自己的边界，具体结果应以 Neki 预览版的文档和实测为准。

采用前的判断清单

Neki 的平台预览释放了一个清晰信号：PlanetScale 正在把自身的平台经验扩展到分片 PostgreSQL。但仅凭预览公告，还不足以推断正式版的功能、价格、服务等级或发布时间。

团队可以先挑选一个数据边界清楚、可回放、可回退的非关键工作负载，建立延迟、吞吐量、故障恢复和运维复杂度基线。只有当分片键稳定、核心查询能够局部执行、跨分片需求得到控制，并且备份与退出路径经过演练后，才适合考虑扩大使用范围。

Neki 进入平台预览：PlanetScale 开始探索分片 Postgres

分片改变的不只是数据库部署方式

用贴近分片的方式设计表和查询

平台预览阶段应该测什么

采用前的判断清单

相关推荐

建议反馈