포스트그레스 FTS 쿼리 페이지 매기기

Question

FTS 쿼리를 페이지 매기기하는 가장 좋은 방법은 무엇입니까? LIMIT 및 OFFSET 봄을 생각하십시오. 그러나 한계 및 오프셋을 사용하여 동일한 쿼리를 반복해서 (예 : 한 페이지에 대해 한 번, 두 번 페이지에 대한 다른 시간 등) 반복적으로 실행하게되었습니다.

PostgreSQL은 쿼리 결과를 투명하게 캐시 할만큼 똑똑합니까? 따라서 캐시에서 페이지 매김 질의를 만족 시키는가? 그렇지 않은 경우 효율적으로 페이지 매기기를 수행하려면 어떻게해야합니까?

편집

데이터베이스는 단일 사용자 데스크탑 분석입니다. 그러나이 OLTP 응용 프로그램이 라이브 일 경우 가장 좋은 방법이 무엇인지 알고 싶습니다. 필자는 과거에 문서 ID의 정렬 된 집합을 만들고 별도의 테이블에있는 ID에 대해 쿼리 매개 변수를 캐시함으로써 SQL Server의 문제를 해결했습니다. 새 문서가 결과 집합에 들어갈 수 있도록 몇 시간마다 캐시를 ​​지우십시오.

아마도이 접근법은 포스트그레스에 대해 실행 가능합니다. 하지만 여전히 데이터베이스에 존재하는 메커니즘과이를 활용하는 최선의 방법을 알고 싶습니다. DB 개발자라면 쿼리 응답 캐시를 FTS 시스템과 함께 사용할 수 있습니다.

Answer 1

글쎄, 솔직히 말해서 쿼리가 라이브 커서를 반환하고 커서 (Cursor)가 나타내는 결과의 특정 부분을 가져 오는 데 다시 사용할 수 있습니다. 이제 PostGre가 이것을 지원하는지 Mongo DB가 지원하는지 모르겠다. 그리고 나는 그 길로 내려 가려고했지만 멋진 것은 아니다. 예를 들어, 쿼리가 완료되고 그 쿼리의 결과 중 두 번째 페이지가 요구 될 때까지 어느 정도의 시간이 경과하는지 알고 있습니까? 커서가 그 시간 동안 계속 머물 수 있습니까? 할 수 있다면 정확하게 의미하는 바는 리소스를 차단할 것인가? 많은 게으른 사용자가 쿼리를 시작하지만 페이지를 탐색하는 데 오랜 시간이 걸리면 서버가 잠긴 커서에 의해 다운 될 수 있습니다.

솔직히 누군가가 특정 페이지를 요청할 때마다 페이지가 매겨진 쿼리를 다시 실행하는 것이 좋습니다. 우선, 적은 수의 항목을 반환 할 것이고 (한 번에 10-20 개 이상의 항목을 표시 할 필요가 없음) 꽤 빠를 것입니다. 둘째, 서버를 조정해야합니다. 느린 속도로 실행하지만 캐싱하지 않고 자주 요청을 빠르게 실행 (인덱스 추가, 필요하면 서버 뒤에 넣기 등)합니다. 당신이 정말로 전체 텍스트 검색 속도를 원하고, 대소 문자를 구별, 접두사와 활성화 접미사 등 같은 공상 인덱스가있는 경우

마지막으로, (스테로이드에 루씬 인) 아직 더 나은 Solr을 Lucene에서 살펴 또는한다 사용자와 지속성 계층 간의 중간 검색 및 인덱싱 솔루션입니다.

Answer 2

서버 측 SQL 커서 효과적으로 전체 세션 동안 열려있는 특정 DB 연결에 연결 할 수있는이 경우 클라이언트 세션에 사용할 수 있습니다. 커서가 다른 연결간에 공유 될 수 없기 때문입니다. 하지만 실행중인 인스턴스마다 고유 한 연결을 가진 데스크톱 응용 프로그램이라면 괜찮습니다.

DECLARE CURSOR에 대한 문서는 커밋 된 트랜잭션에서 커서가 WITH HOLD으로 선언 될 때 결과 집합이 어떻게 구체화되는지 설명합니다.

잠금은 전혀 문제가되지 않습니다. 커서가 이미 구체화되어있는 동안 데이터가 수정되면 판독기에 영향을 미치지 않고 작성기를 차단하지 않습니다.

그 외의 경우에는 PostgreSQL에 암시 적 쿼리 캐시가 없습니다. LIMIT/OFFSET 기술은 각 페이지에 대한 쿼리의 새로운 실행을 의미합니다. 이는 실행 계획의 복잡성과 버퍼 캐시 및 디스크 캐시의 효율성에 따라 초기 쿼리만큼 느릴 수 있습니다.