모듈 평가

1.

1,536차원 포함 200만 개의 벡터 검색 워크로드에 대해 PostgreSQL을 튜닝하고 있습니다. 쿼리가 느리고 캐시 적중률이 85%관찰됩니다. 우선 순위를 지정해야 하는 구성 변경은 무엇입니까?

PostgreSQL 캐시에 데이터를 더 많이 유지하도록 shared_buffers 늘리기

random_page_cost을 줄여 더 많은 인덱스 검사를 장려합니다.

인덱스 파티션을 더 많이 검색하려면 ivfflat.probes을(를) 늘리세요.

2.

잦은 일괄 업데이트(매일 전체 새로 고침)를 수신하는 5백만 개의 제품 포함 데이터 세트에 대한 벡터 인덱스를 만들어야 합니다. 빌드 시간은 30분 미만이어야 합니다. 어떤 인덱스 구성을 선택해야 하나요?

sqrt(행)로 설정된 목록이 있는 IVFFlat

m=16 및 ef_construction=64가 있는 HNSW

m=8 및 ef_construction=32가 있는 HNSW

3.

필터링된 벡터 검색 쿼리는 벡터 유사성별로 category_id 필터링한 다음 정렬합니다. 쿼리 계획은 제품 테이블에 대한 순차적 검사를 보여 줍니다. 먼저 무엇을 확인해야 하나요?

category_id 열에 B-트리 인덱스가 존재하는지 확인합니다.

벡터 인덱스가 쿼리와 동일한 연산자 클래스를 사용하는지 확인합니다.

hnsw.ef_search을(를) 증가시켜 검색 공간을 확장하십시오.

4.

트래픽이 가장 많은 동안 초당 500개의 벡터 쿼리를 만드는 AI 애플리케이션에 대한 연결 관리를 구현하고 있습니다. Azure Database for PostgreSQL 인스턴스는 최대 1,719개의 연결을 지원합니다. 어떤 접근 방식을 사용해야 할까요?

애플리케이션 인스턴스에 적합한 풀 크기로 트랜잭션 모드에서 PgBouncer 사용

각 쿼리 요청에 대한 새 데이터베이스 연결 만들기

세션 모드에서 PgBouncer를 사용하도록 설정하여 영구 연결 유지

5.

현재 범용 8 vCore 인스턴스에서 실행 중인 추천 엔진의 규모를 확장하고 있습니다. CPU 사용률은 평균 75% P95 쿼리 대기 시간은 150ms이지만 50ms 미만의 대기 시간을 달성해야 합니다. 먼저 어떤 크기 조정 방법을 시도해야 하나요?

더 많은 vCore를 사용하여 메모리 최적화 계층으로 업그레이드

읽기 복제본을 추가하여 쿼리 로드 분산

Azure Cache for Redis를 사용하여 애플리케이션 수준 캐싱 구현

피드백