Neo4j: 합리적인 RDF 그래프 데이터베이스 & 추론 엔진 활용기

[커뮤니티 콘텐츠로서 본 게시물은 특정 작성자의 견해와 의견을 반영한 것으로, Neo4j의 공식적인 입장이 반드시 반영되는 것은 아닙니다.]

Neo4j가 RDF를 로드하고 작성할 수 있다는 건 널리 알려져 있죠. 지금까지 RDF(특히 OWL) 추론은 완전한 기능을 갖춘 트리플 스토어 또는 전용 추론 엔진에만 적용되었는데요. 이 게시물에서는 Neo4j가 RDF, RDFS 및 OWL 2 RL을 위한 매우 표현력이 뛰어나고 경쟁이 치열한 추론 엔진을 제공하기 위해 고유한 추론 기술로 확장될 수 있다는 것을 보여줄 거예요. 접근 방식을 간략하게 설명하고 몇 가지 벤치마크 결과를 제공해 드릴게요.

레이블이 있는 Property Graph(LPG)와 리소스 설명 프레임워크(RDF)에는 공통점이 있어요. 둘 다 데이터를 그래프로 표현하죠. 최근에는 한 형식을 다른 형식으로 변환하는 방법이 있다는 건 놀라운 일이 아닐 거예요. Neo4j의 Jesús Barrasa가 Thomson Reuters PermID RDF 데이터 세트의 경우를 훌륭하게 보여줬죠.

굳이 LPG와 RDF의 차이점을 따지자면, 스키마 정보와 그래프 추론을 표현하는 다양한 능력을 고려해야 할 거예요.

Neo4j 2.0에서는 그래프의 경량 유형 스키마를 선택적으로 인코딩하기 위해 `Node`를 입력하기 위한 `Node` 레이블이 도입되었어요. 광범위하게 말하면, RDF 스키마(RDFS)는 이러한 접근 방식을 보다 공식적으로 확장한 것이라고 할 수 있죠. RDFS를 사용하면 `Node`의 레이블을 구조화할 수 있는데, 이를 RDF에서는 *수업*이라고 해요. 그리고 계층의 `Relationship`(속성이라고 함)도 정의할 수 있죠. 또한 OWL(Web Ontology Language)은 규칙과 유사한 조건을 표현하여 `Node` 레이블이나 `Relationship`과 같은 새로운 사실을 자동으로 도출하는 언어를 제공한답니다.

추론은 지식으로 데이터를 강화해요

규칙과 OWL 추론의 세계를 빠르게 살펴보기 위해 매우 인기 있는 LUBM 벤치마크(리하이대학교 벤치마크)를 예시로 들어볼게요.

이 벤치마크는 가상의 대학 영역에서 인위적으로 생성된 그래프 데이터로 구성되어 있으며, 사람, 학과, 강좌 등을 다루고 있어요. 예를 들어, 학생이 어떤 강좌를 수강하면 참석자로 파생되므로 다음과 같은 존재론적 규칙을 만족해야 하죠.

Student and (takesCourse some) SubClassOf Attendee

이 규칙은 LPG 용어로 번역될 때 다음과 같이 읽어야 해요. Student 레이블이 있는 모든 Node가 takesCourse Relationship과 연결되어 다른 Node에 연결되면 Attendee 레이블을 받게 된다는 거죠. 숙련된 Neo4j 프로그래머라면 이 규칙이 다음과 같이 간단하게 Cypher 표현으로 해석될 수 있으므로 손을 대지 못할 수도 있어요. 사이퍼 표현:

match (x:Student)-[:takesCourse]->()
set x:Attendee

이건 완벽하게 가능하지만, 서로 종속될 수 있는 깊게 중첩된 규칙의 경우 번거로울 수 있어요. 예를 들어 Cypher 표현식은 Student의 하위 클래스인 UndergraduateStudent 같은 것들을 놓칠 수 있죠. 따라서 엄밀히 말하면 위의 표현은 다음과 같아야 해요.

match (x)-[:takesCourse]->() where x:Student or x:UndergraduateStudent
set x:Attendee

