Compute usage with Ontology queries（使用本体查询的计算用量）¶

The Foundry Ontology is a data backend that maps file-based data to organization-centric objects and serves high-speed queries for data exploration, data analysis, operational data editing, scenario analysis, and more. The Ontology stores data in multi-modal storage backends that each have their own purposes and can be flexibly queried in a single request. Querying the Foundry Ontology requires knowledge of some foundational concepts discussed below.

:::callout{theme="neutral"} If you have an enterprise contract with Palantir, contact your Palantir representative before proceeding with compute usage calculations. :::

Core concepts: Object types and object sets¶

The first important concept is the difference between an object type and its corresponding object set. An object type is the semantic representation of the entity itself (such as the name and properties of the object).

An object type has a corresponding object set, which contains the objects themselves. The size of the object set corresponds to the number of rows of the incoming dataset and the number of objects created and deleted by Ontology actions.

Core concept: Query types¶

The second important concept is the idea of query types, which include filters, aggregations, Search Arounds, and writeback operations. Each query type requires compute to execute. See Ontology Query Compute (2026) for the current compute-second overhead per query type.

When using the Foundry Ontology, query types are executed against object sets by the following Foundry Applications:

Object Explorer
Workshop
Quiver
Slate
Vertex
Foundry Rules
Foundry Machinery
Object APIs (OPIs)

Querying the ontology from any of these sources will use compute-seconds to run the query.

Investigating Foundry compute usage from Ontology queries¶

In Foundry, compute-seconds are attributed to resources in the platform rather than to the users that are interacting with those resources.

When it comes to Ontology queries, there are multiple ways in which compute is attributed. As a general rule, the compute is attached to the resource where the query originated. However, when there is no saved resource that is used to generate the compute (such as via API), the compute will be attached to the object types that are being queried. If multiple objects are queried in a single request, then the compute is attributed via an even split between the objects.

The following resource types have Ontology query compute attributed to them, rather than the underlying objects:

Workshop applications
Carbon pages
Quiver analyses and dashboards
Vertex applications
Slate applications
Foundry Machinery applications
Foundry Rules resources
Foundry Automate
AIP Logic
SQL Console worksheets
OSDK applications

The following interaction patterns have their Ontology query compute attached directly to the object types that they query, given there is no set resource to which the compute can be attached.

Object Explorer
Object APIs (including the OSDK)

Ontology Query Compute (2026)¶

:::callout{theme="neutral" title="Effective January 1, 2026"} The following compute model takes effect on January 1, 2026, and replaces the legacy model described in the Legacy section below. :::

Ontology Query Compute is driven by Ontology use by users and agents. Consider the primary factors that determine compute usage:

Factor 1: Number of users and agents¶

Compute-seconds are measured cumulatively. The more queries and transformations run against the ontology, the higher the overall compute usage. Query volume grows linearly with user interactions — such as application refreshes and interactive queries — as well as agentic transformations.

Factor 2: Query type¶

Users can access their Ontology through the following query types, each associated with a minimum compute-second overhead per query. Actual compute usage may be higher depending on query complexity and the size of the object set, or number of objects queried.

Base query: Returns the object set as-is or with basic filtering on certain properties.
Search Around query: Takes an incoming object set and runs a secondary filter on another object set based on a certain property of the incoming set.
Aggregation query: Takes an input object set and runs an aggregating function (such as sum or avg) on one of the properties for all objects in the set.
Ontology SQL query: Runs SQL queries directly against object types, links, and interfaces using standard Spark SQL syntax against object storage.
Advanced query: Anything not covered by other query types. For example, applying a semantic search over embeddings across a full object set.
Derived Property query: Derived Properties are properties calculated at runtime based on the values of other properties or links on objects, including aggregating on or selecting properties of linked objects. Derived properties are then available for further operations such as filtering, sorting, or aggregating within the same request.
Actions: Writeback operations that replace the values of properties of objects in a designated object set. Actions have a minimum overhead of 18 compute-seconds and scale with the number of objects edited, incurring an additional 1 compute-second per object edited beyond the first.
Ontology Compute (Phonograph) [Legacy]: Queries against objects still using the Object Storage V1 (OSv1) backend. These appear as "Ontology Compute (phonograph)" in the Resource Management Application. The existing OSv1 compute model has been retained for these queries.

The following table summarizes the minimum compute-second overhead per query type.

