GAE 데이터 저장소 쿼리와 일치하는 항목의 페이지 / 항목 수 / 탐색을 제공하기위한 아이디어 / 대안을 찾습니다.

Question

데이터 저장소의 단순성, 확장 성 및 사용 용이성이 마음에 듭니다. 새로운 ndb 라이브러리의 향상된 기능은 훌륭합니다.

데이터 저장소 권장 사항을 이해하고 있으므로 쿼리와 일치하는 항목의 수가 많은 경우 일치하는 쿼리 결과의 항목 및 / 또는 페이지 수를 제공하는 코드를 작성해서는 안됩니다. 이렇게하는 유일한 방법은 리소스 집약적 인 모든 결과를 검색하는 것입니다.

그러나 Google을 포함한 많은 애플리케이션에서 일치하는 항목 수를 확인하고 사용자에게 해당 결과의 특정 페이지로 이동할 수있는 기능을 제공하는 것이 일반적입니다. 데이터 저장소 페이징 문제는 대규모 데이터 세트를 통한 페이징 . 권장 방법을 지원하려면 데이터에 결과가 표시되는 방식으로 정렬 할 수있는 고유 한 값이 지정된 열이 포함되어야합니다. 이 열은 각 결과 페이지의 시작 값을 정의합니다. 저장하면 해당 페이지를 효율적으로 가져와 요청에 따라 특정 또는 다음 페이지로 이동할 수 있습니다. 따라서 여러 방식으로 정렬 된 결과를 표시하려면 이러한 열을 여러 개 유지해야 할 수 있습니다.

SDK v1.3.1부터는 쿼리 커서 는 데이터 저장소 페이징을 수행하는 데 권장되는 방법입니다. IN 및!= 필터 연산자에 대한 지원 부족을 포함하여 몇 가지 제한 사항이 있습니다. 현재 중요한 쿼리 중 일부는 IN 을 사용하지만 쿼리 커서와 함께 사용하기 위해 OR 을 사용하여 작성하려고합니다.

제안 된 가이드 라인에 따라 사용자에게 (다음) 및 (이전) 탐색 버튼은 물론 탐색이 진행될 때 특정 페이지 버튼이 제공 될 수 있습니다. 예를 들어 사용자가 (다음) 을 세 번 누르면 앱은 탐색을 효율적으로 유지하기 위해 고유 한 시작 레코드 또는 커서를 기억하는 다음 버튼을 표시 할 수 있습니다. (이전) (페이지 -1) (페이지 -2) (페이지 -3) (페이지 -4) (다음) .

일부에서는 개수를 별도로 추적 할 것을 제안했지만 사용자가 반환되는 결과를 변경하는 다양한 필드 집합을 쿼리 할 수있는 경우이 방법은 실용적이지 않습니다.

이러한 문제에 대한 일반적인 정보와 구체적으로 다음 질문에 대한 정보를 찾고 있습니다.

1. 이러한 제한을 해결하기 위해 데이터 저장소 앱에서 제공하는 쿼리 결과의 탐색 옵션은 무엇입니까?

2. 사용자에게 효율적인 결과 수 및 페이지 탐색을 제공하는 경우 데이터 저장소를 사용해야하는 경우 전체 쿼리 결과 집합의 우선 순위가 현재 제공되는 GAE MySql 솔루션 에 찬성하여 버려집니다.

3. 빅 테이블 아키텍처에 예정된 변경 사항이 있습니까? 추가 기능을 제공 할 데이터 저장소 구현 쿼리 결과를 효율적으로 계산합니까?

   도움에 미리 감사드립니다.

Answer 1

모두 일반적으로 얻는 결과 수에 따라 다릅니다. 예 : .count ()에 적절한 제한을 전달하면 #items가 예를 들어 정확한 개수를 제공 할 수 있습니다. <= 100 및 더 많은 경우 "다". 가능한 모든 개수를 미리 계산할 수는 없지만 최소한 캐시 할 수 있으므로 많은 데이터 저장소 작업을 절약 할 수 있습니다.

