WebAssembly 如何吞噬数据库_数据库_Dominique Saulet



大小：1.28M时长：07:26

用户定义函数（UDF）一直都是数据库系统中的固有功能，允许用户扩展数据库的内置功能，用来补充 SQL 语句，使其用起来更方便。尽管传统的 UDF 是一个强大的工具，但开发人员经常被迫使用自己不熟悉的编程语言（这些编程语言是数据库独有的）。然而，随着具有沙盒安全控制和广泛语言支持（WebAssembly）的可移植、低级二进制格式的诞生，行业出现了我们乐见的一种新的 UDF 实现。

例如，Singlestore 的代码引擎为用户提供了使用 Wasm 代码创建 UDF 和表值函数（TVF）的能力，而 InfinyOn 和 RedPanda 让开发人员能够使用 Wasm 操作数据流。我们自己的 Extism 是一个通用插件系统，在一个演示中展示了使用 Wasm UDF 扩展 SQLite3 的能力。让我们在本文中更深入地了解驱动这个趋势的因素，并谈谈对未来的一些想法和思考。

安全

除了支持各种语言运行环境，数据库提供者还必须确保适当的沙盒控制能力，以便主机系统（即数据库）免受任何意外或恶意的副作用。

Wasm 特别适合这种情况，因为运行时被设计为在沙箱环境中执行代码，默认情况下对主机系统资源的访问受到限制。有了这种内置的隔离，数据库提供商可以花更少的时间来运行自己的安全运行时，而有更多的时间在 Twitter 上展示自己。

性能和便携性

Wasm 代码最大的特性是占用空间小，因此可以很容易地对数据进行计算，并且接近原生的执行速度使其非常适合复杂的数据工作负载。

数据集日益庞大，使得在数据库和应用程序之间来回传输数据进行处理变得繁琐和昂贵。除了由这种工作流造成的额外延迟之外，每个连接到数据库的新应用程序都会增加额外的故障点，与数据驻留相关的问题都使得直接在数据旁边运行 Wasm 非常有吸引力。能够将数据保存在它所在的地方，并将（至少部分）应用程序带到它上面，对于不明确和复杂的监管环境来说，这一简化的意义重大。

此外，将计算引入数据的能力消除了系统对许多微服务的需求——取而代之的是在数据库中运行这些微服务!

就可移植性而言，为什么数据库用户要一遍又一遍地针对不同的主机数据库实现 UDF 呢?编写一次，并在任何数据库的任何地方运行！UDF 的一个传统优点是它可以跨 SQL 查询重用，但为什么要将可重用性限制在一个数据库平台上呢？通过混合使用 Wasm，UDF 重用的范围理论上可以扩展到任何支持 Wasm 运行时以及主机功能的标准化接口的数据库上。

在实践中，这需要跨数据库提供者的生态系统进行某种程度的协作，或者需要社区努力将各种接口虚拟化成一个公共标准，但这种可能性和相关的好处都是可预期的。

其他想法和注意事项

Wasm 显然是 UDF 的力量倍增器，但是让我们讨论一下应该考虑的一些设计和实现方面的话题。

主机界面和设施

数据库提供程序必须支持一组导入和导出，这些导入和导出将作为数据库和 Wasm UDF 之间交互的基础。如上所述，如果接口能够标准化，将有利于整个生态系统。WASI SQL Embedding 就是这样一个例子，它提出了一种将 WASM 模块作为扩展嵌入到 SQL 数据库中的标准。

设计高质量的语言支持和库对于成功至关重要，因为 UDF 创建者将需要这样的支持来实现其实现目标。例如，Python 开发人员希望 NumPy 可以用于分析工作。数据库提供者应该考虑在主机级别包含这种支持，特别是出于性能原因而需要本地扩展时。这样做使用户可以访问必要的库，而不必强制将它们直接编译到 Wasm UDF 中，因为这会增加模块本身的大小。

如果可能的话，应该围绕任何导入提供特定于语言的包装器，以提供惯用语言支持。看看像 Extism 这样的开源项目，它为创建这些类型的实用程序的团队提供了一个良好的开端。