확장 및 한도

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

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

개별 항목 읽기가 많다면 DocStore, 추가 및 정렬된 읽기가 많다면 SegmentedLog, 간단하고 내구성 있는 작업 디스패치에는 Queue를 사용하세요. 나란히 비교하려면 엔진 선택을 참고하세요.