Query Type	Minimum compute-seconds overhead
Base query	2
Search Around query	5
Aggregation query	5
Ontology SQL query	5
Advanced query	10
Derived Property query	10
Actions	18
Ontology Compute (Phonograph) [Legacy]	16

:::callout{theme="neutral"} The existing compute model for Object Storage V1 (OSv1) queries has been retained. Any queries against objects still using the OSv1 backend carry a minimum compute-second overhead of 16 compute-seconds per query. :::

Measuring Foundry compute with Ontology object queries [Legacy]¶

:::callout{theme="neutral" title="Legacy"} The following sections describe the legacy compute model that was in effect before January 1, 2026. It is preserved for reference. For the current compute model, see Ontology Query Compute (2026) above. :::

Under the legacy model, querying the ontology uses compute-seconds as follows:

A fixed, minimum number of compute-seconds for query overhead.
An additional scaling number of compute-seconds, which are measured by the amount of compute used to service the query.

Measuring compute with Object Storage V1 [Legacy]¶

Object Storage V1 (Phonograph) stores data in a distributed set of indices in a durable, horizontally scalable cluster. In these indices, data sits in large data structures that are traversed by the Ontology query engine. When a query is executed, the engine can avoid processing large swaths of data during its search by traversing the index. This process is known as "pruning".

Using this engine, you can search through billions of records by evaluating up to 1000x fewer records. Each physical evaluation of a record is called a "hit". Object Storage V1 is designed to minimize the number of hits in each query.

Measuring compute with Object Storage V2 [Legacy]¶

Object Storage V2 (OSv2) stores objects in an enhanced indexing format that is optimized by Palantir for high-speed indexing, Search Arounds, and writeback, as well as smooth hand-offs to multiple compute backends to accomplish complex tasks. This includes a combination of fully parallelized Spark compute as a part of a query.

Given that Object Storage V2 also uses an efficient indexing structure, the same principle of hits from Object Storage V1 applies on basic queries. However, compute-seconds can also be used by on-demand Spark containers that are spun up as a part of the query.

Queries made to objects in the Object Storage V2 backend use compute in the following pattern:

A minimum compute-second overhead of 16 compute-seconds per query for objects in the Object Storage V1 backend.
A minimum compute-second overhead of 4 compute-seconds per query for objects in the Object Storage V2 backend. The optimized structure of Object Storage V2 requires less overhead than Object Storage V1 and therefore has a reduced minimum compute-second overhead.
Additional compute-seconds are required when the process does computational work through the pruning process of the query. The additional compute-seconds scale with the number of objects in the index as well as the type of query.
In Object Storage V2 (OSv2), the index pruning similarly requires additional compute seconds. However, OSv2 supports also on-demand Spark cluster searches when running search-arounds on over 100,000 objects, or running writeback operations on over 10,000 objects in a single request. These Spark clusters utilize usage in the same way as all other Spark-based applications on the platform. See the parallelized compute documentation for a description.
Actions with write-back into the Ontology have a minimum overhead. Each action has a compute-second overhead of 18. Actions also scale with the number of objects that are edited in the write-back request, incurring an additional 1 compute-second per object edited beyond the first.
Functions run via Functions on Objects have a minimum overhead. Specifically, each function execution has a fixed overhead of 4 compute-seconds.

The following table summarizes the minimum compute-second usage per query type under the legacy model.

Query Type	Minimum compute-seconds
Ontology V1 query	16
Ontology V2 query	4
Action on Objects	18
Function on Objects	4

Understanding drivers of Foundry compute usage with Ontology queries [Legacy]¶

As a very simple rule, the fixed compute-usage per query grows linearly with the number of queries. Performing fewer queries will use less compute in aggregate.
More complex queries to the object set service, such as generic multi-object searches, will kick off multiple sub-queries to each object type. Limit your search to individual object types to reduce the number of queries you are using.
Queries on smaller object sets will use less compute than those on larger object sets, as the number of hits in a query are proportional to the size of the object set being queried.
Up-front filtering before performing other operations will take advantage of the highly indexed backend structure. This will reduce the number of hits in a query, reducing the overall compute usage. This is especially important with aggregations and Search Arounds, where filtered object sets require less compute to process than full object sets.

For best practices on writing efficient functions and Automate configurations that minimize compute usage:

中文翻译¶

使用本体查询的计算用量¶

Foundry 本体（Ontology）是一个数据后端，它将基于文件的数据映射为以组织为中心的对象（object），并为数据探索、数据分析、操作性数据编辑、场景分析等提供高速查询服务。本体将数据存储在多模态存储后端中，每个后端都有其特定用途，并且可以在单个请求中灵活查询。查询 Foundry 本体需要了解下文讨论的一些基础概念。

