Neki 把 Postgres 分片藏进连接串，分片键却不能替你选

作者：林岚｜OC 开发者生态编辑

据 PlanetScale 的 Neki 发布说明，这项服务用路由器连接多个原生 Postgres 分片，并把扩容和维护操作纳入控制平面。Neki 目前是 platform preview；官方明确要求不要在这一阶段运行生产工作负载。

一句话结论：Neki 试图把分布式数据库的运维复杂度收进平台，但数据怎样分、查询怎样跨分片，仍是应用团队必须理解的核心问题。

一个连接串，背后可能已经不是一台机器

应用连接单机数据库时，一条查询通常在同一个实例里完成。分片之后，数据被放到不同节点，系统首先需要判断请求该去哪里，再把结果组合回来。

Neki 的路由器使用 Postgres 协议，分片本身也运行 Postgres。这个选择有助于保留现有驱动和生态，但“协议兼容”不意味着每种查询在分布式环境中的成本都与单机一致。

最简单的情况是查询带着明确的分片键，路由器可以直接找到目标。如果请求需要遍历所有分片，再排序、聚合或连接数据，网络和协调工作就会进入执行路径。

所以，连接串不变是一种接入便利，不是性能不变的保证。开发者越看不见底层分布，就越需要能解释查询到底访问了哪些节点的工具。

分片键实际上是在表达业务局部性

设想一个面向多家商户的系统。大多数请求只查看某一家商户的订单和客户，那么把同一商户的相关数据放在一起，就可能减少跨节点操作。

但如果核心需求变成跨商户的统一分析，原来合理的局部性便不再覆盖所有查询。数据库没有突然变差，只是分布方式与工作负载之间出现了矛盾。

还有热点问题：按商户分片，不代表每家商户大小相近。一家超大客户可能让某个分片远比其他分片忙。增加总节点数，也未必能自然消除这个热点。

因此，评估分片方案应从访问模式出发，而不是先选一个看起来均匀的字段。数据增长、热点迁移和跨租户操作，都需要放进长期模型里考虑。

运维自动化是真收益，但不是没有代价

官方介绍，Neki 把路由、分片与副本、连接池和控制平面组合起来，并以工作流处理重分片、结构变更和升级。

把这些操作标准化很有价值。应用团队通常不愿每次扩容都重新发明复制、切流和回退流程；一个成熟平台能把大量经验变成可重复执行的步骤。

但“在线操作”并不等于完全没有资源开销。复制数据、维护新旧状态、追赶写入和切换流量，都需要容量与可观察性。业务越忙，越需要提前安排冗余，避免在已经接近极限时才开始搬家。

对采购方来说，除了询问能不能在线扩容，还应该问扩容期间的性能边界、失败后如何恢复、哪些操作可以取消，以及临时资源怎样计费。

连接池解决的是另一个瓶颈

数据库压力不仅来自数据量，还来自连接数量和并发请求方式。大量短连接、长事务或空闲占用，都可能让资源分配失衡。

Neki 将连接管理放在路由与实例两端。这个设计值得关注，但不能因此跳过应用侧的检查：一个忘记结束的事务，或者无限制并发的后台任务，不会因为前面增加了池就失去破坏力。

平台可以更好地分配资源，应用仍应明确超时、事务范围和并发上限。把所有流量问题都当成“数据库不够大”，往往会让扩容变成昂贵的掩盖。

预览期最适合做什么

当前更合理的用途，是用脱敏数据和真实查询模式验证假设：哪些请求能单分片完成，哪些必须扇出；是否依赖某种扩展；迁移和故障演练能否被团队理解。

不要只用整齐的合成数据跑一个吞吐数字。实际系统中的偏斜、大客户和长尾查询，才会揭示分片后的取舍。

同时保留原有基线。只有同样的工作负载、同样的结果要求和可解释的资源条件，才能区分性能收益来自分片、机器规格变化，还是测试方式不同。

关键事实

• Neki 是 PlanetScale 的 Postgres 分片服务预览。
• 分片使用原生 Postgres，路由与控制平面承担分布式协调。
• 平台支持先以不分片方式使用，再按需调整。
• 官方不建议在预览期承载生产业务。

OC 判断

把复杂度交给平台是合理选择，但前提是平台让复杂度可观察，而不是让它不可见。Neki 的长期价值，将取决于它能否把分片的收益与代价都解释清楚，而不只是把接入步骤缩成一个连接串。

为什么重要

• 对开发者：数据局部性仍需要业务知识。
• 对企业：扩容能力应与运维、可恢复性和费用一起评估。
• 对用户：数据库迁移最终要保障持续可用，而非只改善测试成绩。

参考来源

• PlanetScale：Introducing Neki