AeonG 직접 돌려 보기 — 시간 그래프 DB 튜토리얼과 Ontological 비교

이 문서가 답하는 질문

• Gemini 노트북 보고서(bench/온톨로지 데이터베이스의 시간과 스키마 관리 - Gemini Notebook.pdf)가 소개한 시간 그래프 모델의 핵심은 무엇인가?
• 그중 "OLTP 시점 복원의 정답"으로 추천된 AeonG(PVLDB 2024)는 실제로 어떻게 설치하고, 어떻게 과거를 묻는가?
• 같은 이야기를 AeonG와 Ontological에서 돌리면 답이 어떻게 다른가?
• 우리가 지는 곳은 어디인가?

재현 파일:

• AeonG 빌드: bench/aeong/Dockerfile
• AeonG 시나리오: bench/aeong/aeong_scenario.py
• AeonG 결함 최소 재현: bench/aeong/aeong_probes.sh
• Ontological 시나리오: bench/aeong/ontological_scenario.sql
• 실행 결과 원본: bench/results/aeong_*.out

관련 문서: 바이템포럴 튜토리얼, 시간 기능 매뉴얼, ADR-027

0. 요약

AeonG는 저장소 vldb 브랜치 커밋 b780a0c를 소스에서 빌드해 Apple M-시리즈(arm64)에서 돌렸습니다. Ontological은 현재 작업 트리를 PG16 확장으로 빌드해 돌렸습니다. 두 시스템 모두 입사 → 연봉 인상 → 정정 → 퇴사로 이어지는 같은 이야기로 시험했습니다.

한 줄 결론. AeonG가 논문에서 보인 강점은 저장 효율과 지연시간입니다. 기능 범위는 트랜잭션 시간 한 축뿐입니다. 그마저 관계나 노드가 삭제되는 순간 조용히 틀린 답을 냅니다. 보고서가 권한 "엔터프라이즈 OLTP 시점 복원"에 그대로 쓰기는 어렵습니다. 우리의 약점은 다른 곳에 있습니다.

• 시점 질의 Cypher 문법이 없습니다. 세션 설정으로 시점을 지정합니다.
• 시점 질의에서 가변 길이 경로를 지원하지 않습니다.
• 성능을 측정한 적이 없습니다.

1. 보고서(PDF) 핵심 정리

1.1 시간은 두 개다

두 축을 다 가진 모델을 바이템포럴이라고 합니다. 이 모델이어야 "그 시점에 시스템이 알고 있던 유효 상태"를 재현할 수 있습니다(감사 추적).

1.2 구간과 무결성

• 구간은 반개구간 [start, end)입니다. 열린 끝은 +∞, 9999-12-31 또는 NULL로 표현합니다.
• 시점(AS OF) 질의는 from ≤ t < to를 묻는 포인트 스태빙입니다.
• 범위 질의는 from < T_end ∧ to > T_start를 묻는 오버랩 검사입니다.
• 무결성 제약: 관계의 수명은 양 끝 노드 수명의 교집합 안에 있어야 합니다. Ω(e) ⊆ Ω(u) ∩ Ω(v)

1.3 모델링 방식 (보고서 분류)

• 시간을 붙이는 단위:
  • 노드 주석형
  • 엣지 주석형
  • 노드-엣지 주석형
  • 그래프 스냅샷형
• 설계 패턴:
  • ① 속성에 구간을 두는 방식. 관계 폭발이 생깁니다.
  • ② 불변 Identity 노드와 Version 노드를 나누는 방식. 조회할 때마다 1홉이 더 듭니다.
  • ③ 같은 노드 쌍 사이에 구간별 엣지를 복제하는 방식. 프록시 노드를 씁니다.

1.4 성능 쟁점

• 인터벌 스태빙: B-Tree를 from에만 걸면 후행 필터가 생깁니다. 해법은 R-Tree나 GiST 같은 2차원 색인입니다.
• 슈퍼노드 퇴화: 만료된 엣지가 쌓입니다. 해법은 hot/cold 분리(AeonG 방식)나 Time-Tree 파티셔닝입니다.
• 시간 준수 경로: A→B→C 경로는 엣지 시점이 단조 증가할 때만 성립합니다(ChronoGraph의 EAT 경로).

1.5 보고서가 AeonG에 대해 말한 것 — 검증 결과

2. 튜토리얼 A — AeonG 설치

2.1 공식 이미지가 안 되는 이유

