260215 LiteDB FullQuery 전체읽기 성능분석

⚡ 260215 LiteDB Full Query (전체 읽기) 성능 분석

💡 이전 문서 LiteDB 성능 체크 - Unity 환경의 후속 리서치로, 조건절 없이 모든 레코드를 한번에 메모리로 읽어들이는 Full Query 성능에 집중하여 분석한다.

🗄️ 1. Full Query란?

// LiteDB - 조건 없이 전체 컬렉션을 메모리로 로드
var allMeshes = meshCol.FindAll().ToList();
var allProps  = propCol.FindAll().ToList();

// SQLite 동등 표현
// SELECT * FROM MyMesh;
// SELECT * FROM MyProp;

Full Query는 인덱스를 전혀 사용하지 않고, 컬렉션의 모든 문서를 순차적으로 읽어 메모리에 적재하는 작업이다. LiteDB 내부에서는 다음 과정을 거친다:

[디스크 페이지 읽기] → [BSON 바이트 조립] → [BSON 역직렬화] → [C# 객체 매핑] → [List<T> 적재]

각 단계마다 병목이 발생하며, 특히 BSON 역직렬화와 메모리 할당이 핵심 병목이다.

🗄️ 2. LiteDB Full Query의 내부 동작

🔹 2.1 페이지 기반 순차 읽기

LiteDB v5의 데이터 파일은 8KB 페이지 단위로 구성된다:

Full Query 시 모든 Data Page를 순차적으로 읽으며, 각 페이지에서 문서를 추출한다.

💡 참고: LiteDB 데이터 구조 문서

🔹 2.2 BSON 역직렬화 오버헤드

BSON 역직렬화에서 발생하는 오버헤드:

💡 참고: LiteDB 메모리 할당 이슈 #1062

🔹 2.3 메모리 증폭 현상

실제 보고된 메모리 증폭 사례:

✨ 핵심 교훈: FindAll().ToList()는 모든 결과를 List<T>로 즉시 실체화하므로, 메모리 증폭이 극대화된다. IEnumerable 기반 스트리밍 소비가 메모리 효율에서 훨씬 유리하다.

💡 참고: 메모리 3GB 이슈 #865, 200MB 할당 이슈 #1062

🏗️ 3. 대상 스키마에 대한 Full Query 예상 성능

🔹 3.1 MyProp (경량 문서, ~200 bytes × 500,000건)

총 데이터 크기: ~95 MB (디스크)

🎮 3.2 MyMesh (대용량 문서, ~28 KB × 500,000건, 중형 메시 기준)

총 데이터 크기: ~13 GB (디스크)

💡 결론: MyMesh 50만건 Full Query는 물리적으로 불가능하다. 일반 PC의 RAM(16~32GB)을 초과하며, GC 압력으로 인한 앱 프리징과 OOM이 발생한다.

🔹 3.3 실제 보고 사례와의 대조

⚖️ 4. SQLite Full Query와의 비교

🔹 4.1 SQLite 읽기 메커니즘

SQLite는 LiteDB와 근본적으로 다른 읽기 방식을 사용한다:

[디스크 페이지 읽기] → [행 데이터 디코딩] → [DataReader 커서] → [필요 시 객체 매핑]

💡 참고: SQLite 성능 튜닝, SQLite 최적화

⚖️ 4.2 MyProp Full Query 비교 (500,000건, ~200 bytes)

⚖️ 4.3 MyMesh Full Query 비교 (500,000건, ~28 KB 중형 메시)

✨ 핵심: MyMesh 50만건 Full Query는 어떤 임베디드 DB에서도 한번에 메모리 로드가 비현실적이다. 스트리밍/페이징 전략이 필수다.

⚖️ 4.4 메모리 할당 효율 비교

SoloDB(SQLite 기반)와 LiteDB의 실측 비교:

💡 참고: SoloDB vs LiteDB 벤치마크

🗄️ 5. Full Query 대안 전략

50만건을 한번에 메모리에 올리는 것이 필요한 경우, 다음 전략을 검토해야 한다:

🔹 5.1 스트리밍 소비 (IEnumerable)

// 나쁜 예 - 전체 실체화 (OOM 위험)
var all = col.FindAll().ToList();  // 전체 메모리 로드

// 좋은 예 - 스트리밍 처리 (메모리 효율)
foreach (var item in col.FindAll())
{
    ProcessItem(item);  // 한 건씩 처리 후 GC 가능
}

메모리 절감 효과: 75~80% (이슈 #865 실측)

🔹 5.2 페이징 읽기

int pageSize = 10_000;
int skip = 0;

while (true)
{
    var batch = col.Find(Query.All(), skip, pageSize).ToList();
    if (batch.Count == 0) break;

    ProcessBatch(batch);
    skip += pageSize;
    batch = null;  // GC 유도
}

🔹 5.3 필드 선택적 조회 (Projection)

// 전체 문서 대신 필요한 필드만 조회
var uids = col.Query()
    .Select(x => x.ModelItemUid)
    .ToList();
// 메시 배열 데이터를 제외하면 메모리 극적 감소

🔹 5.4 SQLite + 스트리밍 (최적 대안)

// SQLite DataReader - 행 단위 커서, 최소 메모리
using var cmd = conn.CreateCommand();
cmd.CommandText = "SELECT * FROM MyMesh";
using var reader = cmd.ExecuteReader();

while (reader.Read())
{
    var uid = reader.GetString(1);
    var vertexBlob = (byte[])reader["vertexList"];
    // 행 단위 처리 → 메모리 사용 최소
}

⚖️ 6. 종합 비교표

⚡ 6.1 Full Query 속도 비교 (500,000건)

⚖️ 6.2 Full Query 메모리 사용 비교 (500,000건)

🔹 6.3 최종 판정

📌 7. 권장사항

🔹 7.1 MyProp 테이블

• LiteDB로도 Full Query 가능하지만, FindAll().ToList() 대신 스트리밍(IEnumerable) 방식 권장
• 전체 메모리 로드가 필수라면 ~500MB 메모리 예산 확보 필요
• SQLite로 전환 시 3~10배 속도 향상 기대

🎮 7.2 MyMesh 테이블

• LiteDB Full Query는 사실상 불가능 (OOM 확실)
• SQLite를 사용하더라도 반드시 스트리밍/페이징 적용 필수
• 최적 전략: SQLite BLOB 저장 + DataReader 스트리밍
• float[] → byte[] 변환 저장으로 직렬화 오버헤드 제거

🏗️ 7.3 아키텍처 제안

[Unity App]
    │
    ├── MyProp (50만건, 경량)
    │     └── LiteDB 또는 SQLite (둘 다 가능)
    │         └── FindAll() 스트리밍 or 인덱스 쿼리
    │
    └── MyMesh (50만건, 대용량)
          └── SQLite (강력 권장)
              ├── 메타데이터 (id, uid) → 일반 컬럼
              └── 메시 데이터 (vertex, index, tri) → BLOB 컬럼 (byte[])
                  └── DataReader 스트리밍으로 건별 처리

🔗 참고 자료

• LiteDB 공식 문서
• LiteDB 데이터 구조
• LiteDB 100만건 조회 10분+ 이슈 #1822
• LiteDB 메모리 3GB 사용 이슈 #865
• LiteDB 200MB 메모리 할당 이슈 #1062
• LiteDB COUNT 쿼리 수 분 소요 #1214
• LiteDB FindAll 루프 감지 버그 #2525
• LiteDB 메모리 사용 이슈 #670
• SoloDB vs LiteDB 성능 비교
• SQLite 성능 튜닝
• SQLite 고성능 최적화
• 임베디드 DB 비교 (SQLite, Realm, LiteDB)
• 로컬 스토리지 성능 비교
• LiteDB-Perf 벤치마크