注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
Foundry Ontology是一个数据后台，将基于文件的数据映射到以组织为中心的Object，并为数据探索、数据分析、操作数据编辑、场景分析等提供高速查询服务。Ontology将数据存储在多模态存储后端中，每个后端都有其自己的用途，并可以在单个请求中灵活查询。查询Foundry Ontology需要了解一些基础概念，下面将讨论这些概念。
如果您与Palantir签订了企业合同，请在进行计算使用量计算之前联系您的Palantir代表。
第一个重要概念是object类型及其对应的对象集之间的区别。object类型是实体本身的语义表示（例如Object的名称和属性）。
一个object类型有一个对应的对象集，其中包含Objects本身。对象集的大小对应于传入数据集的行数以及Ontology操作创建和删除的Objects数量。
第二个重要概念是查询类型的概念，包括筛选、聚合、搜索范围和数据输出操作。每种查询类型都需要计算来执行。
sum或avg）。在使用Foundry Ontology时，查询类型通过以下Foundry应用程序对对象集执行：
从这些来源中的任何一个查询Ontology将使用计算秒来运行查询，如下所示：
Object Storage V1（Phonograph）在耐用的、水平可扩展的集群中存储在分布式索引集中。 在这些索引中，数据位于大型数据结构中，由Ontology查询引擎遍历。执行查询时，引擎可以通过遍历索引来避免在搜索过程中处理大量数据。此过程称为"剪枝"。
使用此引擎，您可以通过评估最多1000倍更少的记录来搜索数十亿条记录。每次对记录的物理评估称为"命中"。Object Storage V1旨在将每次查询中的命中次数降到最低。
Object Storage V2（OSv2）以Palantir优化的增强索引格式存储Objects，以实现高速索引、搜索范围和数据输出，以及顺利地与多个计算后端进行交接以完成复杂任务。这包括作为查询一部分的完全并行化Spark计算。
鉴于Object Storage V2也使用高效的索引结构，与Object Storage V1的命中原则相同适用于基本查询。然而，按需Spark容器也可用在查询过程中旋转。
对Object Storage V2后端中的Objects进行的查询按以下模式使用计算：
16计算秒开销。4计算秒开销。Object Storage V2的优化结构需要的开销比Object Storage V1少，因此固定计算秒开销减少。18计算秒开销。操作也随着在写回请求中编辑的Objects数量进行扩展，每多编辑一个Object实例则额外增加1计算秒。4计算秒开销。下表总结了每种查询类型的最低计算秒使用情况。
| 查询类型 | 最低计算秒 |
|---|---|
| Ontology V1查询 | 16 |
| Ontology V2查询 | 4 |
| Objects上操作 | 18 |
| Objects上函数 | 4 |
在Foundry中，计算秒被归因于平台中的资源，而不是与这些资源交互的用户。
当涉及到Ontology查询时，有多种方式可以归因于计算。作为一般规则，计算附加到查询来源的资源。然而，当没有用于生成计算的已保存资源（例如通过API）时，计算将附加到被查询的object类型。如果在单个请求中查询多个Objects，则通过在Objects之间平均分配来归因于计算。
以下资源类型的Ontology查询计算归因于它们，而不是底层Objects：
以下交互模式的Ontology查询计算直接附加到它们查询的object类型上，因为没有可以附加计算的固定资源。