README가 권하는 hououou/aeong:v1은 4.9 GB짜리 CentOS 7 / amd64 빌드 환경입니다. 바이너리는 들어 있지 않습니다. 이미지 안의 /home/memgraph는 AeonG가 아닌 원본 Memgraph 소스입니다.

• Apple Silicon에서 이 이미지를 돌리면 QEMU 에뮬레이션 아래에서 CentOS 7의 yum·curl·sbcl이 vsyscall 페이지 접근(0xffffffffff600400)으로 죽습니다.
• AeonG 저장소에서는 libs/antlr4.patch, rocksdb.patch, librdtsc.patch가 .gitignore로 빠져 있어서 ./init가 실패합니다.

2.2 네이티브 빌드 (권장)

bench/aeong/Dockerfile은 Ubuntu 22.04에서 빌드합니다. arm64와 amd64 모두 됩니다.

• Boost: 1.78을 소스에서 빌드합니다. 22.04에 들어 있는 것은 1.74입니다.
• gflags: Memgraph 포크를 쓰고, toolchain v4와 같은 커밋 b37ceb0에 고정합니다. DEFINE_HIDDEN_* 매크로가 있어야 하기 때문입니다.
• 빠진 패치: 라이브러리 버전 고정이 똑같은 Memgraph v2.3.1에서 가져옵니다.
• 빌드 옵션: -DMG_ARCH=ARM64를 줍니다. Apple Silicon(16코어)에서 저장소 클론부터 make memgraph mgconsole까지 7분 20초 걸렸습니다. apt·Boost·gflags 단계는 캐시된 상태에서 잰 값입니다.

docker build -t aeong -f bench/aeong/Dockerfile bench/aeong
docker run -d --name aeong -p 17687:7687 aeong                         # TT = 논리 타임스탬프
# docker run -d --name aeong -p 17687:7687 aeong --real_time_flag=true # TT = epoch 밀리초
echo "RETURN 1 AS x;" | docker exec -i aeong mgconsole --host 127.0.0.1 --output-format csv

드라이버 주의. 이 빌드(Memgraph 2.3 기반)는 Python neo4j 4.4 드라이버의 Bolt 4.3 HELLO를 받으면 Something went wrong during session execution!를 내고 끊습니다. 그래서 이 문서의 모든 실행은 함께 빌드한 mgconsole로 했습니다.

2.3 AeonG 고유 설정

기본(논리) 모드에서는 사용자가 "어제 오후 3시"를 물을 방법이 없습니다. TT가 커밋 카운터이기 때문입니다. 쓰기 한 번에 카운터가 2씩 오릅니다(시작과 커밋). 그 값을 알려 주는 함수도 없습니다. 이 문서에서 벽시계 기준 질의는 --real_time_flag=true로, 결함 재현은 기본 모드로 했습니다.

3. 튜토리얼 B — AeonG로 과거 묻기

3.1 문법

MATCH (p:Person {name:'ann'}) TT AS 1791261693460 RETURN p.salary          -- 시점
MATCH (p:Person {name:'ann'}) TT FROM 0 TO 9999999999999 RETURN p.salary   -- 구간: 겹치는 모든 버전

• TT 절은 MATCH 하나에 붙습니다. 패턴과 WHERE 다음에 씁니다.
• 쓰기 절(CREATE, SET)에는 시간을 줄 수 없습니다. 기록되는 시간은 언제나 "지금"입니다.
• MATCH … TT AS 0 SET …도 오류 없이 받아들여집니다. 과거에 없던 노드라 매칭되는 것이 없어서 아무 일도 일어나지 않습니다.

3.2 되는 경우 — 노드 속성만 바뀔 때

CREATE (:P {v:1})-[:R {w:'a'}]->(:C);   MATCH (p:P) SET p.v=2;   MATCH (p:P) SET p.v=3;

  TT AS 2    p.v=           r.w=           ← 생성 전
  TT AS 3    p.v="1"        r.w="a"
  TT AS 5    p.v="2"        r.w="a"
  TT AS 7    p.v="3"        r.w="a"

(bench/results/aeong_probes.out P1.) 벽시계 모드에서도 같습니다. TT AS <A>는 1을, TT AS <B>는 2를 돌려줍니다. TT FROM 0 TO ∞는 3, 2, 1을 돌려줍니다.

3.3 이야기 하나 — ann (벽시계 모드)

