그래프 스토리지
Triple Store와 PostgreSQL 기반 그래프 저장 구조, 인덱스와 쿼리 플랜
Posts 2
현장에서 다시 잰 것들 · 5편
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
현장에서 다시 잰 것들 · 2편
그래프 서버가 없는 곳에서 빌드는 트리플 0개로 완료되고 있었습니다
폐쇄망 고객에게 별도 그래프 서버는 반입 심사와 승인, 운영 인력이 따로 드는 구성 요소였습니다. 지식그래프의 정본을 이미 있는 PostgreSQL 테이블 세 개로 옮기고, 같은 빌드 결과를 두 저장소에 이중 기록해 대조한 과정입니다.
Engineering 2
Engineering · Knowledge Graph
그래프 크기를 따라가던 검색 비용과 흔들리던 근거: PostgreSQL 그래프 조회 계층 정비
PostgreSQL 위 GraphRAG 검색이 한 번에 54~127초 걸리거나 같은 질문에 근거가 달라지는 현상을 pg_stat_activity, 실행 계획, 로그 타임스탬프로 추적했습니다. 플래너 통계, 그래프 전체를 읽던 PPR, 검색마다 반복되던 집계, 정렬 없는 LIMIT을 차례로 고쳐 비용을 후보 크기에 묶고 근거 재현을 50/50으로 맞췄습니다.
Engineering · Knowledge Graph
Fuseki 없이 지식 그래프 운영하기: PostgreSQL 테이블 3개로 옮기며 드러난 숨은 결합들
별도 JVM 트리플스토어인 Fuseki는 설정 하나가 어긋나면 그래프 계층 전체가 멈추고 폐쇄망 반입 부담도 컸습니다. 같은 빌드를 두 저장소에 이중 기록해 충실도를 대조한 뒤 Fuseki 쓰기를 기본 비활성화했고, 완료 판정·재시도·카운트·품질 지표에 숨어 있던 Fuseki 전제를 하나씩 걷어내며 검색을 라이브러리로 일원화했습니다.