Lakebase Search 리소스 산정: 실제 앱과 400만 개의 패스지에서 얻은 교훈
영어 원문을 AI가 번역했습니다. 영어로 보기
벡터 인덱스 크기에 맞춰 Local File Cache를 구성하면 페이지의 최대 98%를 메모리에 유지할 수 있으며, Lakebase Postgres 내부에서 웜 상태의 벡터 검색 지연 시간을 한 자리 수 밀리초로 단축합니다. 검색 후보 풀을 200개로 줄이면 상위 10개 결과의 90.5%를 유지하면서 페이지 읽기를 3분의 2로 줄일 수 있으며, 상시 가동되는 0.5 CU 최소 사양을 통해 월 31~31~40달러로 최적의 운영 기준선을 제공합니다.
* Lakebase Search는 애플리케이션 데이터베이스 내에서 Postgres 확장 기능으로 벡터 검색 및 BM25 키워드 검색을 실행하므로, 개발자는 별도의 검색 시스템이나 두 번째 트랜잭션 경로를 유지 관리할 필요 없이 하이브리드 검색을 사용할 수 있습니다. * 벤치마크에 따르면 Local File Cache 크기를 벡터 인덱스와 대략 일치시키면 페이지의 95~98%를 메모리에 유지하여 웜 상태의 벡터 검색 지연 시간을 한 자리 수 밀리초로 낮출 수 있습니다. 또한 후보 풀을 1,000개에서 200개로 줄이면 페이지 읽기를 3분의 1 수준으로 줄이면서도 상위 10개 결과의 90.5% 정확도를 유지할 수 있습니다. * Lakebase Postgres는 실행되는 동안에만 컴퓨팅 비용이 청구되며, 10만 9천 건의 요청을 처리한 14분간의 부하 테스트에서 Lakebase Postgres 컴퓨팅 비용이 단 0.02달러에 불과했습니다. 따라서 콜드 스타트를 방지하기 위한 월 31~40달러의 상시 가동 0.5 CU 사양이 권장 프로덕션 기준선입니다.