Protégé와 같은 온톨로지 편집기와 이를 실행하는 OWL 추론 엔진의 지원을 통해 이러한 도메인 지식을 온톨로지 규칙으로 인코딩하는 것이 훨씬 더 편리해요.

RDFS/OWL의 또 다른 좋은 점은 그러한 지식을 모델링하는 것이 매우 선언적인 수준에 있다는 것이에요. W3C에 의해 표준화되었으니까요. 또한 OWL 언어는 건전성 및 완전성과 같은 몇 가지 중요한 속성을 갖고 있어요.

예를 들어, 비종료 규칙 세트를 정의할 수 없으며 추론을 통해 충돌하는 규칙이 즉시 식별돼요. OWL 2 RL의 경우 그래프의 크기에 따라 모든 도출 가능한 사실을 다항식 시간(이론적으로 최악의 경우)으로 도출할 수 있음이 더욱 보장되죠.

실제로 성능은 물론 많이 달라질 수 있어요. 우리의 경우 Attendee를 예로 들면, 추론기는 삼중 저장 규칙 엔진이든 Cypher 엔진이든 관계없이 Student 레이블이 있는 그래프 Node를 반복해야 하고 takesCourse Relationship을 확인해야 해요.

성능을 조정하려면 전용 Index를 사용하여 특정 Relationship(각 Relationship 정도) 또는 레이블이 있는 Node를 효과적으로 선택하고 저장 프로시저를 사용할 수 있어요. 결국 이는 확장이 잘 되지 않는 것 같아요. 데이터를 두 배로 늘리면 그래프 읽기 및 쓰기 양을 두 배로 늘려 해당 규칙의 결과를 계산하니까요.

좋은 소식은 이것이 이야기의 끝이 아니라는 거예요.

그래프 저장을 위한 효율적인 추론

GraphScale이라는 기술이 있는데, 이는 확장 가능한 OWL 추론으로 Neo4j를 강화해줘요. 이 접근 방식은 메모리 내 추론에 적합한 그래프의 간결한 표현을 구축하는 추상화 개선 기술을 기반으로 하죠. 그런 다음 추론 결과는 기본 그래프 저장소로 다시 점진적으로 전파돼요.

GraphScale의 기본 아이디어는 그래프 내의 엔터티가 유사한 구조를 갖는 경우가 많다는 관찰을 기반으로 해요. GraphScale 접근 방식은 이러한 유사성을 활용하고 추상화라고 하는 원본 데이터의 압축된 버전을 계산하죠.

이 추상화는 잘 정의된 논리적 기준에 따라 유사한 구조를 공유하는 Node의 등가 그룹을 기반으로 해요. 이 기술은 RDF, RDFS 및 OWL 2 RL 모두에 대해 건전하고 완벽한 것으로 입증되었어요.

접근 방식에 대한 직관적인 아이디어는 다음과 같아요. 위 그래프를 Neo4j의 대학 도메인에 대한 원본 데이터의 일부로 생각해 보세요. 오른쪽에는 최소한 일부 과정을 수강하는 학부생이 간략하게 표현되어 있죠.

본질적으로 해당 학생이 참석자라는 파생 사실은 원본 그래프의 모든 소스 Node에 대해 암시적으로 유지돼요. 즉, 압축 표현의 파생된 사실과 원본 그래프의 Node 사이에 일대다 Relationship이 있는 거죠.

GraphScale을 사용한 Neo4j 추론 및 쿼리

LUBM 테스트 스위트에서 데이터 크기가 증가하면서 일부 성능 결과를 살펴볼까요?

다음 차트는 Neo4j 위에 GraphScale을 사용하여(로딩 시간 없이) 50, 100, 250개 대학에서 모든 파생 가능한 사실(구체화라고 함)을 도출하는 데 걸리는 시간을 보여줘요. 추론 기능을 갖춘 다른 보조 스토리지 시스템과 비교할 때, Neo4j-GraphScale 듀오는 다른 어떤 시스템보다 데이터 증가에 따른 추론 시간 증가율이 훨씬 낮은 경우가 발생해요 (스키마 및 데이터 파일은 이 게시물 하단에서 확인할 수 있어요).

