openGauss＋Wasm：构建安全高效的UDF执行引擎 - 网站源码_资源分享

很多人听说 WebAssembly，或者它的全称 Wasm，可能还是虽然它在插件中获得了广为的应用领域。但是，近些年来随著 Wasm 持续不断的产业发展，其在服务端的应用领域也越来越广为。在刚刚过去的 10 月底，Docker 发布了 Docker+Wasm 的控制技术自动更新版，意在为各阶层开发人员提供更多两个更加速快捷地构筑 Wasm 应用领域程序的罐子自然环境，这一姿势标志着 Wasm 在云原生植物领域已经获得了有效应用领域。那么，甚么是 Wasm 呢？

WebAssemby 是甚么？

先来看看非官方的表述：

WebAssembly (abbreviatedWasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

即 Wasm 是一类如前所述栈式软件包的十进制命令格式，意在为为数众多C语言提供更多一类图形界面的校对目标，方便快捷应用领域在 Web 插件及伺服器上的布署运转。

Wasm 问世Hathras，主要是为的是解决后端在繁杂销售业务方法论情景下，读取和运转较慢的问题。Wasm 文件格式的十进制码表面积十分小，可以加速高效率地递送和读取，程序标识符也十分快，并且虽然在设计Hathras抽象化利用的是常用的硬体能力，因而具备十分好的可变性。此外，Wasm 的运转被管制在两个安全可靠的沙盒自然环境中，因而具备极高的可靠性。

随著 Wasm 控制技术的产业发展，人们逐渐意识到 Wasm 的图形界面、高效能和可靠性等特征，在服务端的销售业务情景中同样具备巨大的应用领域价值。甚至于，2019 年，Mozilla、Fastly、Intel 以及 Red Hat 联合成立Cogl国联(BytecodeAlliance)，意在推动 Wasm 和 WASI(WebAssembly System Interface) 的技术标准，以期更快地推展和完善 Wasm 在服务端的应用领域情景和控制技术自然生态。

为的是推展和进一步增强 Wasm 在服务端的应用领域，Cogl国联主导力量幼体了 Wasmtime 工程项目。该工程项目提供更多两个特别针对 Wasm Cogl的独立的运转时。Wasmtime 具备如下表所示特征：

加速。Wasmtime 如前所述强化 Cranelift DDL器构筑，可在运转时或运转前加速聚合高效率的电脑标识符。

安全可靠。Wasmtime 的开发十分注重正确性和可靠性。在 Rust 运行时可靠性保证的基础上，每个 Wasmtime 的特性都经过 RFC 过程的仔细审查和研究。

可配置。Wasmtime 使用合理的默认值，同时提供更多丰富的配置项，可以特别针对 CPU 和内存等资源消耗进行更细粒度的控制。

WASI 接口丰富。Wasmtime 支持为数众多的 WASI 标准接口，可以很方便快捷的和宿主机进行通信。

标准兼容。Wasmtime 通过了非官方的 WebAssembly 测试套件，实现了 Wasm 的非官方 C API，并实现了 WebAssembly 中的为数众多未来特性。

数据库+Wasm 的尝试

Wasm 在问世Hathras就为自己贴上了高效能和高安全可靠的标签，而这些也是数据库系统所一直追求的。数据库系统如何融入 Wasm 控制技术，使其在数据库领域发挥其价值魅力，也成为的是很多开发人员探索的两个方向。

cunchydata 的开发人员，如前所述 v86 模拟器，将 PostgreSQL 整体率先成功地运转在浏览器之上，并如前所述此推出了 Web 上的操作平台，最终在 GitHub 上产业发展成两个高人气的开源工程项目。

Wasmer 的开发人员如前所述 Wasmer 的运转时，使用 Rust 语言为 PostgreSQL 开发了两个 Wasm 插件，使得在 PostgreSQL 中可以成功运转 Wasm Cogl。该插件为 PostgreSQL 提供更多了一类运转 Wasm 创建 UDF 函数，即用户表述函数的能力，开发人员可以将自己开发的 UDF 函数校对为 Wasm 十进制后导入 PostgreSQL 中运转。该工程项目仅支持 PG10 版，且在 Wasm 类型上仅支持整数类型，并且该工程项目已经有两年多没有更新过了。

最近 SQLite 的开发人员，如前所述 Wasmtime 运转时，成功的为 SQLite 开发支持了 Wasm 函数的能力，并已经合入 SQLite 社区。开发人员在 SQLite 中创建了新的函数表，提供更多了新的创建 UDF 函数的语言 Wasm 的语法，这样用户可以直接使用 create function function_name language wasm 的形式为SQLite 增加 UDF 函数。但是该方式无法批量导入开发人员开发的 Wasm 函数，且 Wasm 语言的表现形式比较差，普通用户无法直观的理解函数签名等重要信息，不便于用户使用 Wasm 函数。在函数调用时，在确定函数不存在于 SQLite 系统中时，才会去新增的函数表中查找该函数，这样的二次查找方式也会造成部分性能损耗。

openGauss 与 Wasm 的融合

在简单调研了 Wasm 的现状后，我们如前所述 Wasmtime 的运转时，为 openGauss 开发了一套独立的 UDF 函数执行发动机 WasmExecutor，下面就来详细看看这个 UDF 发动机是如何工作的。

WasmExecutor 总体架构

openGauss＋Wasm：构建安全高效的UDF执行引擎

上图便是我们设计的 UDF 执行发动机的结构图。如前所述 openGauss 提供更多的良好的扩展接口，我们插件化地实现了 Wasm 版的 UDF 执行发动机 WasmExecutor，这种插件化方式可以避免对 openGauss 内核标识符的侵入修改，保持版的独立演进。

如结构图所示，开发人员可以使用自己喜欢的C语言来设计开发 UDF 函数，开发完成后将函数校对为 Wasm 形式的十进制目标码，就可以通过 WasmExecutor 发动机提供更多的能力将 UDF 函数集成到 openGauss 数据库中。在此之后，用户便可以像使用内置函数一样，使用新增的 UDF 函数了。

为的是实现将 Wasm 文件中的函数导入到 openGauss 的能力，我们开发了读取模块。该模块提供更多两个函数 wasm_new_instance(absolutepath: text, namespace: text) 和 wasm_new_instance_wat(absolutepath: text, namespace: text)，其中第两个参数用来指定待导入 Wasm 文件的绝对路径，第二个参数用来指定函数将导入的名称空间。之所以设置第二个参数，是方便快捷人们进行函数管理，避免函数名称冲突，最终用户在 SQL 调用时提供更多的函数名称为 namespace_funcname 的新名称。顾名思义，Wat 后缀的读取函数用来读取 Wat 文件格式的函数文件。读取模块会对提供更多的 Wasm 文件进行基本效验，然后调用 Wasm 的 runtime 接口来读取解析 Wasm 文件，将解析结果保存在运转时管理中。

运转时管理主要实现读取到内存中 Wasm 文件的管理工作，并且为每个读取的 Wasm 文件，如前所述文件绝对路径计算两个哈希值，作为该文件的 uuid 使用。运转时管理提供更多名为 wasm.instances 的元信息表，用户可以查询该表获得当前系统中创建的 wasm 实例信息。

函数管理模块主要实现 Wasm 文件中导出的函数与 openGauss 内核的绑定，每两个 Wasm 导出函数都会绑定到对应的公共接口上，以期用户通过 SQL 语法可

下图所示即为调用读取函数读取新的 Wasm 文件时的流程示意图。

实操演示

下面我们实际操作下，如何通过 WasmExecutor 发动机来读取执行 Wasm 文件格式的 UDF 函数。为的是方便快捷伙伴们加速体验，我们提供更多了支持 WasmExecutor 引

罐子启动成功后，登录 openGauss 数据库，创建 WasmExecutor 发动机，如下表所示：

在罐子镜像中，我们默认内置了一些 Wasm 和 Wat 文件格式的示例文件，供伙伴们加速上手体验，这些文件放置于 /home/opengauss 路径下，如下表所示所示

如下表所示，我们使用 wasm_new_instance 和 wasm_new_instance_wat 来分别读取 sum.wasm 和 fib.wat 中的函数，在读取函数文件时，提供更多函数放置的名称空间 namespace，方便快捷进行函数管理，最终注册到 openGauss 系统表中的函数名称将会是 namespace_funcname 的新名称。

openGauss＋Wasm：构建安全高效的UDF执行引擎