PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗

本文为「数据库全方位对比系列」第三篇,该系列的前两部作品为:

  • 全方位对比 Postgres 和 MySQL
  • 全方位对比 Postgres 和 MongoDB

根据 2023 年 Stack Overflow 调研,Postgres 已经取代 MySQL 成为最受欢迎和渴望的数据库了。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第1张图片

看起来 MySQL 和 Postgres 的爱恨交织还将继续。从原生的 MySQL vs. Postgres,到分布式的 TiDB vs. CockroachDB,再到云原生的 AWS Aurora vs. GCP AlloyDB,现在进入了下一章节:面向开发者的 serverless 数据库 PlanetScale vs. Neon。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第2张图片 PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第3张图片

Bytebase 一直与 MySQL / Postgres 及其生态合作密切。业界最大的 MySQL & Postgres 托管服务之一 Google Cloud SQL 也是 Bytebase 创始团队的杰作之一。

我们就以下几个维度对 PlanetScale 和 Neon 进行了对比:

  • 架构 Architecture
  • 兼容性 Compatibility
  • 开发者工作流 Developer Workflow
  • 可靠性 Reliability
  • 伸缩性 Scalability
  • 可运维性 Operability
  • 集成 Integration
  • 合规 Compliance
  • 开源 Open Source
  • 定价 Pricing
  • 融资情况 Funding

架构 Architecture

PlanetScale 是基于 Vitess 的分布式数据库。Vitess 采用 shared-nothing 架构,每个分片 (shard) 包含一个 MySQL 主节点和几个副本。VTGate 代理将应用程序请求转发到相应的分片。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第4张图片

Neon 采用 shared-storage 架构,分离了计算和存储,计算部分只是普通的 Postgres 服务器,而存储部分则是一个定制的多租户存储系统,由所有 Postgres 计算节点共享。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第5张图片

兼容性 Compatibility

PlanetScale 的 MySQL 兼容性受到了限制。

  • 底层 Vitess 的限制。Vitess 的 shared-nothing 架构本身就有兼容性限制。需要维护会话或跨分片操作的功能很难实现。
  • 产品权衡。比如为了支持在线 DDL,PlanetScale 完全禁止外键,这比 Vitess 对外键的限制更严格。
  • 云服务模式。没有超级权限或 LOAD DATA INFILE 这样可以访问 host 文件系统。

Neon 与原生 Postgres 基本兼容。 Neon 则实现了新的 Page 层,除此之外只是轻微修改了 Postgres 本身的代码。Neon 的兼容性仅受云服务模式的限制,类似于其他云托管数据库服务(没有超级用户或访问 host 文件系统)。

开发者工作流 Developer Workflow

PlanetScale 和 Neon 都是面向开发者的,但它们在介绍开发者工作流时选择了不同的侧重点。 PlanetScale 强调了从分支,迁移 schema,监控到回滚等端到端的体验。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第6张图片

Neon 则仅仅突出了一个功能,分支(branching)。他们专为此构建了 Copy on Write(CoW)的 Page 层,使得同时包含 schema 和数据的分支可以被瞬间创建出来,而且几乎没有任何成本。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第7张图片

可靠性 Reliability

Shared-nothing 架构天生具有容错性,因为数据被分片和复制了。Vitess 已经是经过许多全球知名企业验证的技术,PlanetScale 这些年来也证明了其可靠性,没有出现过大故障。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第8张图片

Shared-storage 架构需要更强的技术来使逻辑上看是单点(SPOF)的存储组件具备故障容错能力。Neon 有文章详细描述其中的技术决策 。

作为一种开创性的数据库架构,Neon 的优势在于它建立在坚实的基础之上。PostgreSQL 本身非常稳定且支持完善的事务。Neon 的 Pageserver 也与 PostgreSQL 基于 WAL 的日志完美契合。此外,Neon 能够选择更现代的系统编程语言 Rust,这对于实现其存储层时来说非常合适。

伸缩性 Scalability

PlanetScale,顾名思义,能做到星球级 (Planet) - 伸缩 (Scale)。其 shared-nothing 架构使得其伸缩性接近线性增长 (scale-out),底层的 Vitess 最初在 YouTube 内部开发,就是用于应对伸缩性的挑战,并且已经在其他大型互联网公司获得了验证:

  • Slack
  • 京东

相比之下,Neon 不像 PlanetScale 那样具备如此高的伸缩性,毕竟,它只是一个单节点的 Postgres 实例。但这个单节点也可以很好地进行纵向伸缩 (scale-up)。Neon 将存储和计算分离开来,因此两个部分可以分别独立进行伸缩。而且在云环境中,存储是无限的,计算资源也非常充足,因此可伸缩性往往仅受网络带宽限制。这种分离式架构还带来了弹性能力,在需要时可以轻松实现 scale-to-zero 的缩减或者从小到大的扩冲。

可运维性 Operability

PlanetScale 提供的是一套完整的托管数据库服务,它的定位是管理使用数据库的每个方面。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第9张图片

  • Deploy requests and Branches - 用于数据库变更工作流
  • Insights - 监控
  • Boost - 提升查询性能
  • Revert - 回滚
  • Console - 在浏览器中提供类似 mysql CLI 的使用体验
  • Backup - 灾备

虽然有这么多功能,PlanetScale 仍然能打磨好每一个。例如,Boost 就展示了 PlanetScale 将学术论文转化为优秀产品的实力。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第10张图片