경험에 따르면 구체화는 실제 환경에서 효율적인 쿼리를 위한 핵심이에요. 사전 구체화 없이 추론 인식 트리플 스토어는 요청 시 각 단일 쿼리에 대한 모든 답변과 관련 사실을 일시적으로 도출해야 하죠. 결과적으로 이는 성능 저하를 가져오고 일반적으로 중요하지 않은 규칙 세트에서 실패해요.

Neo4j는 Graph Database이지, 트리플 스토어가 아니에요. SPARQL 쿼리 엔진이 장착되어 있지도 않고요. 하지만 Neo4j는 Cypher를 제공하죠. 많은 Semantic 애플리케이션의 경우, SPARQL을 Cypher 쿼리로 변환하는 것이 가능해야 해요.

사용자 관점에서 보면, 트랜잭션 그래프 분석 시스템과 Neo4j의 구체화된 그래프를 통해 Cypher로 정교한 Semantic 애플리케이션을 서비스할 수 있는 RDFS/OWL 추론 엔진이라는 두 가지 기술을 하나의 플랫폼으로 통합하는 셈이에요.

개념 증명으로 주어진 14개의 쿼리 중 가장 어려운 쿼리 중 하나로 밝혀진 LUBM 테스트 모음의 SPARQL 쿼리 9번을 한번 살펴볼까요? 쿼리는 학생과 해당 학생이 수강한 과정을 가르치는 지도교수를 요청하는데, 이는 대부분의 데이터세트에 대한 삼각형 관계 패턴이에요.

SELECT ?X ?Y ?Z {
?X rdf:type Student .
?Y rdf:type Faculty .
?Z rdf:type Course .
?X advisor ?Y .
?Y teacherOf ?Z .
?X takesCourse ?Z
}

완전히 구체화된 그래프를 가정하면, 이 SPARQL 쿼리는 다음 Cypher 쿼리로 변환돼요.

MATCH (x:Student)-[:takesCourse]->(z:Course),
  	(x)-[:advisor]->(y:Faculty)-[:teacherOf]->(z)
RETURN x, y, z

Neo4j Cypher 엔진은 이전 데이터 세트와 비교했을 때 (쿼리 9의 resp. count(*) 버전에 대한 시간), 경쟁력 있는 쿼리 성능을 제공하는 건 의심할 여지가 없어요. 트리플 저장소 A는 보조 저장소 지속성이 없는 순수한 인메모리 시스템이므로 여기서는 제외할게요.

Neo4j와 GraphScale 기술의 결합에는 더 많은 잠재력이 있어요. 실제로 그래프 추상화는 쿼리 응답의 지표로 매우 유용할 수 있죠. 예를 들어, 종류의 쿼리 패턴과 일치하는 데이터가 있는지 추상화에서 즉시 읽을 수 있어요.(x:)-[:]->().

결론적으로, 저는 George Anadiotis의 "라벨이 붙은 Property Graph와 RDF/OWL은 가까운 친척입니다"라는 말에 전적으로 동의해요.

다음 블로그 게시물에서는 위에서 설명한 간결한 표현을 인덱스로 활용해서, 큰 그래프에서 뛰어난 사용자 경험과 성능을 제공하는 RDF 그래프에 대한 대화형 시각적 탐색 및 쿼리 도구를 보여드릴게요.

자원

그래프 규모:

• GraphScale: 의미론적 데이터 저장소에 표현적 추론 추가. 제14회 국제 Semantic 웹 컨퍼런스(ISWC 2015) 데모 진행:
• 온톨로지 기반 데이터 저장소의 확장 가능한 유형 추론을 위한 추상화 개선: EP 2 966 600 A1 및 US 2016/0004965 A1

데이터:

• 평가에 사용된 LUBM OWL 2 RL 스키마 및 RDF 데이터(https://www.semspect.de/lubm-neo4j-graphscale.7z)

• 레이블이 지정된 Property Graph
• owl
• 올빼미 2 RL
• RDF
• RDF 스키마
• Reasoning Engine
• Resource Description Framework
• SPARQL

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지