딥러닝과 대규모 언어 모델(LLM)의 확산으로 인해 고성능 컴퓨팅의 중심이 GPU로 이동하고 있지만, RDF(Resource Description Framework) 데이터 처리와 SPARQL 쿼리 실행 영역에서는 여전히 CPU의 성능과 대규모 메모리 아키텍처가 시스템의 효율성을 결정짓는 핵심 요소입니다.
1. RDF 처리의 특성: 랜덤 액세스 패턴
GPU가 빛을 발하는 영역은 대규모 병렬 연산입니다. 정형화된 데이터를 대상으로 동일한 연산을 수천 개의 데이터에 동시에 적용하는 작업에서는 GPU가 압도적입니다. 그러나 RDF와 그래프 데이터베이스는 데이터 간의 연결을 따라가는 비정형적인 탐색이 주를 이루므로 성격이 근본적으로 다릅니다.
그래프 탐색의 본질
RDF 데이터는 트리플(Subject-Predicate-Object) 형태로 저장되어 거대한 그래프를 형성합니다. SPARQL 쿼리를 실행한다는 것은 이 그래프를 탐색(Traversal)하는 것입니다.
문제는 그래프 탐색이 랜덤 액세스 패턴을 따른다는 점입니다. A 노드에서 B 노드로, B에서 또 다른 C 노드로 점프하는 과정에서 메모리 접근이 예측 불가능하게 분산됩니다. GPU는 순차적이고 예측 가능한 메모리 접근에 최적화되어 있어, 이러한 랜덤 패턴에서는 오히려 비효율적입니다 [1].
2. 메모리 용량의 결정적 차이
GPU 메모리의 한계
RDF 트리플 스토어는 효율적인 쿼리를 위해 다중 인덱스를 유지합니다. 기본 트리플 구조(S, P, O)에서는 6가지 순열(SPO, SOP, PSO, POS, OSP, OPS)이 가능하지만, 네임드 그래프(Named Graph)를 포함하는 쿼드(Quad) 구조(G, S, P, O)로 확장되면 상황은 훨씬 복잡해집니다.
이론적으로 4개의 요소는 총 24가지(4!)의 순열을 가질 수 있으며, 실무적인 성능을 위해 GSPO, GPOS, GOSP, SPOG, GSOP 등 주요 접근 패턴에 대한 인덱스를 중복해서 생성합니다 [2]. 여기에 문자열을 ID로 변환하는 딕셔너리 인코딩 구조까지 포함하면, 전체 인덱스 크기는 원본 데이터 대비 5~10배 이상으로 증폭됩니다.
NVIDIA H100도 80GB 정도의 메모리를 가지고 있습니다. 반면, 서버급 CPU 시스템은 수백 GB에서 TB 단위의 메모리를 장착할 수 있습니다. 수십억 개의 트리플을 처리할 때 이 거대한 데이터를 80GB 내외의 GPU 메모리에 담는 것은 구조적으로 한계가 있습니다.
대규모 Knowledge Graph(예: Wikidata, DBpedia)를 다룬다면, GPU 메모리에 전체 그래프를 올리는 것 자체가 불가능합니다. “필요한 부분만 디스크에서 읽어오면 되지 않느냐”고 생각할 수 있지만, 앞서 언급한 랜덤 액세스 특성 때문에 인덱스의 일부만 메모리에 올리는 방식은 I/O 병목 현상을 극심하게 유발합니다. 결국 고성능 SPARQL 엔진은 전체 인덱스를 메모리에 상주시키는 ‘In-memory’ 방식을 선호하게 되는데, GPU는 이 지점에서 메모리 용량이라는 물리적 한계에 부딪히게 됩니다.
CPU-GPU 데이터 전송 오버헤드
GPU를 사용하더라도 데이터는 CPU 메모리에서 GPU 메모리로 PCIe 버스를 통해 전송되어야 합니다. 이 전송 오버헤드가 실제 연산 시간보다 길어지는 경우가 많습니다 [3].
특히 SPARQL 쿼리가 그래프의 다양한 영역을 탐색해야 할 때, 필요한 데이터를 GPU로 계속 옮겨야 하므로 GPU 연산의 이점이 상쇄됩니다.
3. SPARQL 쿼리 처리의 CPU 친화적 특성
조인 연산과 쿼리 최적화
SPARQL 쿼리의 핵심은 트리플 패턴 매칭과 이를 연결하는 조인(Join) 연산입니다. 일반적인 SQL 조인이 미리 정의된 외래 키(Foreign Key)를 따라 테이블을 결합하는 방식이라면, SPARQL의 조인은 쿼리 실행 시점에 공유 변수(Variable)를 매개로 그래프 패턴을 확장해 나가는 과정입니다. 복잡한 쿼리는 수십 개의 트리플 패턴을 조인해야 하며, 이때 데이터의 카디널리티(Cardinality, 특정 패턴에 매칭되는 결과의 수)를 예측하여 최적의 조인 순서를 결정하는 것이 성능에 결정적입니다 [4].
쿼리 최적화(Query Optimization)는 본질적으로 순차적이고 복잡한 의사결정 과정입니다. 각 단계의 결과가 다음 단계의 입력이 되므로, GPU의 병렬 처리 능력을 활용하기 어렵습니다. 현대의 고성능 CPU가 제공하는 브랜치 예측(Branch Prediction)과 캐시 최적화가 훨씬 효과적입니다.
추론(Reasoning)의 복잡성
RDF의 강점 중 하나는 온톨로지 기반 추론(Reasoning)입니다. OWL이나 RDFS 시맨틱스에 따라 암시적 지식을 도출하는 과정은 논리적 규칙의 반복 적용을 필요로 합니다 [5].
이 과정은 GPU가 잘하는 “같은 연산의 대량 반복”이 아니라, “조건에 따른 분기가 빈번한 복잡한 로직”입니다. CPU의 복잡한 명령 파이프라인과 분기 예측이 이런 워크로드에 훨씬 적합합니다.
4. 실무적 권장사항
메모리: 다다익선
인메모리 트리플 스토어(예: Apache Jena, GraphDB)를 사용한다면, 메모리야말로 성능의 핵심입니다. 전체 그래프와 인덱스를 메모리에 올릴 수 있다면 쿼리 응답 시간이 극적으로 개선됩니다.
권장사항:
- 중소 규모(수천만 트리플): 64GB 이상
- 대규모(수억 트리플): 256GB 이상
- 엔터프라이즈급(십억 트리플 이상): 1TB 이상 또는 분산 클러스터
CPU: 코어 수보다 단일 코어 성능
많은 분들이 코어 수가 많은 CPU를 선택하지만, SPARQL 쿼리 대부분은 단일 쿼리 단위로 처리됩니다. 동시에 수십 개의 쿼리를 처리해야 하는 경우가 아니라면, 높은 클럭 속도와 큰 L3 캐시를 가진 CPU가 더 효과적입니다.
권장사항:
- 대형 L3 캐시(64MB 이상)를 가진 서버급 CPU
- 메모리 대역폭이 높은 DDR5 지원 플랫폼
- 단일 코어 성능이 중요하므로 무조건적인 코어 수 늘리기는 비효율적
GPU는 특수한 경우에만
물론 GPU가 유리한 RDF 관련 작업도 있습니다:
- 그래프 임베딩 학습 (Knowledge Graph Embedding)
- 대규모 유사도 계산 (Entity Matching)
- 대규모 병렬 조인: 일반적인 SPARQL 조인과 달리, 데이터가 정형화되어 있고 수백만 개의 트리플을 동시에 결합해야 하는 특정 분석용 쿼리(예: 대규모 해시 조인)에서는 GPU의 SIMD(Single Instruction, Multiple Data) 연산이 성능을 높일 수 있습니다 [6].
하지만 다시 강조하지만, 일반적인 SPARQL 쿼리 서빙과 추론에서는 CPU와 메모리 투자가 훨씬 효율적입니다.
5. 결론
RDF 처리 시스템을 구축할 때, GPU 카드를 구매하기 전에 먼저 질문해야 합니다:
“메모리는 충분한가? CPU는 적절한가?”
그래프 데이터의 랜덤 액세스 패턴, 메모리 집약적 인덱싱, 복잡한 추론 로직이라는 세 가지 특성이 CPU와 메모리를 핵심 병목으로 만듭니다. 예산이 한정되어 있다면, 고성능 GPU보다 더 많은 메모리와 캐시가 큰 CPU에 투자하는 것이 현명한 선택입니다.
딥러닝 시대에 GPU가 만능처럼 느껴지지만, 모든 문제가 행렬 연산은 아닙니다. 문제의 본질을 이해하고 그에 맞는 하드웨어를 선택하는 것이야말로 엔지니어의 역할입니다.
참고문헌
- [1]S. Beamer, K. Asanovic, and D. Patterson, “Direction-Optimizing Breadth-First Search,” in 2012 International Conference on High Performance Computing, Networking, Storage and Analysis (SC), IEEE, 2012, pp. 1–10.
- [2]M. Atre, V. Chaoji, M. J. Zaki, and J. A. Hendler, “Matrix ‘Bit’ loaded: a scalable lightweight join query processor for RDF data,” Proceedings of the 19th International Conference on World Wide Web (WWW), pp. 41–50, 2010.
- [3]C. Chantrapornchai and C. Choksuchat, “GPU-based SPARQL Query Processing,” Walailak Journal of Science and Technology, vol. 15, no. 7, pp. 521–537, 2018.
- [4]A. Hogan and others, “Knowledge Graphs,” ACM Computing Surveys, vol. 54, no. 4, pp. 1–37, 2021.
- [5]Ontotext, “What is RDF Reasoning?” 2024. Available at: https://www.ontotext.com/knowledgehub/fundamentals/what-is-rdf-reasoning/
- [6]P. Yuan, P. Liu, J. Zhai, L. Wu, H. Liu, and H. Jin, “TripleBit: A Fast and Compact System for Large Scale RDF Data,” in Proceedings of the VLDB Endowment, 2013, pp. 517–528.
Comments