pharmacy-pos-qr-system/docs/sqlite-graph-evaluation.md

SQLite-Graph 도입 평가

현재 시점(2026-01-24)에서 SQLite-Graph를 우리 프로젝트에 도입해야 하는가?

---

🎯 결론: 아직은 기존 SQL 유지 권장

이유

1. 아직 초기 버전 (Cypher 구문 부분 지원)
2. 핵심 기능 미지원 (ORDER BY, LIMIT, 집계 함수)
3. 프로덕션 안정성 불확실
4. 기존 SQL도 충분히 작동 중

---

✅ 현재 상황 분석

우리 프로젝트의 그래프 복잡도

현재 그래프 규모:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- 노드: ~50개 (약물, 증상, 환자 프로필)
- 엣지: ~200개 (약물-증상, 약물-부작용 관계)
- 최대 경로 깊이: 2-3 hop

→ 이 정도 규모에서는 SQL JOIN도 충분히 빠름!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

기존 SQL 쿼리 성능

# 2-hop 경로 탐색 (Statin → CoQ10 → Myopathy)
# 현재 SQL 쿼리 시간: ~10ms ✅

SELECT
    e1.name, r1.predicate, e2.name, r2.predicate, e3.name
FROM relationships r1
JOIN entities e1 ON r1.subject_id = e1.id
JOIN entities e2 ON r1.object_id = e2.id
JOIN relationships r2 ON r2.subject_id = e2.id
JOIN entities e3 ON r2.object_id = e3.id
WHERE e1.name = 'Statin' AND e3.name = 'Myopathy';

-- 실행 시간: 8-12ms (50개 노드, 200개 엣지 기준)
-- 충분히 빠름! 🚀

---

🔬 SQLite-Graph가 필요한 경우

시나리오 1: 그래프 규모가 클 때

대규모 그래프:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- 노드: 10,000개 이상
- 엣지: 100,000개 이상
- 최대 경로 깊이: 5-10 hop

→ 이 경우 SQL JOIN 성능 저하 (재귀 CTE 느림)
→ SQLite-Graph의 그래프 최적화 필요
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

시나리오 2: 복잡한 경로 쿼리가 많을 때

-- 예시: 모든 가능한 경로 탐색
MATCH path = (drug)-[*1..5]->(symptom)
WHERE drug.type = 'NSAID'
RETURN path;

-- SQL로 구현: 재귀 CTE 사용, 매우 복잡
WITH RECURSIVE paths AS (
    SELECT id, name, 1 AS depth, CAST(name AS TEXT) AS path
    FROM entities
    WHERE type = 'Drug'
    UNION ALL
    SELECT e.id, e.name, p.depth + 1, p.path || ' -> ' || e.name
    FROM paths p
    JOIN relationships r ON p.id = r.subject_id
    JOIN entities e ON r.object_id = e.id
    WHERE p.depth < 5
)
SELECT * FROM paths WHERE name = 'symptom';

-- 복잡도: ⭐⭐⭐⭐⭐ (이해하기 어려움)
-- vs Cypher: ⭐ (매우 간단)

---

📊 비교표: 우리 프로젝트 기준

┌─────────────────────────┬─────────────────┬─────────────────┐
│      평가 항목          │  기존 SQL       │ SQLite-Graph    │
├─────────────────────────┼─────────────────┼─────────────────┤
│ 현재 그래프 규모        │  ✅ 충분        │  ✅ 충분        │
│ 성능 (50 노드, 200 엣지)│  ✅ ~10ms       │  ✅ ~5-10ms     │
│ 배포 난이도             │  ✅ 매우 쉬움   │  ⚠️ 확장 필요   │
│ 안정성                  │  ✅ 검증됨      │  ⚠️ 초기 버전   │
│ 팀원 학습 곡선          │  ✅ SQL 익숙    │  ⚠️ Cypher 학습 │
│ 쿼리 가독성 (2-hop)     │  ⭐⭐          │  ⭐⭐⭐⭐⭐     │
│ 쿼리 가독성 (N-hop)     │  ⭐             │  ⭐⭐⭐⭐⭐     │
│ ORDER BY / LIMIT        │  ✅ 지원        │  ❌ 미지원 가능 │
│ 집계 함수               │  ✅ 지원        │  ❌ 미지원 가능 │
│ 그래프 알고리즘         │  ❌ 수동 구현   │  ✅ 내장        │
└─────────────────────────┴─────────────────┴─────────────────┘

【종합 점수】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
기존 SQL:         ★★★★☆ (4.0/5.0)
SQLite-Graph:     ★★★☆☆ (3.0/5.0)  ← 아직 초기 버전

【결론】
현재 시점에서는 기존 SQL 유지 권장
6개월~1년 후 SQLite-Graph 성숙도 재평가

---

🎯 권장 전략: 하이브리드 접근

1단계: 현재 (기존 SQL 유지)

# backend/graph_query.py
class GraphQuery:
    """기존 SQL 기반 그래프 쿼리"""

    def find_path(self, start, end, max_depth=3):
        """2-3 hop 경로 탐색"""
        # SQL로 구현 (현재 코드 유지)
        pass

    def recommend_drug(self, patient_profile, symptom):
        """약물 추천"""
        # SQL로 구현 (현재 코드 유지)
        pass

장점:

• ✅ 안정적
• ✅ 배포 쉬움
• ✅ 충분한 성능

---

2단계: 6개월 후 (SQLite-Graph 재평가)

평가 항목:

