コンピュート使用量：オントロジーインデックス化

Foundry のオントロジーは、オブジェクトを高速アクセスに最適化されたストレージ形式であるオントロジーインデックスに保存します。Foundry データセット内のデータは任意のサイズや形式であるため、データセットのデータをオントロジーインデックスに保存するためのデータ変換が必要となります。このプロセスはオントロジーインデックス化と呼ばれ、任意のサイズのデータセットとオブジェクトに適用できます。オントロジーインデックス化の処理コストは、コンピュート秒で測定されます。このドキュメンテーションでは、オントロジーインデックス化がコンピュートをどのように使用するか、およびコンピュート使用量をどのように管理するかについて説明します。

オントロジーインデックス化からのコンピュート使用量の測定

オントロジーインデックス化は、並列化されたSparkバックエンドを使用して、任意の大きさのデータセットを読み込み、それらをオントロジー形式に変換します。インデックス化ジョブを実行するために使用されるコンピュートの量は、使用される計算リソース（ドライバーとエグゼキューター）の量と、インデックス化ジョブ自体の全体的な壁掛け時間に基づいています。

Spark使用量がどのようにコンピュート秒に変換されるかについての詳細は、主要な 使用タイプ のドキュメンテーションを参照してください。以下では、オントロジーインデックス化によって使用されるコンピュート秒の計算例を見つけることができます。

オントロジーインデックス化からの使用量の調査

オントロジーインデックス化ジョブは Foundry の Builds アプリケーションで公開され、インデックス化されているオブジェクトに関連付けられています。オントロジーインデックス化ジョブは Spark ジョブであり、並列化されたバッチコンピュートとして分類されるため、Code Repositories の変換や Contour のクエリなど、同じバックエンド上の他のジョブと同じ方法で測定することができます。

インデックス化ジョブは、それらがトリガーされる方法に基づいてカテゴライズすることができます。

• オントロジーインデックス化ジョブはデータセットをオントロジーバックエンドにインデックス化します。このコンピュートは、データセットからインデックス化されたオブジェクトを生成するために使用されます。
• オントロジー出力ジョブは、オントロジー内で直接行われた編集を Foundry の変換フレームワーク内のデータセットに永続化します。これらのジョブは通常、オントロジー出力ジョブが主に編集を扱っているため、全オブジェクトセットの厳格なサブセットであるため、完全なインデックス化ジョブよりも小さい傾向があります。

オントロジーインデックス化の使用量の要因

オントロジーインデックス化ジョブは、インデックス化する必要があるすべてのデータを読み込み、それをオントロジーバックエンドが迅速に保存、検索、編集できる形式に変換する必要があります。

データの読み取りとインデックス化時のコンピュート使用量は、以下の要素によって引き起こされます：

• オブジェクトごとのレコード数
  • インデックス化されるデータセット内のレコード数が増えると、オブジェクトの数も増えます。各オブジェクトはインデックス化のために一定数の計算操作を必要とするため、オブジェクトの数を増やすと、インデックス化のためのコンピュート使用量が増えます。
• オブジェクトごとのプロパティ数
  • 各オブジェクトの各プロパティは、インデックス化ジョブによって個別に分析され、その後オブジェクトインデックスに書き込まれる必要があります。分析およびインデックス化するプロパティが多い場合、コンピュートの使用量が増えます。
• 各プロパティのサイズ
  • 一部のプロパティは他のものよりも大きいです。例えば、多くの内容を含むテキストプロパティは、単純な数値プロパティよりも多くのスペースとコンピュートを分析するために必要とします。より大きく、より複雑なプロパティタイプを持つオブジェクトは、インデックス化するためのコンピュートがより多く必要となります。

インデックス化の頻度も、オントロジーの更新に使用されるコンピュートの量に大きな影響を与えます。上流のデータセットに設定されたスケジュールは、オブジェクトの自動再インデックス化をトリガーします。オブジェクトを最新の状態に保つための使用量の含意を調べるときは、そのオブジェクトとその上流のデータセットに対する更新スケジュールを考慮に入れてください。

オントロジーインデックス化のコンピュート管理

オントロジーインデックス化ジョブは最適化してコンピュート使用量を減らすことが可能です。最適化の最初の方法であり最も簡単な方法は、インデックスの入力データのサイズを減らすことで、ジョブを完了するために必要な作業量を減らすことです。これには、可能な場合に以下のことを行うことが含まれます：

• 入力レコード数の管理
• オブジェクトごとのプロパティ数の管理
• オブジェクトごとの各プロパティのサイズの管理

別の最適化方法は、オントロジーインデックスジョブをインデックス化のためのチェンジログ戦略を使用するように設定することです。チェンジログインデックス化は、ジョブを実行する前に既存のオブジェクトと比較することで、作成または更新する必要があるオブジェクトの数を大幅に減らします。チェンジログインデックス化にはより多くの設定と更新戦略への準拠が必要ですが、パフォーマンスと効率性の向上をもたらすことができます。

インデックス化コンピュート計算の例

インデックス化ジョブは並列化されたSparkジョブの形を取り、Buildsアプリケーションで見ることができます。以下にインデックス化ジョブの例を示します。オントロジーインデックス化ジョブは、ジョブのサイズに応じて、インデックス化ジョブのドライバーとエグゼキューターのサイズを自動的に選択することに注意してください。

Driver:
    num_vcpu: 1
    GiB_RAM: 6
Executors:
    num_vcpu: 1
    GiB_RAM: 4
    num_executors: 2
Total Runtime: 10 seconds

Calculation: 

# ドライバーの計算時間を計算する
driver_compute_seconds = max(num_vcpu, GiB_RAM / 7.5) * runtime_in_seconds
                       = max(1vcpu, 6GiB / 7.5) * 10sec
                       = 1 * 10 = 10 compute-seconds

# エグゼキュータの計算時間を計算する
executor_compute_seconds = max(num_vcpu, GiB_RAM / 7.5) * num_executors * runtime_in_seconds
                         = max(1vcpu, 4GiB / 7.5) * 2executors * 10sec
                         = 1 * 2 * 10 = 20 compute-seconds

# 合計の計算時間を計算する
total_compute_seconds = driver_commpute_seconds + exeucutor_compute_seconds
                      = 10 compute-seconds + 20 compute-seconds
                      = 30 compute-seconds