AeonG에는 유효 시간이 없습니다. 그래서 "2023-01-01부터 인상"이라는 정보는 어디에도 기록되지 않습니다. 정정과 인상의 구분도 사라집니다.

3.4 깨지는 경우

① 관계를 지우면 그 노드의 과거가 현재값으로 덮입니다. 위 3.2의 그래프에서 R 하나만 지운 뒤 같은 질문을 다시 던졌습니다.

  TT AS 3    p.v="3"        r.w=           ← 정답: v=1, r.w=a
  TT AS 5    p.v="3"        r.w=           ← 정답: v=2, r.w=a
  TT AS 7    p.v="3"        r.w=           ← 정답: v=3, r.w=a

• 오류도 경고도 없습니다. GC(FREE MEMORY)로 이력을 RocksDB로 옮긴 뒤에도 같습니다(P6).
• 논리 모드와 벽시계 모드 모두에서 재현됩니다.
• ann 시나리오(aeong_scenario_keep_*.out)에서도 T1~T5 전 시점이 salary 250으로 나왔습니다.

② 노드를 지우면 이력 전체가 안 보입니다.

  삭제 전 구간: "8" "7" "NULL" "NULL" "NULL"
  삭제 후 구간: []

스캔 연산자가 지금 존재하는 정점을 순회합니다. 그 정점마다 과거 버전을 덧붙이는 구조입니다(ScanAllCursor::Pull → addHistoryVertex, operator.cpp:481-523). 그래서 지워진 정점은 출발점이 될 수 없습니다. ann 시나리오에서 DETACH DELETE까지 실행하면 T1~T5 모든 시점 질의가 빈 결과를 냅니다(aeong_scenario_memory.out, aeong_scenario_gc.out).

③ 구간 질의에 존재한 적 없는 버전이 섞입니다. TT FROM 0 TO ∞에 실제 버전 3개와 "NULL" 행 3개가 함께 나옵니다. 이 행은 노드가 아닙니다. 라벨 없는 패턴에서 labels(n)을 부르면 'labels' argument … must be either 'null' or 'node'로 실패합니다. 관계가 낀 패턴에서는 같은 관계가 수십 번 반복됩니다. 행 33개 중 상당수는 c.name = NULL이었습니다.

④ VT 절은 동작하지 않습니다. MATCH (c:C) VT AS 0 RETURN c → line 1:13 mismatched input 'VT'.

3.5 정리

AeonG가 정답을 주는 범위는 **"노드도 관계도 삭제되지 않고 속성만 바뀐 그래프의 트랜잭션 시간"**입니다. 논문 벤치마크(T-mgBench, T-LDBC, T-gMark)의 갱신 연산도 대부분 이 형태입니다. 그래서 논문의 지연시간과 저장량 수치 자체는 이 결과와 모순되지 않습니다. 다만 퇴사, 계약 해지, 관계 종료처럼 삭제가 곧 사건인 업무에는 쓸 수 없습니다.

4. 튜토리얼 C — 같은 이야기를 Ontological에서

4.1 준비

SELECT og_create_graph('hr');
-- Person(name, salary) / Company(name) / WORKS_AT(title) 타입 생성 후
SELECT og_enable_temporal('hr','Person');
SELECT og_enable_temporal('hr','Company');
SELECT og_enable_temporal('hr','WORKS_AT');

og_enable_temporal을 부르면 저장 테이블에 두 열이 추가됩니다.

• __valid tstzrange: 유효 시간입니다.
• __sys_from: 트랜잭션 시간입니다.

이력은 og_data.h_<tid> 테이블에 쌓입니다. 행 단위 트리거가 기록하므로 Cypher, TypeQL, 원시 SQL 어느 경로로 쓰든 빠지지 않습니다.

4.2 쓰기 — 유효 시간을 직접 준다

SET og.valid_from = '2020-01-01';   -- T1: 입사
SELECT og_cypher('hr','CREATE (:Person {name:"ann", salary:100})');
...
SET og.valid_from = '2023-01-01';   -- T2: 2023년부터 200 (소급 입력)
SELECT og_cypher('hr','MATCH (p:Person {name:"ann"}) SET p.salary = 200');
SET og.valid_from = '2023-01-01';   -- T3: 2023년 값 정정 → 250
SELECT og_cypher('hr','MATCH (p:Person {name:"ann"}) SET p.salary = 250');
SET og.valid_from = '2024-06-01';   -- T4: 퇴사
SELECT og_cypher('hr','MATCH (:Person {name:"ann"})-[w:WORKS_AT]->() DELETE w');

