Neki

# 介绍 Neki — PlanetScale 来源：https://planetscale.com/blog/introducing-neki Neki 现已在平台预览版中提供。 Neki (https://neki.dev/) 基于我们八年来运营全球一些最大规模分片 MySQL 集群所积累的经验教训而构建。为众多公司处理着每秒数百万次查询的数千个生产负载，在这些公司里，即使是几秒钟的宕机也是广为人知的事件。我们深知驱动全球最关键的第 0 层负载意味着什么。 一年半前，当我们发布 PlanetScale Postgres 时，我们知道我们需要做得更多。在此期间，我们在 PlanetScale 上服务了数千家客户，其中一些客户的规模可与我们最大的 MySQL 客户相媲美。我们一次又一次地看到，团队在 Postgres 上遇到了单机性能的天花板。虽然更大的硬件能争取一些时间，但当客户达到单机性能的极限时，我们发现没有好的解决方案可以提供。于是，Neki 应运而生。 ## 什么是 Neki？(https://planetscale.com/blog/introducing-neki#what-is-neki) Neki 是来自 PlanetScale 的分片式 Postgres。它允许你在多台机器上扩展 Postgres 数据库，同时在每个分片上保留真正的 Postgres。 你的应用程序通过标准的 Postgres 线协议连接到 Neki 路由器，因此你现有的驱动程序、ORM 和连接字符串将继续正常工作。每个分片都是一个完整的 Postgres 集群，包含一个主节点和至少两个副本，分布在 3 个可用区。没有自定义存储引擎，因此扩展、SQL 支持和性能表现与原生 Postgres 一致。 你选择分片键，并通过 JSON 数据拓扑控制表的分组和分布方式。模式变更、版本升级、故障转移、数据导入和重新分片都作为内置的完全在线工作流运行。你还可以获得你已经依赖的 PlanetScale 功能，包括洞察分析、模式建议、分支和 MCP。 你不必在第一天就进行分片。可以先将 Neki 作为带有副本的单主节点运行，当一台机器无法满足需求时，重新分片只是针对现有集群执行的一个工作流。 ## 为什么选择 Neki？(https://planetscale.com/blog/introducing-neki#why-neki) 你已经了解快速增长的 Postgres 数据库带来的问题：表太大，无法在不影响流量的情况下进行 vacuum 或索引；备份耗时数小时；连接限制；模式变更的维护窗口；事务回卷等等。 你可以迁移到更大的实例，但最终会耗尽足够大的机器，而且随着核心数和 IOPS 的增加，问题并不会线性增长。 现有的解决方案都要求你做出某种牺牲。应用层分片将路由逻辑推入你的代码。Postgres “兼容”的分布式数据库对你隐藏分片键，移除你的扩展，并引入复杂性和延迟，使其难以处理和调试。 因此，我们基于几个原则构建了 Neki，其中最重要的原则是：坚持 Postgres，而不是绕过它、模拟它或偏离它。 ## Neki 如何工作？(https://planetscale.com/blog/introducing-neki#how-does-neki-work) 我们从第一性原理出发为 Postgres 架构了 Neki，在每个分片上运行真正的 Postgres。它由四个核心部分组成。 ### Neki 路由器 (https://planetscale.com/blog/introducing-neki#neki-routers) 你的应用程序首先连接到 Neki 路由器。路由器使用 Postgres 线协议通信，因此你现有的驱动程序和 ORM 可以通过单个连接字符串继续工作。路由器拥有完整的 Postgres 查询解析器、分布式查询规划器、查询缓冲等。它解析你的查询，构建一个计划以决定哪些分片应该运行该查询，发送任务，然后将结果合并回一个流。路由器可以垂直和水平扩展，因此不会有任何单个路由器成为瓶颈。 ### 分片与分片组 (https://planetscale.com/blog/introducing-neki#sharding-and-shard-groups) Neki 中的每个分片都是真正的 Postgres，包含 1 个主节点和至少 2 个副本，分布在可用区。没有修改过的存储引擎。扩展、SQL 支持和性能表现与原生 Postgres 一致，因为它*就是* Postgres。 分片被组织成分片组，因此不同的表或工作负载可以存储在不同的分片集上。每个分片使用一个配置文件，该文件定义其实例大小、副本数量、存储、Postgres 参数和扩展，因此你可以根据每个组的流量进行资源调配。 ### 连接池 (https://planetscale.com/blog/introducing-neki#connection-pooling) Sidecar 进程与每个 Postgres 实例并行运行。这是使 Neki 的连接处理比仅仅在数据库前放置 PgBouncer 有了实质性改进的关键部分。因为 Neki 控制着连接的两端——路由器端和 Postgres 端，它可以根据每个实例的实际服务能力来设定连接池大小，而不是从进程外部进行估算。 ### 控制平面 (https://planetscale.com/blog/introducing-neki#control-plane) 控制平面跟踪每个节点的健康状况，执行计划的切换和非计划的故障转移，并协调重新分片数据、应用模式变更和执行版本升级的工作流。 ### 数据拓扑 (https://planetscale.com/blog/introducing-neki#data-topology) 将所有这些联系在一起的是数据拓扑（https://planetscale.com/blog/what-is-a-data-topology），这是一个 JSON 配置，将你的逻辑表映射到物理分片上。你定义分片索引，指定 Neki 路由所依据的列以及该值如何被哈希；以及分片组，控制一组表分布在多少个分片上以及具体是哪些分片。路由器会缓存拓扑并在每次生成计划时查询它。 ## 分片之外你能获得什么 (https://planetscale.com/blog/introducing-neki#what-you-get-beyond-sharding) 通常需要安排维护窗口执行的所有操作，在 Neki 中都作为内置工作流运行。工作流会配置新的目标节点，通过复制同步数据，使用 `_neki` 元函数切换流量，并退役旧节点。所有这些都通过与应用程序相同的 `psql` 连接完成。 这种在线运维模式涵盖了模式变更、版本升级、计划内和计划外故障转移、数据导入和重新分片。 Neki 还包含你已经依赖的所有 PlanetScale 功能：洞察分析、模式建议、分支、MCP 等。 你也可以将 Neki 作为带有副本的单主节点非分片模式运行。在需要分片之前，你就能获得改进的连接池、在线 DDL、零停机升级和健康监控。当你需要分片时，重新分片只是针对现有集群执行的一个工作流。 ## 什么是平台预览版？(https://planetscale.com/blog/introducing-neki#what-is-a-platform-preview) 我们希望尽快将 Neki 交到您手中。在平台预览版期间，你不应在 Neki 上运行生产负载。产品仍在变动中，其中一些变动可能是破坏性的。 如果你在平台预览期间有任何反馈、问题或遇到任何问题，请告诉我们。提交支持工单（https://planetscale.com/contact）或加入我们的 Discord（https://pscale.link/community）。 ## 今日尝试 Neki (https://planetscale.com/blog/introducing-neki#try-neki-today) 登录 PlanetScale，选择加入平台预览版，并创建一个 Neki 集群。阅读 Neki 文档（https://planetscale.com/docs/neki）了解更多关于 Neki 架构、如何分片等信息。 如果你拥有一个大型 Postgres 集群并想了解 Neki 是否适合，请联系我们（https://planetscale.com/contact）。我们很乐意为你的团队进行私有演示，深入研究你的模式和查询模式，并提供关于如何分片的切实建议。