온톨로지 질의 컴퓨팅 사용량
온톨로지 질의는 객체 집합(Object set)에 필터, 집계와 링크 탐색(Link traversal)을 적용하거나 액션(Action)으로 편집하는 연산을 사용합니다. 컴퓨팅 사용량은 compute-seconds로 측정하며 사용자와 에이전트의 요청에 따라 누적됩니다.
엔터프라이즈 계약을 사용하는 경우에는 계산을 적용하기 전에 Palantir 담당자와 계약 조건을 확인합니다. 아래 값은 컴퓨팅 사용량 기준이며 금액 자체가 아닙니다.
객체 유형과 질의 대상
객체 유형(Object type)은 이름과 속성(Property) 등 의미와 구조를 정의합니다. 실제 질의는 그 유형의 전체 또는 필터링한 객체 집합에 적용됩니다. 집합 크기에는 기반 데이터와 액션으로 생성하거나 삭제한 객체가 반영됩니다.
Object Explorer, Workshop, Quiver, Slate, Vertex, Foundry Rules, Foundry Machinery와 Object APIs(OPIs) 등에서 온톨로지를 조회하면 연산 사용량이 발생합니다.
사용량 귀속
사용량은 작업한 사용자보다 질의를 발생시킨 리소스에 귀속합니다. 저장된 발생 리소스가 없으면 조회한 객체 유형에 귀속하고, 한 요청에서 여러 유형을 조회하면 그 유형들에 균등하게 나눕니다.
| 발생 위치 | 귀속 대상 |
|---|---|
| Workshop 애플리케이션 | 해당 애플리케이션 |
| Carbon 페이지 | 해당 페이지 |
| Quiver 분석과 대시보드 | 해당 분석 또는 대시보드 |
| Vertex 애플리케이션 | 해당 애플리케이션 |
| Slate 애플리케이션 | 해당 애플리케이션 |
| Foundry Machinery 애플리케이션 | 해당 애플리케이션 |
| Foundry Rules | 해당 리소스 |
| Foundry Automate | 해당 리소스 |
| AIP Logic | 해당 리소스 |
| SQL Console 워크시트 | 해당 워크시트 |
| 저장된 OSDK 애플리케이션 | 해당 애플리케이션 |
| Object Explorer | 조회한 객체 유형 |
| 별도 발생 리소스가 없는 Object API 및 직접 OSDK 호출 | 조회한 객체 유형 |
OSDK를 사용한다는 사실만으로 귀속 대상이 정해지는 것은 아닙니다. 저장된 앱의 요청인지 직접 API 요청인지 구분합니다.
2026년 계산 모형
다음 모형은 2026년 1월 1일부터 적용합니다. 같은 종류의 질의를 반복하면 최소 오버헤드는 요청 수에 비례하여 누적됩니다. 앱 새로 고침, 대화형 조회와 에이전트 작업이 요청 수에 영향을 줍니다.
| 질의 종류 | 동작 | 요청당 최소 compute-seconds |
|---|---|---|
| Base query | 객체 집합을 그대로 반환하거나 기본 속성 필터 적용 | 2 |
| Search Around query | 입력 집합의 속성 및 링크를 이용해 연결된 다른 객체 집합 탐색 | 5 |
| Aggregation query | 집합의 속성에 sum, avg 등 집계 적용 | 5 |
| Ontology SQL query | 객체 유형, 링크와 인터페이스를 SQL로 조회 | 5 |
| Advanced query | 다른 종류에 포함되지 않는 연산, 예를 들어 임베딩의 의미 기반 검색 | 10 |
| Derived Property query | 조회 시 파생 속성을 계산하고 같은 요청에서 추가 필터, 정렬이나 집계에 사용 | 10 |
| Actions | 객체 편집 적용 | 18 |
| Ontology Compute (Phonograph), 구형 항목 | Object Storage V1 조회의 별도 기준 | 16 |
실제 사용량은 질의 복잡도와 대상 객체 수에 따라 더 커질 수 있습니다. 액션은 첫 편집 객체 이후 객체 하나당 1 compute-second를 추가합니다. 예를 들어 N개 객체를 편집하고 N이 1 이상이면 기본 부분은 18 + (N - 1)입니다.
Ontology SQL과 파생 속성도 각 연산의 실행 경로 및 대상 규모에 따라 추가 사용량이 발생할 수 있습니다.
Object Storage V1(Phonograph)의 지정된 지원 종료일은 2026년 6월 30일입니다. V1의 16 compute-seconds 항목은 구형 리소스와 사용 내역을 해석할 때 구분하며 새 구성은 Object Storage V2를 사용합니다.
2026년 이전 사용량 대조
이전 모형은 요청당 고정 최소 사용량에 실제 계산량에 따른 사용량을 더했습니다. 아래 값으로 현재 V2의 질의별 최소값을 대체하지 않습니다.
| 구형 항목 | 최소 compute-seconds |
|---|---|
| Ontology V1 query | 16 |
| Ontology V2 query | 4 |
| Action on Objects | 18 |
| Function on Objects | 4 |
V1의 분산 인덱스는 가지치기(Pruning)로 확인할 자료를 줄였습니다. 수십억 레코드에서도 실제 평가 대상을 최대 1000분의 1 수준까지 줄일 수 있는 방식이며, 실제로 평가한 레코드 한 건을 hit라고 부릅니다.
V2도 기본 질의에서 인덱스와 hit 개념을 사용하고 복잡한 작업은 별도 Spark 연산과 결합합니다. 이전 모형에서는 100,000개를 넘는 Search Around와 한 요청의 10,000개 초과 쓰기 반영에 필요한 주문형 Spark 클러스터의 사용량도 병렬 컴퓨팅으로 계산했습니다. 이 수치는 이전 계산 모형의 실행 설명이며 현재 작업별 한도는 질의 제한과 해당 액션 조건을 따릅니다.
요청량과 대상 규모 관리
필요 없는 반복 조회를 줄이면 고정 오버헤드를 줄일 수 있습니다. 여러 유형을 일반 검색하면 유형별 하위 질의가 생길 수 있으므로 대상 유형을 알고 있다면 그 유형으로 범위를 제한합니다.
집계와 Search Around 전에 기본 속성으로 필터링하면 인덱스를 활용하여 평가할 객체를 줄일 수 있습니다. 같은 목적의 질의라면 더 작은 후보 집합을 사용하도록 구성합니다. 함수와 Automate의 실행 빈도 및 질의 구성도 전체 사용량에 영향을 줍니다.