SQL数据库自启动以来一直在为Web提供动力。即使在今天，严格的模式，酸性交易和强大的完整性的结合也使其成为许多应用程序的最佳存储选择。尽管听起来不可思议和沉闷，但在过去的几年中，数据库系统一直是一个非常活跃的领域。许多人才致力于这一人，开源项目是一个接一个地创建的，公司一直在努力建立有利可图的企业，而VC一直在押注那些看起来像下一任独角兽的人。

在繁荣的表面下，新一代现代SQL数据库正在翻新这项50年历史的技术，并逐渐重塑了我们如何使用它来构建Web应用程序 - 我们如何处理它，我们如何管理它以及我们如何反对它。这一系列文章试图从多个方面探索这个主题，包括：

• 无服务器和边缘
• 可编程性
• 与开发流的集成
• AI功能

今天让我们谈谈“无服务器”和“ Edge-Ready”。

---

“无服务器”是一个广义的术语，在不同的情况下可能意味着许多不同的事情。通常意味着系统管理自己（不需要低级操作），并根据需求自动将资源自动扩展。更具体地说，对于数据库，您无需担心版本升级，安全补丁，备份和还原，监视，故障转移等。系统具有弹性，并且似乎具有弹性量的计算功率和存储容量。

除了操作的简单性外，无服务器数据库的成本模型也有所不同。由于不再“服务器”，因此您最终要为“逻辑”使用而不是物理硬件付费。当心，这并不一定意味着总成本的降低。

无服务器数据库不是新事物。 AWS早在2017年就启动了Aurora，从那时起，云本地数据库服务使开发人员可以通过API提供，配置和扩展其数据库，而无需关心基础基础架构详细信息。但是，像PlanetScale和Neon这样的新挑战者正在将“无服务器 - 性”推向新的水平，并且某些改进使它们更自然地适合“移动到边缘”建筑趋势。

让我们看看如何。

连接池

使用SQL数据库的顶级头痛之一是达到其连接限制。连接是重型加权数据库构造 - 每种连接都具有为会话，交易等分配记忆预订的非平凡成本。传统上，开发人员有两种选择来处理它。一种是在应用程序端（使用应用程序代码或框架的帮助）进行连接池。它需要仔细规划池尺寸，并且在处理请求（通常是由于长期归功于交易）时，应用程序代码还需要避免在很长一段时间内保持连接，因为这可能会导致池精疲力尽。另一个选择是使用pgbouncer之类的工具将代理在数据库的前面，该数据库内部管理连接池。缺点也很明显 - 您还有另外一项服务可以运行。

在传统的应用程序托管环境中，连接池管理问题并不那么糟糕，该环境具有长期运行的node.js流程为客户端请求服务。但是，它在边缘环境中可能会变得越来越高，因为对于每个传入的请求，都会产生一个新的运行时为其服务，从而创建一个新的数据库连接。这种高频搅动会很快降低数据库的性能。

新一代数据库正在烘烤连接汇集到他们的系统中，因此您不再担心它了。 Planetscale得益于基本Vitess的支持，自豪地宣布，他们在现实世界中测试了一百万个并发联系。

霓虹灯是最新的Postgres Hoster，具有内置的PGBOUNCER服务，您可以简单地使用“泳池”连接字符串来利用它。

优势就绪驱动程序

关于从边缘支撑连接，具有连接池的连接仅解决了一半问题。另一半没有老练 - 许多边缘环境不支持建立任意TCP出站连接；仅允许HTTP（S）和Websocket。大多数SQL数据库都使用基于自定义的TCP网络协议。这意味着您根本无法从边缘连接到它们。您可能可以使用HTTP的TCP代理来隧道隧道或像PostGrest这样的API包装服务以使其（部分）起作用，但它们要么脆弱，要么会导致不必要的性能成本。

情况一直在快速变化。 Planetscale几个月前宣布了其“ Fetch API兼容”数据库驱动程序，使其完全可以从Vercel Edge运行时和Cloudflare工人中使用。霓虹灯也是released an edge-ready driver到2022年底，允许您查询http fetch（最适合单次查询）或websocket（适用于会话和交易）。

在单独的频谱中，Prisma-最受欢迎的Node.js Orm，也向几天前的所有人（仍处于预览阶段）开放了其“加速”服务（以前称为数据代理）。在其所有功能中，其主要产品之一是在传统数据库面前充当托管代理，并通过提供内置连接池并公开基于HTTP的端点来使其“ Edge Ready”。您需要做出的唯一更改是使用新的连接字符串，整个代码库保持不变。

分离计算和存储

无服务器SQL数据库世界中的另一个迷人进度是计算和存储的分离。是的，我在这里明确谈论霓虹灯，因为它是第一个先驱这个概念的人，并且做得很好。

您可能会争辩说这不是新事物。使用AWS RDS，如果您将EBS用作存储空间，则您的计算和存储已经“分开”。但是，重要的是要提到RDS场景是“物理分离”。霓虹灯所做的是“逻辑分离” - 计算和存储在体系结构上是不同的组件，这使许多有趣的新功能。

这种建筑选择的明显好处：

• 独立缩放

  计算可以独立地上下缩放，甚至可以零。对于具有不同特征的工作负载，您可以分配专用的计算端点并独立扩展它们，而它们在不在，它们共享相同的统一存储。

• 轻松的分支

  霓虹灯的存储系统使用非关闭格式，这意味着将写入以三角洲为单位，并且可以将历史数据保存在需要的时间内。为您的数据库创建“分支”（出于同样的原因，GIT中的分支很便宜）并将单独的计算端点分配给它们，这使得非常便宜。这有什么用？对于每个功能分支，您可以将数据库以及用于开发和测试的源代码组成。那不是很酷吗？

这是对“无服务器”数据库的完整重新思考的一个很好的例子！

存储在边缘

“移动到边缘”的一个很大的困境是，尽管计算与用户接近，但需要获取的数据仍然存在于数据中心。缓慢的提取过程很大程度上可以取消性能增长，有时会导致负面的净改善。这全是因为数据未存储在边缘。还是可以？

Turso是一种有趣的新数据库服务，它将SQLITE包装到直接在边缘上分布在存储和计算的云数据库中。 SQLite的占地面积非常低，是在边缘节点的商品硬件上运行的理想选择。这个想法是将整个数据库从中央主要位置复制到选定的边缘区域（由Fly.io托管）。它为最终用户提供了最佳的性能，因为计算和存储与用户接近共存。

当然，利益并非没有缺点。 TURSO本质上是一个全球分布的单写的多阅读数据库。所有写入必须将其写入中央主要实例并复制到边缘节点。在复制完成之前，读者可以看到不一致的结果。鉴于复制需要经历很长的距离和许多网络啤酒花，因此完成的时间可能是漫长而波动的。但是，并非每个应用程序都需要立即一致性，而Turso可能是某些人的绝佳选择。

包起来

我希望您能像我一样发现这些无服务器和边缘准备就绪的数据库的进步。他们使开发人员更多地专注于构建应用程序，而不是管理基础架构，同时为更好的性能提供新的机会。

同时，能够从边缘查询并不意味着您应该这样做。 “以用户感知的性能”是一个复杂的主题，您应该始终根据应用程序的特定特征做出量身定制的决定，最重要的是，在现实世界中对其进行彻底测试。

---

我们正在构建ZenStack，这是一种工具包，它可以用强大的访问控制层增强Prisma Orm，并释放其全堆栈开发潜力。如果您喜欢阅读并感到项目有趣，请帮助明星播放，以便更多的人可以找到它！