Manage published functions（管理已发布的函数）¶

Once published, all types of functions can be viewed and managed using the Ontology Manager.

Searching for functions¶

To search for functions, navigate to the Ontology Manager and select the Functions tab. You can search for functions by most metadata on the function, including but not limited to the function name, description, API name and RID.

Function overview page¶

After selecting a function in the Ontology Manager, you can view basic information about the function, including its inputs and outputs and any associated usage history for the function.

View function overview in Ontology Manager

Function configuration page¶

Some types of functions allow you to configure resources such as timeouts or memory limits. If your function supports any configuration options, you can view and edit them in the Configuration tab. If this tab is not present, the function does not support any configuration options.

:::callout{theme="neutral"} Configuration overrides are applied on a per-function version basis. Depending on the application from which you publish your function, new versions may have the default configuration and you may need to reapply any configuration overrides. :::

For example, you can configure the timeout on a TypeScript function as seen in the following image.

Manage function runtime configurations in Ontology Manager

Configuration inheritance¶

Functions provide out-of-the-box support for inheriting configuration overrides when publishing new versions. The configuration is inherited from the prior stable version according to the semantic version specification. If publishing a non-stable version, configurations will be inherited from the prior version, regardless of whether it is a stable release.

Configuration inheritance requires your repository to contain updated template configurations. You can check the hidden templateConfiguration.json file to confirm the version your repository is on.

For TypeScript v1 functions repositories, you must have parentTemplateVersion >= 3.512.0
For Python functions repositories, you must have parentTemplateVersion >= 0.423.0

Consistent snapshots¶

Function-backed actions automatically use one ontology snapshot for all read requests in a single run.

Consistent snapshots provide the following qualities:

Data consistency: Without snapshots, sequential ontology queries within a function could return different versions of data if the underlying data changed between requests. With snapshots, your function operates on a consistent view of the ontology, similar to snapshot isolation in a database transaction.
Improved performance: Reusing a single snapshot across all ontology requests significantly improves ontology read performance. A single function-backed action, along with any queries within, receives this benefit.

Snapshot configuration¶

If you need to explicitly manage snapshots for advanced use cases, you can configure the snapshot behavior on the function configuration page using the following options:

Default (recommended): Leave this option selected unless you encounter snapshot-related errors.
Disable snapshots: Use when you need the freshest data on each query during a run, or when you are hitting snapshot errors due to long-running workloads.
Enable snapshots: Use when you need a consistent point-in-time view across all reads and want better read performance, and your function can tolerate data not updating mid-run. This is not recommended for most use cases.

:::callout{theme="warning"} By default, functions with sources run against live data without snapshots. Enforcing snapshots is not recommended since functions can perform writes or invoke external systems. :::

Enforced limits¶

Several limits are in place to prevent functions from consuming too many resources when they are executed.

Time limit¶

Functions are limited to 60 seconds of elapsed run time by default. These limits can be modified on the function configuration page.

Functions are allowed to run for up to 280 seconds when running in live preview, even if modified on the function configuration page.

:::callout{theme="warning"} TypeScript v1 functions are additionally limited to 30 seconds of CPU time, which is not configurable. When a function exceeds this threshold, the cause is often inefficient data loading logic. Refer to the section on optimizing performance for tips on how to avoid CPU timeouts. :::

Memory limit¶

Memory limits differ between TypeScript v1, TypeScript v2, and Python functions.

TypeScript v1¶

Function execution is limited to 128 Megabytes of memory usage. This limit is rarely reached; often, functions run into time limits or object loading limits before memory limits.

Deployed Python functions¶

Deployed Python functions have 2 Gigabytes of memory usage by default. Currently, deployed Python functions cannot configure memory usage on the function configuration page.

Serverless Python and TypeScript v2 functions¶

Serverless functions have 1024 Mebibytes of memory usage by default. This can be configured from 512 Mebibytes to 5120 Mebibytes on the function configuration page.

Multithreading¶

For TypeScript v1, function execution is on a single thread, allowing only one computation at any given time. However, you can parallelize loading of object sets or links. Refer to optimizing performance for more information.

For TypeScript v2 and Python functions, you can use multithreading with the built-in Node.js worker_threads and Python threading libraries.

Object set limits with TypeScript v1¶

When using object sets, calling .all() or .allAsync() will throw an error if:

More than 100,000 objects are loaded at once from the object set. In general, even loading tens of thousands of objects will run into time limits or memory limits. For use cases where you are running into this limit, consider fetching summary data using aggregations or fetching a subset of objects using ordering and limiting.
More than 3 search arounds are used at once.

Some aggregation and bucketing operations have limits. See the aggregations section for details.

中文翻译¶

管理已发布的函数¶

一旦发布，所有类型的函数都可以通过本体管理器(Ontology Manager)进行查看和管理。

搜索函数¶

