WebAssembly 的出现，给予了数据库领域新的动力，也随之带来了更多的可能与变革。

原文 链接：https://dylibso.com/blog/wasm-udf/

未经允许，禁止转载！

(资料图片)

作者 | Dominique Saulet Steve Manuel 译者 | 弯月 责编 | 郑丽媛 出品 | CSDN（ID：CSDNnews）

长期以来，用户定义函数（User Defined Function，简称 UDF）一直是数据库系统中不可或缺的一个功能，用户可以通过 UDF 扩展数据库的内置功能。 尽管传统 UDF 是一个强大的 工具，但 大 多数情况 下开发人 员都 被迫使用不熟悉的编程语言 ——通常是数据库特有的语 言。

然而，随着具有沙 盒安全控制和广泛语言支持（WebAssembly）的可移植、低级二进制格式的出现， 新一 轮的 UDF 实现开始涌现。

举个例子，Singlestore 的代码引擎为用户提供了使用编译为 Wasm 的代码创建 UDF 和表值函数（Table-Valued Functions，简称 TVF）的能力，而 InfinyOn 和 RedPanda 为开发人员提供了使用 Wasm 从其平台内操作数据流的功能。我们自己开发的通用插件系统 Extism 则可以使用 Wasm UDF 来扩展 SQLite3。

下面，我们来更深入地了解一下推动这一趋势的因素，以及 对未来的一些想法和考虑。

多语言

使用多种编程语言创建 UDF 的支持，扩大了对许多开发者社区的影响，从而导致数据库提供商的市场扩张。另一方面，数据库用户希望使用自己最喜欢的语言编写 UDF，并希望这些语言能为他们提供最好的生产力。

因此， 对于 数据库创建者和消费者来说， 更多的语言支持显然是双赢的——那为什么以前对 UDF 的语言支持如此有限呢？

大致原因可归咎于时间和资源，如果没有针对语言的通用运行时和可执行格式，数据库供应商就需要构建/集成和维护各种语言运行时，以提供 Wasm 的广泛语言支持。这是一项复杂且耗时的任务，因此从优先级排序上看自然要让位于其他任务，更常见的方法是选择一种广泛使用的通用编程语言（例如 JavaScript）或创建一种领域特定的语言（DSL）。

对于前者（选择一种广泛使用的通用编程语言），数据库供应商将自己的 UDF 引擎与选择的语言联系了起来；而对于后者（创建一种领域特定的语言），数据库供应商的做法也大抵相同，但由于学习曲线更陡峭且这类语言缺乏可转移性，因此给产品采用带来了更多摩擦。

而如今，UDF 的春天来了。在撰写本文时，有十多种语言直接以 Wasm 为目标，随着未来更多语言的加入，数据库平台无需大费周折就可以获得这些附加功能。

安全

除了支持各种语言运行时，数据库提供商还需要确保适当的沙箱控制，以保护宿主系统（即数据库）免受任何意外或恶意的副作用影响。Wasm 就特别适合这项任务，因为 Wasm 的运行时在沙盒环境中执行代码，默认情况下对宿主系统资源的访问会受到限制。

有了这种天然的隔离，数据库提供商就无需花费太多时间编写自己的安全运行时。

性能和便携性

Wasm 代码占用的空间非常小，因此很方便计算数据，接近原生的执行速度使其非常适合复杂的数据工作负载。

数据集日益增大，这使得在数据库和应用程序之间来回传输这些数据集的处理会变得既麻烦又昂贵。除了此类工作流造成的额外延迟之外，每个连接到数据库的应用程序都会成为一个额外的故障点，再加上与数据驻留相关的一系列问题，如果 Wasm 能直接与数据一起运行就变得非常有吸引力：数据可以保存在本地，而应用程序可以直接在 Wasm 中运行，这样整个结构更加清晰，且可以简化复杂的监管环境。

此外，将计算带到数据中的能力消除了对微服务的需求——因为这些计算可以直接在数据库中运行。

就可移植性而言，为什么数据库需要针对不同的主机数据库一遍又一遍地实现 UDF？我们希望编写一次，就可以在所有数据库中运行。 UDF 的一个常见优势是它可以跨 SQL 查询重用，我们又 何必将这种重 用性限制在一个数据库平台上呢？

结合 Wasm 之后，UDF 的 重用 范围理 论上可以扩展到所有支持 Wasm 运行时以及主机功能标准化接口的数 据库。 在实践中，这需要整个数据库提供商生态系统进行某种程度的协作，或者社区努力将各种接口虚拟化为一个通用标准，但我们可以享受到相应的好处。

其他想法和注意事项

Wasm 可以放大 UDF 的优势，但我们需要考虑一些设计和实现方面的因素。

宿主接口和设施

数据库提供者必须支持一组导入和导出，这些导入和导出将作为数据库和 Wasm UDF 之间的交互基础。如上所述，如果这个接口可以标准化，则整个生态系统都会受益。WASI SQL 嵌入是此类提议的一个示例，旨在为 WASM 模块作为扩展嵌入 SQL 数据库的方式制定标准。

设计高质量的语言支持和库是成功的关键，因为 UDF 创建者需要这样的支持来达成他们的实现目标。例如，Python 开发人员希望利用 NumPy 分析工作负载。数据库提供商应考虑在主机层面提供此类支持，尤其是当出于性能原因需要原生扩展时。这样可以方便用户访问必要的库，而不必强制将它们直接编译到 Wasm UDF 中，后者会增加模块本身的大小。

如果可能，导入应该提供特定于语言的包装器，以提供惯用语言支持。Extism 等开源项目可以为创建此类实用程序的团队提供一个良好的开端。

事务隔离/完整性

大多数用于生产的数据库都会在事务中运行 UDF，这样就可以在发生异常时无缝回滚，而且无需在代码中实现故障处理。话虽如此，考虑事务应当如何适应 Wasm 风格的 UDF 及其规则很重要，这仍然是数据库实现者需要自行解决的问题。

可观察性和验证

数据库提供者和 UDF 创建者需要什么工具来观察和检查 UDF 的性能，并在意外发生时对其进行调试呢？多租户可观察性是这类生态系统中未能满足的需求，应该仔细考虑。

回到主机/访客接口标准化的主题，如果定制接口是必须的，可以考虑使用 Modsurfer 之类的工具，这些工具为数据库提供商和 UDF 创建者提供了一种以主动方式验证相互兼容性的方法。一些导入和导出、运行时复杂性、二进制大小和函数签名都是关键组件，应该成为验证方案的一部分。

UDF 以及其他方面

除了 UDF 之外，从数据库的其他方面来看，包括存储过程、表值函数以及用户定义聚合函数等，WebAssembly 的可扩展性已趋于成熟。我们应该让用户表达他们最深层次的数据驱动欲望！

关键词：