从物理磁盘位置加载 ML 模块（Xquery / Javascript）和从 ML 内部的 ML 模块数据库加载之间有什么性能差异？

Any performance difference between loading ML Module (Xquery / Javascript) from physical disk localation and loading from ML Module DB inside ML?

默认情况下，ML HTTP 服务器将使用 ML 中的 Module DB。（似乎所有 ML 培训材料都提到了那种类型的配置。） XQuery 程序中的任何更改都需要先上传到模块数据库中。这可以通过使用 mlLoadModules 或 mlReloadModules ml-gradle 命令来完成。 CI/CD不直接访问ML集群。一切都通过 ml-gradle 从专用于代码部署的机器到不同的 ML 环境，如 dev/uat/prod 等

然而，也可以将 ML 应用程序服务器配置为使用来自 物理磁盘位置 的 XQuery 程序，如下图所示。使用该配置，不需要将程序重新加载到 ML 模块数据库中。程序中的更改必须在 ML 服务器本身中进行。 CI/CD 将需要直接访问 ML 集群。这种方式的一个优点是开发人员可以很容易地看到程序中的更改是否确实已部署，因为所有更改都以物理可读文本文件的形式存储在磁盘中。

问题：

哪种方式更好？为什么？
这两种不同方法之间有任何 ML 查询性能差异吗？
对于物理文件方法，是否意味着CI/CD需要将程序更改部署到 ML 集群中的所有 ML 主机？（我想如果 HTTP 服务器从 ML 内部的 Module DB 引用 XQuery 程序，这不是问题。ML 集群将自动在不同主机之间同步代码。）

一般来说，建议将模块部署到数据库而不是文件系统。

这使得部署变得更加简单和容易，因为您只需将模块一次加载到模块数据库中，而不是将文件放在每个主机上。如果使用文件系统，则需要将这些文件放在集群中的每个主机上。

使用模块数据库，如果要向集群添加节点，则不必同时部署模块。然后，您还可以利用高可用性、备份和还原以及数据库的所有其他功能。

模块一旦被读取，就会加载到缓存中，因此对性能的影响应该可以忽略不计。

以便可以在该数据库中安装配置。

有些人可能希望使用文件系统在单个节点上进行简单开发，其中保存到文件系统的更改无需重新部署即可使用。但是，您可以使用 ml-gradle mlWatch task 之类的东西在文件系统上修改模块时自动部署模块，并使用模块数据库有效地实现相同的目的。

从物理磁盘位置加载 ML 模块（Xquery / Javascript）和从 ML 内部的 ML 模块数据库加载之间有什么性能差异？

Any performance difference between loading ML Module (Xquery / Javascript) from physical disk localation and loading from ML Module DB inside ML?

performance

marklogic