:::callout{theme="neutral"} 如果您与 Palantir 签订了企业合同，请在开始计算用量计算之前联系您的 Palantir 代表。 :::

核心概念：对象类型与对象集¶

第一个重要概念是对象类型（object type）与其对应的对象集（object set）之间的区别。对象类型是实体本身的语义表示（例如对象的名称和属性）。

一个对象类型对应一个对象集，其中包含对象本身。对象集的大小对应于输入数据集的行数，以及通过本体操作（Ontology actions）创建和删除的对象数量。

核心概念：查询类型¶

第二个重要概念是查询类型（query types），包括筛选（filters）、聚合（aggregations）、周边搜索（Search Arounds）和回写操作（writeback operations）。每种查询类型都需要计算资源来执行。每种查询类型当前的计算秒数开销请参见本体查询计算（2026）。

在使用 Foundry 本体时，查询类型由以下 Foundry 应用针对对象集执行：

Object Explorer
Workshop
Quiver
Slate
Vertex
Foundry Rules
Foundry Machinery
对象 API（OPIs）

从以上任何来源查询本体都将消耗计算秒数来运行查询。

调查来自本体查询的 Foundry 计算用量¶

在 Foundry 中，计算秒数归属于平台中的资源，而非与这些资源交互的用户。

对于本体查询，计算归属有多种方式。一般来说，计算归属于发起查询的资源。但是，当没有用于产生计算的已保存资源（例如通过 API）时，计算将归属于被查询的对象类型。如果单个请求中查询了多个对象，则计算将在这些对象之间平均分配。

以下资源类型拥有归属于它们的本体查询计算，而非底层对象：

Workshop 应用
Carbon 页面
Quiver 分析和仪表板
Vertex 应用
Slate 应用
Foundry Machinery 应用
Foundry Rules 资源
Foundry Automate
AIP Logic
SQL Console 工作表
OSDK 应用

以下交互模式的本体查询计算直接归属于它们所查询的对象类型，因为没有固定的资源可以归属计算。

Object Explorer
对象 API（包括 OSDK）

本体查询计算（2026）¶

:::callout{theme="neutral" title="自 2026 年 1 月 1 日起生效"} 以下计算模型自 2026 年 1 月 1 日起生效，并取代下文旧版部分中描述的旧模型。 :::

本体查询计算由用户和代理（agents）对本体的使用驱动。考虑决定计算用量的主要因素：

因素 1：用户和代理数量¶

计算秒数是累积计算的。针对本体运行的查询和转换越多，总体计算用量就越高。查询量随用户交互（例如应用刷新和交互式查询）以及代理转换线性增长。

因素 2：查询类型¶

用户可以通过以下查询类型访问其本体，每种查询类型都有每次查询的最低计算秒数开销。实际计算用量可能更高，具体取决于查询复杂度和对象集的大小，或查询的对象数量。

基础查询（Base query）： 按原样返回对象集，或对某些属性进行基本筛选。
周边搜索查询（Search Around query）： 接收一个输入对象集，并根据输入集的某个属性对另一个对象集运行二次筛选。
聚合查询（Aggregation query）： 接收一个输入对象集，并对该集中所有对象的某个属性运行聚合函数（例如 sum 或 avg）。
本体 SQL 查询（Ontology SQL query）： 使用标准 Spark SQL 语法直接针对对象存储中的对象类型、链接和接口运行 SQL 查询。
高级查询（Advanced query）： 其他查询类型未涵盖的任何内容。例如，对整个对象集的嵌入向量（embeddings）应用语义搜索。
派生属性查询（Derived Property query）： 派生属性是在运行时根据对象上其他属性或链接的值计算的属性，包括对链接对象的属性进行聚合或选择。派生属性随后可用于同一请求中的进一步操作，例如筛选、排序或聚合。
操作（Actions）： 回写操作，用于替换指定对象集中对象属性的值。操作的最低开销为 18 个计算秒数，并且随编辑的对象数量而扩展，每编辑第一个对象之后的对象额外消耗 1 个计算秒数。
本体计算（Phonograph）[旧版]： 针对仍使用对象存储 V1（OSv1）后端的对象的查询。这些查询在资源管理应用中显示为"本体计算（phonograph）"。这些查询保留了现有的 OSv1 计算模型。

