一周热榜

我们开发了 browser-metro，这是一款类似 Metro 的打包工具，完全在 Web Worker 中运行。它支持与 React Refresh 的完整热模块替换（HMR）、基于文件的 Expo Router 路由，以及通过 ESM 服务器按需解析 npm 包。API 路由通过 fetch 拦截在浏览器中运行，无需服务器或服务工作者。 与 Expo Snack（服务器端打包）或 CodeSandbox 不同，这里的一切都发生在客户端。目前仅支持网页预览；原生设备预览在计划中。 开源（MIT）：[https://github.com/RapidNative/reactnative-run](https://github.com/RapidNative/reactnative-run)

我用 Rust 构建了一个 SQLite VFS，它能够直接从 S3 提供冷查询，性能达到亚秒级，且通常更快。<p>这个项目叫做 turbolite。它仍处于实验阶段，存在一些错误，可能会导致数据损坏。我目前不建议将其用于任何重要的事务。<p>我想探索对象存储是否已经足够快速，以支持基于云存储的嵌入式数据库。文件系统对小的随机读取和就地修改有很好的支持，而 S3 则更倾向于减少请求、增加传输量、使用不可变对象，以及在带宽通常是主要限制的情况下进行高并发操作。这一设计灵感明确来源于 turbopuffer 的从零开始的 S3 原生设计。 <a href="https:&#x2F;&#x2F;turbopuffer.com&#x2F;blog&#x2F;turbopuffer" rel="nofollow">https:&#x2F;&#x2F;turbopuffer.com&#x2F;blog&#x2F;turbopuffer</a><p>我设想的用例是大量主要处于冷状态的 SQLite 数据库（每个租户一个数据库、每个会话一个数据库或每个用户一个数据库的架构），在这种情况下，为不活跃的数据库保持一个单独的附加卷显得很浪费。turbolite 假设只有一个写入源，更加关注“许多数据库的突发冷读取”而不是“一个热数据库”。<p>turbolite 不会简单地逐页读取原始 SQLite 文件，而是会深入分析 SQLite 的 B 树，将相关页面压缩在一起存储，并保持一个清单，作为每个页面位置的真实来源。缓存未命中时，它使用可寻址的 zstd 帧和 S3 范围 GET 来进行搜索查询，因此获取一个所需页面并不需要下载整个对象。<p>在查询时，turbolite 还可以将存储操作从查询计划传递到 VFS，以便提前下载索引和大规模扫描所需的数据，按照它们将被访问的顺序进行。<p>你可以调整 turbolite 的预取策略。对于点查询和小规模连接，它可以保持保守，避免预取整个表。对于扫描，它可以变得更加激进。<p>它还会根据页面类型在 S3 中对页面进行分组。内部 B 树页面单独打包并被提前加载。索引页面则会进行积极的预取。数据页面按表存储。目标是使冷点查询和连接表现良好，同时使扫描的效率比简单的远程分页要好。<p>在 EC2 + S3 Express 上进行的 1M 行 / 1.5GB 基准测试中，我看到的结果包括亚 100 毫秒的冷点查找、亚 200 毫秒的冷 5 连接查询，以及从空缓存中进行的亚 600 毫秒的扫描，数据库大小为 1.5GB。在普通的 S3/Tigris 上速度稍慢。<p>当前的局限性非常明确：它仅支持单写入，并且仍然是一个系统实验，而非生产基础设施。<p>我非常希望能收到那些在网络上使用 SQLite、存储引擎、VFS 或基于对象存储的数据库方面有经验的人的反馈。我特别感兴趣的是，B 树感知的分组/清单/可寻址范围 GET 的方向是否是值得继续推进的正确方向。