1. Cypher 구문 지원 확대 여부
   - ORDER BY, LIMIT 지원?
   - 집계 함수 지원?
   - OPTIONAL MATCH 지원?

2. 커뮤니티 성숙도
   - GitHub Stars 증가?
   - 이슈 해결 속도?
   - 프로덕션 사용 사례?

3. 우리 그래프 규모 증가
   - 노드 1,000개 이상?
   - 복잡한 N-hop 쿼리 필요?

조건 충족 시 마이그레이션:

# backend/graph_query_v2.py (SQLite-Graph 버전)
class GraphQueryV2:
    """Cypher 기반 그래프 쿼리"""

    def find_path_cypher(self, start, end):
        """Cypher로 경로 탐색"""
        cypher = f"""
        MATCH path = (a {{name: '{start}'}})-[*1..5]->(b {{name: '{end}'}})
        RETURN path
        ORDER BY length(path)
        LIMIT 1
        """
        # 실행...

---

3단계: 장기 (Neo4j 검토)

만약 그래프가 매우 커진다면 (노드 10,000개+):

SQLite-Graph도 한계 → Neo4j 전환 검토

Neo4j 장점:
- 대규모 그래프 최적화
- 완전한 Cypher 지원
- 분산 처리 가능
- Graph Data Science 라이브러리

Neo4j 단점:
- 별도 서버 필요 (배포 복잡)
- 비용 (엔터프라이즈)
- SQLite보다 무거움

---

🛠️ 실용적인 팁: SQL을 Cypher처럼 사용

현재 SQL을 더 읽기 쉽게 만들기

# backend/graph_utils.py

def build_path_query(start_entity, end_entity, max_hops=3):
    """
    경로 탐색 SQL을 자동 생성
    (Cypher처럼 간단하게 호출)
    """
    # 2-hop
    if max_hops == 2:
        return f"""
        SELECT
            e1.name AS start,
            r1.predicate AS rel1,
            e2.name AS middle,
            r2.predicate AS rel2,
            e3.name AS end
        FROM relationships r1
        JOIN entities e1 ON r1.subject_id = e1.id
        JOIN entities e2 ON r1.object_id = e2.id
        JOIN relationships r2 ON r2.subject_id = e2.id
        JOIN entities e3 ON r2.object_id = e3.id
        WHERE e1.name = '{start_entity}' AND e3.name = '{end_entity}'
        """

    # 3-hop (재귀 CTE)
    elif max_hops == 3:
        return f"""
        WITH RECURSIVE paths AS (
            -- 시작 노드
            SELECT
                e.id,
                e.name,
                1 AS depth,
                e.name AS path
            FROM entities e
            WHERE e.name = '{start_entity}'

            UNION ALL

            -- 재귀: 다음 노드 탐색
            SELECT
                e.id,
                e.name,
                p.depth + 1,
                p.path || ' -> ' || e.name
            FROM paths p
            JOIN relationships r ON p.id = r.subject_id
            JOIN entities e ON r.object_id = e.id
            WHERE p.depth < {max_hops}
        )
        SELECT * FROM paths WHERE name = '{end_entity}'
        """


# 사용 (Cypher처럼 간단)
query = build_path_query('Statin', 'Myopathy', max_hops=2)
results = cursor.execute(query).fetchall()

---

📌 최종 권장사항

✅ 지금 당장: 기존 SQL 유지

이유:

1. 현재 그래프 규모에서 충분히 빠름 (10ms 미만)
2. 안정적이고 검증됨
3. 배포 간단 (확장 설치 불필요)
4. SQLite-Graph 아직 초기 버전

개선 방안:

• SQL 쿼리를 헬퍼 함수로 감싸서 가독성 향상
• 자주 사용하는 쿼리 VIEW로 저장
• 성능 병목 발생 시에만 최적화

---

🔮 6개월 후: SQLite-Graph 재평가

체크리스트:

□ SQLite-Graph가 ORDER BY/LIMIT 지원?
□ 집계 함수 (COUNT, AVG) 지원?
□ GitHub Stars 1,000+ (커뮤니티 활성화)?
□ 프로덕션 사용 사례 3개 이상?
□ 우리 그래프 노드 500개 이상?
□ 복잡한 N-hop 쿼리 빈번?

→ 3개 이상 ✅ → 마이그레이션 고려

---

📚 장기: Neo4j 검토 (선택사항)

조건:

□ 노드 10,000개 이상
□ 복잡한 그래프 알고리즘 필요 (PageRank, 커뮤니티 탐지)
□ 실시간 그래프 분석 필요
□ 분산 처리 필요

→ 모두 ✅ → Neo4j 도입

---

🎯 요약

┌─────────────────────────────────────────────────────────┐
│         현재 시점 (2026-01-24) 최적 선택:              │
│                                                         │
│              기존 SQL 유지 ✅                            │
│                                                         │
│  이유:                                                  │
│  - SQLite-Graph 아직 초기 버전                          │
│  - 핵심 기능 미지원 (ORDER BY, LIMIT)                   │
│  - 현재 그래프 규모에서 SQL 충분히 빠름                 │
│  - 프로덕션 안정성 중요                                 │
│                                                         │
│  재평가 시점: 2026년 7-8월                              │
└─────────────────────────────────────────────────────────┘

---

🔗 참고 링크

• SQLite-Graph GitHub: https://github.com/agentflare-ai/sqlite-graph
• 현재 지원 구문: CREATE, MATCH, WHERE, RETURN
• 미지원 구문: ORDER BY, LIMIT, 집계, OPTIONAL MATCH

---

작성: 2026-01-24 재평가 예정: 2026-07-24