近日，Astro 团队推出了一项专为 Astro Web 框架设计的全面托管的 SQL 数据库服务。让我们深入了解 Astro DB 的实现细节：它是如何工作的，为什么 Astro 构建它以及为什么采用 libSQL。
Astro 独特之处在于专注于构建内容驱动的网站。Astro 其核心是内容，这就是为什么在 Astro 2.0中推出了内容集合。Astro 的用户喜欢它作为管理本地内容的一种方式。
WordPress 一直是 Astro 巨大灵感的来源之一。使 WordPress 如此特别的其中一个因素就是其内置数据库。您不仅可以管理文章内容，还可以管理数据、页面、块、图片以及整个插件生态系统。
Astro 希望为其打造类似于此功能，但很快意识到静态存储库数据能够走多远已经达到了极限。
寻找和失去 SQLite
为了通过数据集合和引用来发展内容收藏，Astro 正在构建一个类似数据库的 ORM 文件系统，并且遇到了几个挑战。核心团队成员 Erika 提出了一个想法：为什么不使用数据库 SQLite 呢？
Astro 爱上了将轻量级数据库内置于本身的想法。对于大多数内容驱动型网站的读取密集工作负载来说，SQLite 非常适合。
Astro 原型化了这个想法，但遇到了一些障碍。由于 SQLite 是一个 C 库，因此它需要本机插件才能在 Node.js 中运行。这对于本地开发来说没问题，但是很难部署到无服务器主机，并且启动时间令人担忧。此外，像 StackBlitz 这样的关键环境完全无法运行它。
失败后，Astro 把这个想法搁置一边专注于其他事情。那是 2023 年春天。
寻找并爱上 libSQL
与此同时，在地球的另一端，另一个团队正在解决这个确切的问题。那支团队是 Turso，他们的解决方案是 libSQL。
libSQL 是 SQLite 的一个分支，引入了一系列改进以提高运行时性能，同时保持与经典 SQLite 的兼容性。libSQL 提供了一个现代化的数据库客户端，适用于 JavaScript/TypeScript，并避免了困扰整个生态系统的本机绑定和编译步骤。它甚至可以通过 WASM 在 StackBlitz 上运行。
Turso 还为 libSQL 数据库提供托管服务，重点关注我们所需的规模。Astro DB 的愿景开始形成，但直到 2023 年 12 月所有要素最终才得以完美结合。
设计本地数据库
Astro DB 在启动开发服务器时为您提供完全本地的 libSQL 数据库。由于 Astro 具有静态站点生成器的背景，因此重要的是数据库可以从头开始构建，以便将来它可以支持一个内容层，其中数据来自各种地方，包括文件系统。
当您运行 astro dev 时，Astro DB 将会：
- 在
.astro/data.db创建空数据库 - 从
db/config.ts读取你的 schema - 从
db/seed.ts文件填充数据库 - 你的数据库客户端现在已准备就绪
Astro 用户已经喜爱的工作流程在很大程度上与内容集合工作流程相似。重要的是，数据库本身（data.db）不是持久性的。每次启动开发服务器时都会从头开始创建它。这为您提供了简单、可复制的一次性数据库。
Astro DB 将 Web框架、模式、种子文件和数据库本身全部融合成一个连贯的故事。Astro 甚至为其包含了一个 ORM：Drizzle。Astro 选择 Drizzle 是因为它是一种类型安全的 ORM，让您可以尽可能接近底层，并且还支持插件化，这使我们能够在其上添加自己的行为。
使用托管数据库
Astro DB 包括一个托管的 libSQL 数据库，您可以在本地开发和生产环境中连接到它。一切都通过 Astro Studio 平台为您管理。您可以在 30 秒内为项目创建一个新数据库。
为了实现所需要的规模，Astro 与 Turso 合作，他们维护 libSQL 并运营最大的 libSQL 托管平台。他们致力于「每个租户一个数据库」的模式非常适合 Astro 需要按需启动数十万个数据库。
去年 Astro 团队还花了一些时间原型化 Cloudflare 的 D1 产品。但 Astro 需要的只是数据库时，在 workers 和 worker bindings 增加了抽象层让人感到困惑。此外，如果这意味着将专有数据库技术捆绑到 Astro 本身上，则会使人犹豫不决。最终，Astro 发现 D1 并不适合其用例。
零停机模式迁移
您的数据库架构在项目 db/config.ts 文件中定义。当您对架构进行更改时，需要将它们推送到托管的数据库，以消除数据丢失和停机风险。因此 Astro 开发了 astro db push。
push 命令旨在平衡易用性，同时鼓励适用于生产大型项目的最佳实践。在 Astro DB 中没有要管理的迁移文件。相反，在运行 push 时，您的架构会自动与托管的生产数据库进行比较，并应用任何新更改。如果这些更改无法安全添加或以任何方式存在数据丢失风险，则不会应用这些更改。
这鼓励「扩展和收缩」迁移策略在 Astro DB 应用程序中使用。如果您正在进行快速开发并且不介意根据需要重置数据库，则可以运行 astro db --force-reset 来推送任何想要的模式更改，包括数据库重置。
在确定最终版本之前，Astro 经历了几个不同版本的架构迁移系统迭代过程。有一段时间甚至有一个 migrations 文件夹，在那里您可以手动创建和检查显式迁移计划文件到存储库中去。虽然有些人喜欢这种模型，但对大多数用户来说记得每次更改其架构时都去创建一个迁移是个烦人的步骤。
总结
Astro DB 对其第一次迭代中找到的平衡感到满意，给未来 Astro 本地用例奠定基础，同时提供了一个简单的方式来部署生产数据库。这篇文章中遗漏的一个细节是集成如何能够提供他们自己的表格和数据，希望在继续沿着建立 Astro 内容和插件下一次迭代之路时更多地探索这个问题。
要开始集成您的应用程序，请查看文档。