GAEデータストアクエリに一致するアイテムのページ/アイテムカウント/ナビゲーションを提供するためのアイデア/代替案を探しています

Question

データストアのシンプルさ、スケーラビリティ、使いやすさが気に入っています。そして、新しいもので見つかった強化 NDB 図書館は素晴らしいです。

データストアのベストプラクティスを理解しているため、クエリに一致するアイテムの数が大きい場合、一致するクエリの結果のアイテムおよび/またはページカウントを提供するためのコードを記述しないでください。これを行う唯一の方法は、リソース集中的なすべての結果を取得することだからです。

ただし、当社を含む多くのアプリケーションでは、一致するアイテムのカウントを見て、ユーザーにそれらの結果の特定のページに移動する機能を提供することが一般的な欲求です。データストアのページングの問題は、の制限を回避するための要件により、さらに複雑になります フェッチ（制限、オフセット= x） 記事で概説されているように 大きなデータセットを介したページング. 。推奨されるアプローチをサポートするには、データには、結果の表示方法で注文できる独自の価値のある列を含める必要があります。この列は、結果の各ページの開始値を定義します。保存すると、対応するページを効率的に取得し、要求に応じて特定のページまたは次のページにナビゲーションを付けることができます。したがって、複数の方法で順序付けられた結果を表示する場合は、そのような列をいくつか維持する必要がある場合があります。

SDK v1.3.1の時点で、 クエリカーソル データストアページングを行うための推奨方法です。 INおよび！=フィルター演算子のサポートの欠如など、いくつかの制限があります。現在、私たちの重要なクエリの一部が使用されています の, 、しかし、私たちはそれらを使用してそれらを書くことを試みます また クエリカーソルで使用するため。

提案されたガイドラインに従って、ユーザーに （次） と （前） ナビゲーションボタン、およびナビゲーションが進むにつれて特定のページボタン。たとえば、ユーザーが押した場合 （次） 3回、アプリは次のボタンを表示でき、ナビゲーションを効率的に保つために、それぞれの一意の開始レコードまたはカーソルを覚えています。 （prev）（Page-1）（Page-2）（Page-3）（Page-4）（Next）（次）.

一部の人は、カウントを個別に追跡することを提案していますが、このアプローチは、ユーザーが返された結果を変える豊富なフィールドのセットをクエリすることが許可される場合に実用的ではありません。

一般的にこれらの問題と次の質問についての洞察を探しています。

1. これらの制限を回避するために、DataStoreアプリでクエリ結果のナビゲーションオプションを提供していますか？

2. ユーザーに効率的な結果カウントとクエリ結果セット全体のページナビゲーションを提供することが優先事項である場合、データストアの使用を放棄して有利にしています。 Gae mysqlソリューション 今提供されています。

3. クエリの結果を効率的にカウントするための追加の機能を提供するビッグテーブルアーキテクチャまたはデータストア実装の今後の変更はありますか？

よろしくお願いします。

Answer 1

それはすべて、通常の結果を得る結果に依存します。たとえば、.count（）を渡すことにより、#itemsが<= 100である場合は正確なカウントを提供できます。可能なすべてのカウントを事前に計算することはできないように聞こえますが、少なくともそれらをキャッシュすることができ、それにより多くのデータストアOPSを保存することができます。

NDBを使用すると、最も効率的なアプローチは、fetch_page（）を使用してエンティティの最初のページを要求し、結果のカーソルをcount（）呼び出しの開始点として使用することです。あるいは、最初のページのfetch（）とその非同期施設を同時に使用してcount（）を実行する方がよい場合があります。 2番目のオプションは、クエリがカーソルをサポートしていない場合の唯一の選択肢かもしれません。ほとんどのイン /またはクエリは現在カーソルをサポートしていませんが、注文した場合に行います __key__.

UIオプションに関しては、次のページオプションを提供するだけで十分だと思います。いくつかのページをスキップする余裕がある「goooooogle」uiはかわいいですが、私はそれを自分で使用することはほとんどありません。 （「前のページ」を実装するには、クエリの順序を逆にし、現在のページに使用したのと同じカーソルを使用します。これが機能することが保証されていると確信しています。）

Answer 2

たぶん、このスタイルのページングを目指してください：

（First）（prev）（ページ1）（page2）（page3）....（last）（next）

そうすれば、総数は必要ありません - 別の3ページ以上の結果が十分にあることを知るためにコードのみが必要です。ページ1ページあたり10個のアイテムのサイズで、30個以上のアイテムがあることを知る必要があります。

既に4ページにあるときに60個のアイテム（6ページで十分）がある場合、コードが楽しみにしていて、別の20のレコードしかないことに気付くので、最後のページ番号を表示できます。

（First）（prev）（ページ4）（Page5）（page6）（next）（last）（last）

基本的に、現在のページのフェッチごとに、さらに3ページのデータに十分なレコードを取得し、さらに多くのページを実行しているかを確認してから、それに応じてポケットベルを配置します。

また、キーを取得するだけの場合、追加のアイテムを取得するよりも効率的になります。それがある程度理にかなっていることを願っています!! ?? :)

Answer 3

1. Gmailがいくつかのカウントで準備ができていることに気づきました - それはあなたが受け取った合計電子メールの数、そしてあなたの受信トレイにいくつの電子メールがあるかなどを伝えることができます - しかし、あなたが見ていると言っているフルテキスト検索のように他のカウントで「多くの1-20」または「約130の1-20」。クエリごとにカウントを表示する必要がありますか、それとも重要なものだけを事前に計算できますか？

Answer 4

質問は「ページを提供するためのアイデア/代替案を探している」ことであるため、10ページ相当のKey_onlyアイテムを取得するという非常に簡単な代替品であるため、このセット内でナビゲーションを処理することは検討する価値があります。

同様の質問に答える際にこれについて詳しく説明しました。そこにサンプルコードがあります。

カーソルを使用した後方ページネーションは機能していますが、アイテムがありません

サンプルコードは、この質問に対してより適切です。これがその一部です：

def session_list():
    page = request.args.get('page', 0, type=int)

    sessions_keys = Session.query().order(-Session.time_opened).fetch(100, keys_only=True)
    sessions_keys, paging = generic_list_paging(sessions_keys, page)
    # generic_list_paging will select the proper sublist.
    sessions = [ sk.get() for sk in sessions_keys ]

    return render_template('generic_list.html', objects=sessions, paging=paging)

詳細については、参照されている質問を参照してください。

もちろん、結果セットが潜在的に巨大である場合、フェッチの制限を引き続き指定する必要があります。ハード制限は1000アイテムです。明らかに、結果は約10ページ以上の長さであり、ユーザーは基準を追加して洗練するように求められます。

数百のkeys_onlyアイテム内でのページングを扱うことは、非常に簡単であるため、検討する価値があります。質問で言及されているように、直接ページナビゲーションを簡単に提供できます。実際のエンティティアイテムは実際の現在のページのみフェッチされ、残りはキーのみであるため、それほど費用はかかりません。キー_onlyの結果をMemcacheに数分間設定しておくことを検討して、ユーザーがページをすばやくブラウジングすると同じクエリを再度実行する必要がないようにすることができます。