측정된 기준선 — 수치와 그 조건

이 문서가 답하는 질문

• 이 프로젝트에서 실제로 측정된 수치는 무엇인가?
• 각 수치는 어떤 머신·데이터 규모·평균 차수·PostgreSQL 설정에서 나왔는가?
• 어떤 수치가 아직 측정되지 않았는가?

0. 규칙 — 이 문서의 사용법

필수

• ✅ 어떤 수치를 인용할 때는 표 헤더의 출처 JSON 파일명과 §1의 측정 조건을 함께 인용한다.
• ✅ 지연 수치는 같은 표의 프로토콜 바닥값 행과 함께 읽는다.
• ✅ 각 표는 하나의 런(run) 에서 온 값만 담는다. 표 사이의 셀을 옮기지 않는다.

금지

• ❌ 이 문서에 없는 수치를 만들어 쓰는 것.
• ❌ 평균 차수 20의 랜덤 그래프에서 얻은 수치를 다른 모양의 그래프에 적용하는 것.
• ❌ 논리 페이지 접근 수를 지연과 같은 방식으로 측정된 값으로 다루는 것 — §6의 주의사항을 볼 것.

1. 사실 — 측정 조건

모든 수치는 한 대의 머신, 한 프로세스, 동시성 없음, 웜 캐시 조건이다.

미확인 / 측정되지 않음 동시성, 콜드 캐시, 스큐(허브·파워로우) 그래프, LDBC SNB, 쓰기 워크로드, 장기 스트레스. docs/benchmark.md "What this benchmark does not show" 와 bench/README.md "Not yet implemented" 가 같은 목록을 든다.

2. 사실 — 데이터셋

3. 사실 — 공개 기준선: 1/2/3홉 + 프로퍼티 스캔

50,000 노드 / 974,936 엣지 / 평균 차수 20 출처: bench/results/bench-50000-20260806T042833Z.json (AGE explicit·TypeDB 열은 같은 데이터에 대한 별도 런 — docs/benchmark.md "Reproducing" 참고)

이 JSON 파일 자체의 age 3홉 값은 15,383.778 ms 이고, docs/benchmark.md 가 싣는 22,412 ms 는 같은 데이터에 대한 다른 런(bench-50000-20260806T052220Z, 저장소에 없음)의 값이다. AGE의 *1..n 은 시작 노드에 따라 변동이 극심하며(중앙값 22.4 s, p95 914 s — docs/benchmark.md), 이 열의 어떤 값도 안정된 수치로 인용해서는 안 된다.

논리 페이지 접근 (같은 파일):

4. 사실 — 깊은 순회 기준선 (정규화된 질문)

질문: "시작 노드를 제외하고 k홉 안에 있는 서로 다른 노드의 수" (bench/harness.py:305-317 의 reach_hop). 문당 60초 상한. 출처: bench/results/bench-50000-20260817T033001Z.json (50,000 노드 / 974,936 엣지 / 평균 차수 20).

같은 런의 논리 페이지 접근 (PostgreSQL 상주 시스템만):

age_explicit 행은 이 런에서 5홉을 물었을 때 백엔드가 커널에 의해 종료(signal 9) 되어 전부 결측이다 (JSON의 not_attempted: "… crashed the server at reach5hop").

5. 사실 — 큰 지름 그래프

chain-250k (250,000 노드 / 249,999 엣지 / 차수 1) — bench-250000-20260817T051823Z.json

grid-250k (250,000 노드 / 499,000 엣지 / 차수 2) — bench-250000-20260817T052859Z.json

결론(사실): 프론티어가 그래프 전체를 덮는 모양에서는 우리 힙 BFS가 앞서고, 프론티어가 얇고 깊이가 큰 모양에서는 Neo4j와 plain 재귀 CTE 가 우리보다 앞선다. docs/deep-traversal.md 의 "A correction we owe the earlier section" 이 같은 결론을 서술한다.

