注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry オントロジーは、ファイルベースのデータを組織中心のオブジェクトにマッピングし、データ探索、データ分析、運用データの編集、シナリオ分析などのために高速なクエリを提供するデータバックエンドです。オントロジーは、それぞれに用途が異なるマルチモーダルなストレージバックエンドにデータを保存し、単一のリクエストで柔軟にクエリできます。Foundry オントロジーに対してクエリを実行するには、以下で説明する基本的な概念を理解する必要があります。
Palantir とエンタープライズ契約を締結している場合は、コンピュート使用量の計算に進む前に、Palantir の担当者にお問い合わせください。
最初の重要な概念は、オブジェクトタイプとそれに対応するオブジェクトセットの違いです。オブジェクトタイプは、エンティティ自体を意味的に表現したものです（オブジェクトの名前やプロパティなど）。
オブジェクトタイプには、オブジェクト自体を含むオブジェクトセットが対応しています。オブジェクトセットのサイズは、入力データセットの行数と、オントロジーアクションによって作成および削除されたオブジェクトの数に対応します。
2つ目の重要な概念は、フィルター、集計、関連検索、ライトバック操作を含むクエリの種類です。どの種類のクエリも、実行にはコンピュートが必要です。クエリの種類ごとの現在のコンピュート秒のオーバーヘッドについては、オントロジークエリのコンピュート（2026年）を参照してください。
Foundry オントロジーを使用する際、以下の Foundry アプリケーションによって、オブジェクトセットに対して各種類のクエリが実行されます。
これらのいずれのソースからオントロジーに対してクエリを実行しても、クエリの実行にコンピュート秒が使用されます。
Foundry では、コンピュート秒はリソースを操作しているユーザーではなく、プラットフォーム内のリソースに帰属します。
オントロジークエリでは、コンピュートの帰属方法が複数あります。原則として、コンピュートはクエリの発生元のリソースに紐付けられます。ただし、コンピュートを発生させるために使用される保存済みリソースがない場合（API 経由の場合など）、コンピュートはクエリ対象のオブジェクトタイプに紐付けられます。単一のリクエストで複数のオブジェクトに対してクエリが実行される場合、コンピュートはオブジェクト間で均等に分割して帰属させられます。
以下のリソースの種類では、オントロジークエリのコンピュートは基盤となるオブジェクトではなく、リソースに帰属します。
以下のインタラクションパターンでは、コンピュートを紐付ける特定のリソースがないため、オントロジークエリのコンピュートはクエリ対象のオブジェクトタイプに直接紐付けられます。
以下のコンピュートモデルは2026年1月1日から適用され、後述のレガシーセクションで説明するレガシーモデルに置き換わります。
オントロジークエリのコンピュートは、ユーザーとエージェントによるオントロジーの使用によって発生します。コンピュート使用量を決める主要な要因を確認します。
コンピュート秒は累積で測定されます。オントロジーに対して実行されるクエリと変換が多いほど、全体のコンピュート使用量は増加します。クエリ量は、アプリケーションの更新や対話型クエリなどのユーザーインタラクション、およびエージェントによる変換に応じて線形に増加します。
ユーザーは、以下の種類のクエリを通じてオントロジーにアクセスできます。それぞれの種類には、クエリあたりのコンピュート秒の最小オーバーヘッドが設定されています。実際のコンピュート使用量は、クエリの複雑さやオブジェクトセットのサイズ、またはクエリ対象のオブジェクト数によって、それよりも多くなる場合があります。
sum や avg など）を実行します。18 コンピュート秒で、編集されるオブジェクト数に応じて増加し、最初の1個を超えて編集されるオブジェクト1個につき 1 コンピュート秒が追加で発生します。以下のテーブルは、クエリの種類ごとのコンピュート秒の最小オーバーヘッドをまとめたものです。
| クエリの種類 | コンピュート秒の最小オーバーヘッド |
|---|---|
| 基本クエリ | 2 |
| 関連検索クエリ | 5 |
| 集計クエリ | 5 |
| オントロジー SQL クエリ | 5 |
| 高度なクエリ | 10 |
| 派生プロパティクエリ | 10 |
| アクション | 18 |
| オントロジーコンピュート（Phonograph）［レガシー］ | 16 |
Object Storage v1（OSv1）クエリの既存のコンピュートモデルは維持されています。OSv1 バックエンドを引き続き使用しているオブジェクトに対するクエリには、クエリあたり 16 コンピュート秒の最小オーバーヘッドが発生します。
以下のセクションでは、2026年1月1日より前に適用されていたレガシーのコンピュートモデルについて説明します。参照用として保持されています。現在のコンピュートモデルについては、上記のオントロジークエリのコンピュート（2026）を参照してください。
レガシーモデルでは、オントロジーへのクエリで次のようにコンピュート秒が使用されます。
Object Storage v1（Phonograph）は、耐久性があり、水平スケーリング可能なクラスター内の分散インデックスにデータを格納します。これらのインデックスでは、データは大規模なデータ構造内に格納され、オントロジークエリエンジンがその構造を走査します。クエリの実行時に、エンジンはインデックスを走査することで、検索中に大量のデータを処理せずに済みます。このプロセスは「プルーニング」と呼ばれます。
このエンジンを使用すると、評価するレコード数を最大で1000分の1に抑えながら、数十億件のレコードを検索できます。レコードに対する物理的な評価の1回1回を「ヒット」と呼びます。Object Storage v1 は、クエリごとのヒット数を最小限に抑えるように設計されています。
Object Storage v2（OSv2）は、Palantir が高速なインデックス化、関連検索、ライトバックに加え、複雑なタスクを実行するための複数のコンピュートバックエンドへの円滑な引き継ぎに最適化した、高度なインデックス形式でオブジェクトを格納します。これには、クエリの一部として完全に並列化された Spark コンピュートを組み合わせて使用することも含まれます。
Object Storage v2 も効率的なインデックス構造を使用するため、基本的なクエリには Object Storage v1 と同じヒットの原則が適用されます。ただし、クエリの一部として起動されるオンデマンドの Spark コンテナでも、コンピュート秒が使用される場合があります。
Object Storage v2 バックエンド内のオブジェクトに対するクエリでは、次のようにコンピュートが使用されます。
16 コンピュート秒のオーバーヘッドが発生します。4 コンピュート秒のオーバーヘッドが発生します。Object Storage v2 の最適化された構造では、Object Storage v1 よりもオーバーヘッドが少ないため、最小コンピュート秒のオーバーヘッドも小さくなっています。18 コンピュート秒のオーバーヘッドが発生します。また、アクションの使用量はライトバックリクエストで編集されるオブジェクト数に応じて増加し、2個目以降は、編集されるオブジェクト1個につき追加で 1 コンピュート秒が発生します。4 コンピュート秒の固定オーバーヘッドが発生します。以下のテーブルは、レガシーモデルにおけるクエリの種類ごとの最小コンピュート秒使用量をまとめたものです。
| クエリの種類 | 最小コンピュート秒 |
|---|---|
| オントロジー V1 クエリ | 16 |
| オントロジー V2 クエリ | 4 |
| オブジェクトに対するアクション | 18 |
| オブジェクトに対する関数 | 4 |
コンピュート使用量を最小限に抑える、効率的な関数の作成と Automate の設定に関するベストプラクティスについては、以下を参照してください。