# 확장 및 한도

storh는 관계형 쿼리 엔진이 아니라 파일 우선 저장소입니다. [벤치마크](https://storh.inline0.dev/ko/docs/benchmarks)의 수치(레코드 50k, Apple M1 Pro)를 기준으로 한 실용적 한도는 다음과 같습니다:

- 파일 시스템이 파일 수를 감당할 수 있고 컬렉션이 UUID-tail 샤딩을 사용한다면 개별 항목 접근에는 사실상 한도가 없습니다. 단일 레코드 읽기에는 몇 마이크로초가 걸리고, 내구성 있는 단일 레코드 쓰기는 fsync에 묶여 초당 수천 건 정도입니다.
- 세그먼트 크기를 워크로드에 맞게 설정하면 분할 로그 스캔, 커서 읽기 및 시간 범위 읽기는 대략 1M 레코드까지 원활합니다. 대량 추가는 초당 수만 건이며, 잘린 꼬리 복구는 재시작 시 초당 수십만 건의 레코드를 재생합니다.
- 큐 작업은 압축된 이벤트를 하나의 내구성 있는 로그에 추가하므로, 큐에 넣기, 가져오기, 완료, 재대기열 등록 및 제거 과정에서 작업별 파일로 인한 디렉터리 변경이 발생하지 않습니다. 대량 가져오기와 완료는 여러 배치에 잠금과 fsync 비용을 분산합니다.
- `DocStore`의 파일별 필드 스캔은 약 10k 레코드를 넘으면 느려집니다. 일치하는 항목을 스캔할 때마다 개별 파일을 순회하기 때문입니다. 필터링할 필드에 [인덱스](https://storh.inline0.dev/ko/docs/indexes)를 선언하면 인덱스 동등성 쿼리가 컬렉션 크기와 관계없이 약 1밀리초 안에 결과를 반환합니다.
- storh는 임의의 관계형 쿼리, 조인, 보조 인덱스가 많은 필터링 또는 다수 필드에 대한 분석 스캔용이 아닙니다. 이런 읽기 패턴이 필요하면 컬렉션을 [SQL 미러](https://storh.inline0.dev/ko/docs/sql-mirror)로 보내세요. 여러 레코드에 걸친 트랜잭션이 필요하다면 실제 데이터베이스를 기준 시스템으로 유지하세요.

개별 항목 읽기가 많다면 `DocStore`, 추가 및 정렬된 읽기가 많다면 `SegmentedLog`, 간단하고 내구성 있는 작업 디스패치에는 `Queue`를 사용하세요. 나란히 비교하려면 [엔진 선택](https://storh.inline0.dev/ko/docs/engines#choosing-an-engine)을 참고하세요.