6. 사실 — og_vlp / og_reach_sql / og_reach / og_csr_reach 4종 비교

출처: bench/csr/results/. 전체 표는 docs/deep-traversal.md 에 있으므로 여기서는 문서에 없는 값만 싣는다.

CSR 컴파일 비용 (백엔드마다 1회, 질의는 이 비용을 내지 않음):

docs/deep-traversal.md 는 dense/sparse의 컴파일 비용만 싣는다. 100만 노드 규모에서는 백엔드당 약 1초 / 23~31 MB 라는 것이 위 두 줄이 새로 말해 주는 사실이다. 연결당 이 비용을 내는 배치라면 og_csr_build 는 사실상 쓸 수 없다.

chain-1M / grid-1M 4종 비교 (ms, 중앙값) — 두 파일 모두 모든 변형의 답이 일치(agrees: true):

7. 사실 — 로드 처리량 (주의: 이것은 쓰기 API의 수치가 아니다)

결과 JSON의 load_edges_per_sec 는 하네스가 og_data.og_node / og_edge / og_adj 에 직접 INSERT … SELECT 하는 SQL 경로를 잰 값이다 (bench/harness.py:322-355). og_create_node() / og_create_edge() / Cypher CREATE 는 이 수치에 포함되지 않는다.

같은 데이터에 대해 두 런이 124,580 대 161,852로 30% 차이가 난다. 이 항목은 안정된 지표가 아니며, 회귀 게이트가 감시하지도 않는다(06_regression_guard.md).

8. 사실 — 페이지 수 측정의 주의사항 (중요)

buffers 값은 지연과 같은 방식으로 측정되지 않는다.

• 지연은 이미 열린 psql 세션 안에서 워밍업 후 중앙값을 잰다 (harness.py:135-181).
• 페이지 수는 buffers_read() 가 새 psql 프로세스를 띄워 EXPLAIN (ANALYZE, BUFFERS) 를 한 번 돌린 값이다 (harness.py:183-206 → harness.py:54-66 의 psql()). 즉 콜드 백엔드의 첫 호출이다.

이 차이는 ontological 행에만 비대칭적으로 불리하게 작용한다. Cypher 표면은 첫 호출에서 Rust 쪽 컴파일 경로를 지나고, 그 경로가 카탈로그를 SPI로 여러 번 읽기 때문이다 (03_hot_paths.md §2).

측정으로 뒷받침되는 증거: ontological 의 prop_scan 페이지 수는 데이터 크기와 무관하게 거의 일정하다.

노드 수가 50배로 늘어도 1,170 → 1,177 로만 움직인다. 따라서 이 1,170여 페이지는 데이터 스캔이 아니다. 무엇이 소비하는지는 미확인이며, 후보는 컴파일 시점 카탈로그 SPI 조회(types::graph_id, resolve_label_set, views::view_exists / view_properties / concrete_tables, labeling::og_subtypes), og_cypher 의 감사 로그 INSERT (cypher/mod.rs:122-135), pgrx 확장 첫 로드다. 확인 방법은 PERF-14 에 적었다.

9. 사실 — 재현 불가·해석 주의가 필요한 관측

bench-5000-20260817T030411Z.json 에서 ontological 과 ontological_raw 의 페이지 수가 사실상 동일하다.

같은 두 행이 50,000 노드 런에서는 2,070 대 448 (4.6배), 1.519 ms 대 0.107 ms (14배)로 갈린다. ontological_raw 의 존재 이유는 "Cypher 표면을 뺀 스토리지 경로를 재는 것"인데 (bench/README.md "Two Ontological rows"), 이 런에서는 두 행이 서로 다른 것을 재고 있다는 전제가 성립하지 않는 것으로 보인다. 원인 미확인. 회귀 게이트의 공백으로 06_regression_guard.md §5 에 기록한다.

10. 미확인 — 아직 측정되지 않은 것