要搜索函数，请导航至本体管理器(Ontology Manager)并选择函数(Functions)选项卡。您可以通过函数的大多数元数据进行搜索，包括但不限于函数名称、描述、API名称和RID。

函数概览页面¶

在本体管理器(Ontology Manager)中选择一个函数后，您可以查看该函数的基本信息，包括其输入和输出以及任何相关的使用历史记录。

在本体管理器中查看函数概览

函数配置页面¶

某些类型的函数允许您配置资源，例如超时时间或内存限制。如果您的函数支持任何配置选项，您可以在配置(Configuration)选项卡中查看和编辑它们。如果此选项卡不存在，则表示该函数不支持任何配置选项。

:::callout{theme="neutral"} 配置覆盖是按函数版本应用的。根据您发布函数的应用程序，新版本可能使用默认配置，您可能需要重新应用任何配置覆盖。 :::

例如，您可以像下图所示那样配置TypeScript函数的超时时间。

在本体管理器中管理函数运行时配置

配置继承¶

函数在发布新版本时提供了开箱即用的配置覆盖继承支持。配置根据语义版本规范从先前的稳定版本继承。如果发布的是非稳定版本，配置将从先前版本继承，无论该版本是否为稳定版本。

配置继承要求您的仓库包含更新的模板配置。您可以检查隐藏的templateConfiguration.json文件来确认您的仓库所使用的版本。

对于TypeScript v1函数仓库，您必须拥有parentTemplateVersion >= 3.512.0
对于Python函数仓库，您必须拥有parentTemplateVersion >= 0.423.0

一致性快照¶

函数支持的操作会自动在单次运行中为所有读取请求使用一个本体快照。

一致性快照提供以下特性：

数据一致性： 没有快照时，如果底层数据在请求之间发生变化，函数内的顺序本体查询可能返回不同版本的数据。使用快照后，您的函数将在本体的一致视图上运行，类似于数据库事务中的快照隔离。
性能提升： 在所有本体请求中重复使用单个快照可显著提高本体读取性能。单个函数支持的操作及其内部的任何查询都将受益于此。

快照配置¶

如果您需要为高级用例显式管理快照，可以在函数配置页面上使用以下选项配置快照行为：

默认（推荐）： 除非遇到快照相关错误，否则请保留此选项。
禁用快照： 当您需要在运行期间每次查询都获取最新数据时，或者当您因长时间运行的工作负载而遇到快照错误时使用。
启用快照： 当您需要在所有读取操作中获得一致的时间点视图并希望获得更好的读取性能，且您的函数能够容忍数据在运行过程中不更新时使用。对于大多数用例，不建议使用此选项。

:::callout{theme="warning"} 默认情况下，带有数据源的函数在没有快照的情况下对实时数据运行。不建议强制使用快照，因为函数可能执行写入操作或调用外部系统。 :::

强制限制¶

系统设置了若干限制，以防止函数在执行时消耗过多资源。

时间限制¶

默认情况下，函数的运行时间限制为60秒。这些限制可以在函数配置页面上修改。

在实时预览中运行时，即使已在函数配置页面上修改，函数最多允许运行280秒。

:::callout{theme="warning"} TypeScript v1函数额外限制为30秒的CPU时间，此限制不可配置。当函数超过此阈值时，原因通常是数据加载逻辑效率低下。请参阅优化性能部分，了解如何避免CPU超时的技巧。 :::

内存限制¶

TypeScript v1、TypeScript v2和Python函数的内存限制有所不同。

TypeScript v1¶

函数执行的内存使用限制为128兆字节。此限制很少达到；通常，函数在达到内存限制之前就会遇到时间限制或对象加载限制。

已部署的Python函数¶

默认情况下，已部署的Python函数的内存使用量为2吉字节。目前，已部署的Python函数无法在函数配置页面上配置内存使用量。

无服务器Python和TypeScript v2函数¶

默认情况下，无服务器函数的内存使用量为1024兆比字节。这可以在函数配置页面上配置为512兆比字节到5120兆比字节之间的值。

多线程¶

对于TypeScript v1，函数执行在单线程上进行，任何给定时间只允许进行一次计算。但是，您可以并行加载对象集或链接。有关更多信息，请参阅优化性能。

对于TypeScript v2和Python函数，您可以使用内置的Node.js worker_threads和Python threading库进行多线程操作。

TypeScript v1的对象集限制¶

使用对象集(object sets)时，在以下情况下调用.all()或.allAsync()将抛出错误：

一次从对象集中加载超过100,000个对象。通常，即使加载数万个对象也会遇到时间限制或内存限制。对于遇到此限制的用例，请考虑使用聚合(aggregations)获取摘要数据，或使用排序和限制(ordering and limiting)获取对象子集。
一次使用超过3个搜索环绕(search arounds)。

某些聚合和分桶操作存在限制。详情请参阅聚合(aggregations)部分。