NDB를 사용하는 가장 효율적인 방법은 fetch_page ()를 사용하여 엔티티의 첫 번째 페이지를 요청한 다음 결과 커서를 count () 호출의 시작점으로 사용하는 것입니다. 또는 그 대신 비동기 기능을 사용하여 첫 페이지의 fetch ()와 count ()를 동시에 실행하는 것이 더 나을 수 있습니다. 두 번째 옵션은 쿼리가 커서를 지원하지 않는 경우 유일한 선택 일 수 있습니다. 대부분의 IN / OR 쿼리는 현재 커서를 지원하지 않지만 __key__로 주문하면 지원합니다.

UI 옵션 측면에서 다음 및 이전 페이지 옵션을 제공하는 것으로 충분하다고 생각합니다. 여러 페이지를 건너 뛸 수있는 "Gooooooogle"UI는 귀엽지 만 저는 거의 직접 사용하지 않습니다. ( "이전 페이지"를 구현하려면 쿼리의 순서를 바꾸고 현재 페이지에 사용한 것과 동일한 커서를 사용하십시오. 이것이 작동하는 것이 확실합니다.)

Answer 2

다음 스타일의 페이징을 목표로 할 수 있습니다.

(처음) (이전) ( 1 페이지 ) (2 페이지) (3 페이지) .... (마지막) (다음)

그러면 총 수가 필요하지 않습니다. 다른 3 개 이상의 페이지에 대해 충분한 결과가 있는지 알기 위해서는 코드 만 있으면됩니다.페이지 당 10 개 항목의 페이지 크기를 사용하는 경우 30 개 이상의 항목이 있다는 것만 알면됩니다.

60 개의 항목이있는 경우 (6 페이지에 해당) 이미 4 페이지에있는 경우 코드는 앞으로 갈 레코드가 20 개뿐임을 인식하고 마지막 페이지 번호를 표시 할 수 있습니다.

(처음) (이전) ( 4 페이지 ) (5 페이지) (6 페이지) (다음) (마지막)

기본적으로 현재 페이지를 가져올 때마다 다른 3 페이지의 데이터에 대해 충분한 레코드를 가져 와서 실제로 가지고있는 페이지 수를 확인한 다음 그에 따라 호출기를 표시합니다.

또한 키만 가져 오면 추가 항목을 가져 오는 것보다 더 효율적입니다. 그게 말이 되길 바랍니다 !! ??:)

Answer 3

1. Gmail은 몇 가지 계산을 통해 준비된 것으로 나타났습니다. 수신 한 총 이메일 수와받은 편지함에있는 이메일 수 등을 알려줄 수 있지만 전체 텍스트 검색과 같은 다른 계산에서는 다음과 같이 말합니다."1-20 of many"또는 "1-20 of 약 130"을 다시보고 있습니다.정말 모든 쿼리에 대한 개수를 표시해야합니까? 아니면 중요한 쿼리 만 미리 계산할 수 있습니까?

Answer 4

질문이 "페이지 제공에 대한 아이디어 / 대안을 찾는 것"이었으므로 아마도 10 페이지 분량의 key_only 항목을 가져 오는 매우 간단한 대안이 될 수 있습니다. 그러면이 세트 내에서 탐색을 처리하는 것이 좋습니다.

비슷한 질문에 대한 답변으로 이에 대해 자세히 설명했습니다. 여기에서 샘플 코드를 찾을 수 있습니다.

커서로 뒤로 페이지 매기기는 작동하지만 항목 누락

이 질문에는 샘플 코드가 더 적합합니다. 다음은 그 중 일부입니다. 라코 디스

더 많은 코드는 참조 된 질문을 참조하세요.

물론 결과 집합이 잠재적으로 큰 경우 가져 오기에 대한 일부 제한을 여전히 제공해야하며 하드 제한은 1,000 개 항목으로 제한됩니다. 당연히 결과는 약 10 페이지 이상이며 사용자는 기준을 추가하여 수정하라는 요청을 받게됩니다.

수백 개의 keys_only 항목 내에서 페이징을 처리하는 것은 매우 간단하므로 고려할 가치가 있습니다. 질문에서 언급했듯이 직접 페이지 탐색을 제공하기가 매우 쉽습니다. 실제 항목 항목은 실제 현재 페이지에 대해서만 가져오고 나머지는 키일 뿐이므로 비용이 많이 들지 않습니다. 또한 사용자가 페이지를 빠르게 탐색 할 때 동일한 쿼리를 다시 수행 할 필요가 없도록 몇 분 동안 memcache에 keys_only 결과 집합을 유지하는 것을 고려할 수 있습니다.