下表总结了每种查询类型的最低计算秒数开销。

查询类型	最低计算秒数开销
基础查询	2
周边搜索查询	5
聚合查询	5
本体 SQL 查询	5
高级查询	10
派生属性查询	10
操作	18
本体计算（Phonograph）[旧版]	16

:::callout{theme="neutral"} 对象存储 V1（OSv1）查询的现有计算模型已保留。任何针对仍使用 OSv1 后端的对象的查询，每次查询的最低计算秒数开销为 16 个计算秒数。 :::

使用本体对象查询衡量 Foundry 计算用量 [旧版]¶

:::callout{theme="neutral" title="旧版"} 以下部分描述了 2026 年 1 月 1 日之前生效的旧版计算模型。此处保留以供参考。有关当前计算模型，请参见上面的本体查询计算（2026）。 :::

在旧版模型下，查询本体消耗的计算秒数如下：

用于查询开销的固定最低计算秒数。
额外的可扩展计算秒数，由用于服务查询的计算量来衡量。

使用对象存储 V1 衡量计算用量 [旧版]¶

对象存储 V1（Phonograph）将数据存储在分布式索引集中，这些索引位于持久、水平可扩展的集群中。在这些索引中，数据位于大型数据结构中，由本体查询引擎遍历。执行查询时，引擎可以通过遍历索引来避免在搜索过程中处理大量数据。此过程称为"剪枝（pruning）"。

使用此引擎，您可以通过评估最多减少 1000 倍的记录来搜索数十亿条记录。对记录的每次物理评估称为一次"命中（hit）"。对象存储 V1 旨在最小化每次查询中的命中次数。

使用对象存储 V2 衡量计算用量 [旧版]¶

对象存储 V2（OSv2）以增强的索引格式存储对象，该格式由 Palantir 优化，用于高速索引、周边搜索和回写，以及平滑地切换到多个计算后端以完成复杂任务。这包括将完全并行化的 Spark 计算作为查询的一部分。

鉴于对象存储 V2 也使用高效的索引结构，来自对象存储 V1 的相同命中原则适用于基础查询。但是，计算秒数也可能由按需启动的 Spark 容器（作为查询的一部分）使用。

针对对象存储 V2 后端中的对象进行的查询按以下模式使用计算：

对于对象存储 V1 后端中的对象，每次查询的最低计算秒数开销为 16 个计算秒数。
对于对象存储 V2 后端中的对象，每次查询的最低计算秒数开销为 4 个计算秒数。对象存储 V2 的优化结构需要的开销少于对象存储 V1，因此具有更低的最低计算秒数开销。
当进程通过查询的剪枝过程执行计算工作时，需要额外的计算秒数。额外的计算秒数随索引中的对象数量以及查询类型而扩展。
在对象存储 V2（OSv2）中，索引剪枝同样需要额外的计算秒数。但是，OSv2 还支持在单次请求中对超过 100,000 个对象运行周边搜索，或对超过 10,000 个对象运行回写操作时，按需进行 Spark 集群搜索。这些 Spark 集群的使用方式与平台上所有其他基于 Spark 的应用相同。有关说明，请参见并行计算文档。
回写到本体的操作具有最低开销。每个操作的计算秒数开销为 18。操作还随回写请求中编辑的对象数量而扩展，每编辑第一个对象之后的对象额外消耗 1 个计算秒数。
通过对象函数（Functions on Objects）运行的函数具有最低开销。具体来说，每次函数执行都有 4 个计算秒数的固定开销。

下表总结了旧版模型下每种查询类型的最低计算秒数用量。

查询类型	最低计算秒数
本体 V1 查询	16
本体 V2 查询	4
对象操作	18
对象函数	4

理解本体查询驱动 Foundry 计算用量的因素 [旧版]¶

作为一个非常简单的规则，每次查询的固定计算用量随查询数量线性增长。执行较少的查询将总体上使用更少的计算。
对对象集服务进行更复杂的查询，例如通用的多对象搜索，将针对每个对象类型启动多个子查询。将搜索限制为单个对象类型以减少您使用的查询数量。
对较小对象集的查询将比对较大对象集的查询使用更少的计算，因为查询中的命中次数与被查询的对象集大小成正比。
在执行其他操作之前进行预先筛选将利用高度索引的后端结构。这将减少查询中的命中次数，从而降低总体计算用量。这对于聚合和周边搜索尤其重要，因为经过筛选的对象集比完整的对象集需要更少的计算来处理。