Neon 相对较新,提供了基本的功能。

  • 通过分支功能来实现灾备。
  • 可视化的 SQL 编辑器与数据库进行交互。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第11张图片

SQL 编辑器很好用:Neon 嵌入了外部的 explain.dalibo.com 来展示查询计划。虽然界面看起来有点奇怪,但确实能解决问题。

集成 Integration

PlanetScale 本身已经是个很全面的数据库平台了,它的文档站还列了一系列集成:

  • 支持主要的语言应用程序框架。
  • 使用 Datadog 监控。
  • 通过 Airbyte, Stitch 和 Hightouch 进行数据传输。

Neon 尚未积累很多标配的数据库集成,但 Neon 独特的功能解锁了新的集成可能:

  • Snaplet 使用 Neon 来瞬间提供生产数据库快照以供测试环境使用。
  • Replit 使用 Neon 的 scale-to-zero 为用户提供低成本的数据库服务。
  • Vercel + Neon 的 branching,可以在几分钟内(而不是几小时)提供部署预览。

合规 Compliance

PlanetScale 拥有 SOC 2 Type 2 和 HIPAA 认证。 Neon 目前已完成 SOC 2 Type 1 。

开源 Open Source

PlanetScale 和 Neon 采用了一致的策略,他们的代码库都采用了相同的自由开源许可证,并只对云服务收费。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第12张图片

PlanetScale 基于 forked 的 Vitess 分支,用的是 Apache-2.0 证书。PlanetScale 的团队还曾经打造过 gh-ost,是 MySQL 最好的在线 Schema 迁移 (Online DDL) 工具(可能也是所有开源关系型数据库管理系统中最好的)。他们还开源了 beam,一个展示 PlanetScale 功能的留言板网页应用。

Neon 的整个代码库也是采用了 Apache-2.0 许可证。

定价 Pricing

PlanetScale 根据用量计费 (usage-based),基于读写行数。这在数据库服务中还是不太常见的,当时也引起了争议。一方面,它鼓励用户优化查询;另一方面,糟糕的查询是很难避免的,尤其是 MySQL 查询优化器本身也存在缺陷。为了消除争议,PlanetScale 最近推出了一个新的 Scaler Pro 套餐,提供无限制的行读写操作。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第13张图片

Neon 也是用量计费 (usage-based),根据的是 4 个指标:活跃计算时间、数据存储、数据传输和数据写入。这种定价模型更加传统和可预测。Neon 还提供一个定价计算器来估算成本。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第14张图片

融资 Funding

两家公司都由行业老兵带领,且资金充裕:PlanetScale 迄今已筹集了 $1.05 亿美元,而 Neon 则获融到了 $1.03 亿(包括近期刚宣布的 B 轮融资 $4600 万)。

PlanetScale 还是 Neon?

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第15张图片

总体而言,PlanetScale 为每个数据库任务提供了一致的体验。最初,它只是一个面向超大规模用户的兼容 MySQL 的 Vitess 托管服务。自从转向开发者市场以来,PlanetScale 已经转变成一个先进的 serverless 数据库平台,只是恰好是支持了 MySQL 方言。

Neon 面世的晚一些,并且与新的 PlanetScale 有非常相似的价值主张。与 PlanetScale 不同的是,Neon 从第一天起就明确知道自己的目标受众,并有意地去构建迎合他们的技术:

  • 类似 Git 的分支管理,特别是可以立马创建出包括 schema 和数据的分支。
  • 具备自动缩放的 serverless 数据库。
  • 迎合 Postgres 的崛起,提供几乎完美的 Postgres 兼容性。

PlanetScale 和 Neon 之上

现在,在为下个项目选数据库时,首要考虑的已经不再是 Postgres vs. MySQL。相反,是考虑选择关系型数据库管理系统 (RDBMS) 还是其他类型的数据库。尽管 RDBMS 在数据库市场上仍占据主导地位,但讽刺的是,在云时代,这个领域并没有像其他数据库领域一样取得很大进展。用户确实有很多选择,但没有哪个能与 NoSQL 领域的 MongoDB Altas 或 OLAP 里的 Snowflake 媲美。

PlanetScale 和 Neon 彼此相似,而它们也与 MongoDB / Snowflake 相似:

  • 类似 MongoDB,PlanetScale 采用了 shared-nothing 架构、提供完整的数据库平台、面向开发人员,并能够讲述出色的产品故事。
  • 类似 Snowflake,Neon 将新颖的 shared-storage 引入到体系僵化的 OLTP 领域,使用 Postgres 方言,也同样重视开发者体验。

PlanetScale 和 Neon 都有可能成为现代关系型数据库即服务 (Modern RDBMS DBaaS) 中的下一个 MongoDB / Snowflake。我们都已经等了太久了。

不过, 如果你还是喜欢用原生的 MySQL 和 Postgres,并想要用 PlanetScale 的数据库变更工作流或 Neon 的可视化 SQL 编辑器,可以来试用一下 Bytebase。Bytebase 是个支持所有主流数据库的数据库工具,一站式覆盖数据库的变更、查询、安全和治理,提供了更多可定制的变更工作流,以及集成了数据访问控制和脱敏的可视化 SQL 编辑器。

PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗_第16张图片


你可以访问官网,免费注册云账号,立即体验 Bytebase。

你可能感兴趣的:(数据库,运维,DBA,开发者,数据库管理,DevOps)