4.3 읽기 — Cypher는 그대로, 시점은 세션 설정으로

(bench/results/aeong_ontological_scenario.out)

구간 이력은 SQL 함수로 봅니다. 아래는 같은 ann을 두 시점의 믿음으로 본 결과입니다.

og_timeline('hr','Person','name','ann')                         -- 지금의 믿음
 2020-01-01 | 2023-01-01 | 100 | v
 2023-01-01 | infinity   | 250 | current
og_timeline('hr','Person','name','ann', system_at => T2)        -- T2 시점의 믿음
 2020-01-01 | 2023-01-01 | 100 | v
 2023-01-01 | infinity   | 200 | u

지원하지 않는 형태는 명시적으로 거절합니다.

SET og.valid_at = '2021-06-01';
MATCH (p:Person)-[:WORKS_AT*1..2]->(c:Company) RETURN c.name
→ 0A000 OG_TEMPORAL_UNSUPPORTED: variable-length traversal over a temporal relationship type
  cannot answer a point-in-time query

5. 기능 비교

6. 보고서 체크리스트 대비 우리 위치

7. 우리가 가져올 것

AeonG에서 배울 것은 질의 모델이 아니라 저장 모델입니다.

1. Cypher 안에 시점을 쓰고 싶다는 요구는 실재합니다. AeonG의 MATCH … TT AS t처럼 "이 패턴만 과거로" 묻는 기능은 GUC로 흉내 낼 수 없습니다. 예를 들어 "지금의 조직도에 작년 담당자를 붙여 보라" 같은 질문입니다. ADR-027의 플랜 캐시 논거를 지키는 길이 있습니다. 시점을 리터럴이 아닌 파라미터로 컴파일하면 됩니다(MATCH … AT VALID $t). 이 방식은 검토할 가치가 있습니다.
2. 이력 저장량. 우리는 바뀐 열이 하나여도 행 전체를 복사합니다. AeonG의 델타 체인과 앵커 방식은 이력이 긴 타입에서 크게 차이 날 수 있습니다. 우선 측정부터 해야 합니다. spec 013 SC-005("이력 쓰기 오버헤드 ≤ 40%")가 아직 비어 있습니다.
3. 보존 정책. AeonG에도 기본으로 꺼진 retention_period가 있습니다. 우리는 아예 없습니다.

가져오지 말아야 할 것도 분명합니다. 현재 정점에서 출발해 과거를 덧붙이는 스캔 구조입니다. 삭제가 있는 순간 과거가 사라지는 결함(§3.4 ②)이 바로 이 구조에서 나옵니다. 우리 구조는 이력 테이블을 1급 관계로 UNION합니다(ADR-027). 이 구조 덕분에 같은 질문에 정답을 냈습니다.

8. 재현 방법

# AeonG (빈 인스턴스, 기본 논리 모드)
docker build -t aeong -f bench/aeong/Dockerfile bench/aeong
docker run -d --name aeong -p 17687:7687 aeong
bash bench/aeong/aeong_probes.sh aeong                 # §3.2, §3.4 결함 재현 → aeong_probes.out

# AeonG ann 시나리오 (벽시계 모드로 띄운 뒤)
python3 bench/aeong/aeong_scenario.py --container aeong              # 노드 삭제까지
python3 bench/aeong/aeong_scenario.py --container aeong --keep-node  # 노드는 남기고
python3 bench/aeong/aeong_scenario.py --container aeong --gc         # 질의 전 FREE MEMORY

# Ontological
docker exec og bash -lc 'createdb -h localhost -p 28816 tt_demo &&
  psql -h localhost -p 28816 -d tt_demo -c "CREATE EXTENSION ontological CASCADE" &&
  psql -h localhost -p 28816 -d tt_demo -f /work/bench/aeong/ontological_scenario.sql'

환경:

• 하드웨어: Apple M-시리즈(arm64), 16코어, Docker Desktop
• AeonG: hououou/AeonG@b780a0c (vldb 브랜치), Ubuntu 22.04에서 clang 13으로 빌드
• Ontological: 현재 작업 트리, PG16
• 실행일: 2026-10-06

한계: 성능은 비교하지 않았습니다. AeonG는 이 문서에서 기능 정확성만 확인했습니다.