2012-04-01 12 views
11

データベースからフェッチした従業員テーブルに1つのクエリで3000レコードがあります。 1ページに20レコードを表示できます。したがって、各ページには20レコードを表示するための150ページがあります。ページング/ソート可能な列のためのウェイ(クライアント側またはサーバー側)?

1)ソート可能な列を持たない単純なページネーションを実装する場合は、3000レコードすべてをクライアントに送信して、javagriptまたはjqueryを使用してページ分割クライアント側を実行する必要があります。したがって、ユーザーが2番目のページをクリックすると、コールはサーバー側に送られず、より高速になります。 ブラウザ/クライアント側で3000以上のレコードを送信した場合の影響はどうなるでしょうか?ですから、一度にクライアントにすべてのレコードを送信し、そこをソートするか、またはページをクリックして、サーバー側にコールを送信し、その特定のページの結果を返すベスト・アプローチは何ですか?

2)このシナリオでは、ページングとソート可能な列(6列)を提供する必要があります。だからここでユーザーは従業員名や部門名のような列をクリックすることができます。名前は昇順または降順に並べる必要があります。 もう一度、タイム・レスポンス/メモリーの観点から最良のアプローチを知りたいですか?

+0

意味のあるデータの3000件のレコードを送信する効果が大幅にクライアントのブラウザが遅くなります。私はサーバー側をページ付けしたいと思う。 – Brad

+0

私は、どのように大きなデータセットがブラウザのパフォーマンスに影響を与えるか考えていません。あなたの答えのように見える3000以上のレコードはブラウザで処理するのが難しいでしょう。それは...ですか? –

+0

質問:「次の20件の結果を見る確率/頻度は?それが低い場合は、サーバー側にページを貼り付けます。中等度の場合、まだサーバー側、ペナルティの価値がある。高い場合は、STILLサーバ側のボトルネックとクライアント側の処理は、それだけの価値がないかもしれませんので、:)あなたはいつも:) – PhD

答えて

7

クライアントへのデータ送信は、ほとんどの場合、ボトルネックになりがちです(特にモバイルクライアントの場合)。できるだけデータを送信しないようにしてください。これで、サーバー側でページ分割を行うのがほぼ確実です。これははるかにスケーラブルなソリューションです。データの量が増える可能性が高いので、将来的にはサーバ上でページネーションを実行する方が安全です。

また、すべてのユーザーが実際に何百もの結果ページを調べることはほとんどありませんので、すべてのデータを転送するのは無駄かもしれません。 Thisはあなたのための適切な読書かもしれません。

+1

私はどのように大きなデータセットがブラウザのパフォーマンスに影響を与えるか考えていません。あなたの答えのように見える3000以上のレコードはブラウザで処理するのが難しいでしょう。それとも、私は基本的にはDeskop /ラップトップクライアントをモバイルクライアントではないと考えているだけです。 –

+0

ブラウザはデータを(おそらく)扱うことができますが、通常はネットワーク速度がアプリケーションの中で最も遅く、数桁の大きさ。あなたが送る余分なデータは非常に高価です。 – Oleksi

+1

その場合、resposeは初めて(私が3000レコードを一緒に送信しているときだけ)遅くなります。しかし、クライアントサイドでデータを再生することができるので、ユーザーが次のページに行くほうが速くなります(サーバーに行く必要はありません)。再び同じ質問:)。どちらがクライアント側かサーバー側のどちらが良いですか(おそらく、ユーザーが少ないページを経由してサーバー側に行く可能性が低いシナリオに依存しますが、多数のページを通過する可能性が高い場合はクライアント側に行くことができます)。実際には、これらの種類の詳細な分析を探しています。 –

1

あなたは、このテーブルにレコードを表すBeanクラスがあり、インスタンスはどのORMでもロードされているものとします。

まだお持ちでない場合は、これらのBeanのキャッシュをアプリケーションに実装する必要があります。これはおそらくGuavaのCacheBuilderを使用してローカルで行うことも、Memcachedなどの呼び出しをリモートから行うこともできます(後者は複数のアプリケーションサーバー/負荷分散に必要です)。これらのBeanのキャッシュは、一意のID、おそらく対応する表の主キー列へのマッピングに基づいてキーを設定する必要があります。

ページングの取得:選択したレコードのIDのみを返すようにクエリを書き込むだけです。 LIMITOFFSETを含むか、DB言語のページネートに相当します。クエリの呼び出し側はまた、

戻るのJava層のソートで、ORDER BYなどWHEREを使用します/フィルタリングこれらのクエリの結果のIDを反復処理し、キャッシュを呼び出すことにより、豆のあなたのListを構築することができます。キャッシュがミスした場合は、ORMを呼び出して、そのBeanを個別に照会してロードします。 Listがビルドされると、処理/シリアル化されてUIに送信されます。

1

これはクライアントとサーバー側のページ付けに直接応答しないことがわかっていますが、DataTables.netを使用してデータの表示とページ設定を行うことをお勧めします。それは非常に素晴らしいディスプレイを提供し、並べ替えとページネーション、検索機能に組み込まれています。私が初めて使ったのは、最初のWebプロジェクトでした。完全なnoobieとして、私はそれを働かせることができました。フォーラムはまた、非常に良い情報/ヘルプを提供し、作成者はあなたの質問に答えます。 DataTablesは、クライアント側とサーバー側の両方で使用でき、何千もの行をサポートできます。 スピードに関しては、数百行しかありませんでしたが、クライアント側の処理を使用して、遅延に気付かなかったのです。

+0

固体生成物。 DTを使用しない場合でも、さまざまなユースケースとデモを学ぶことができます。トピックの質問に直接答えることができます。「...大規模なデータベースで作業している場合は、 DataTablesは提供しています。スケーリングの懸案事項に対処するために大量の理論に頼っています。それ以外の場合は、クライアントサイドのデモをチェックしてください。 –

1

使用するサーバーPAGINATION!

確かに、あなたはおそらく3000個の要素のJSON配列を下に送信し、クライアント上のページ/ソートにJavaScriptを使用して逃げることができました。しかし、良いWebプログラマーは、サーバー上のレコードをページングしソートする方法を知っている必要があります。 (彼らは実際にいくつかの方法を知っているはずです)。したがって、それを良い習慣と考えてください:)

滑らかなユーザーインターフェイスが必要な場合は、AJAXを使用してデータをフェッチするJavaScript grid componentを使用することを検討してください。一般的に、これらのコンポーネントは、以下のパラメータ(またはそれらのいくつかの変種)をバックパス:レコードの

  • 録音開始インデックス
  • 番号を取得するために
  • 並べ替えるには、列
  • ソート方向
  • 列を返すために(時々)

これらの入力pに基づいて結果セットを返すハンドラまたはインターフェイスを実装するのは開発者次第ですarameters。

+0

dana返信ありがとうございます。サーバ側のページネーションがより良い選択肢であることは、すべての回答のように見えます。しかし、なぜサーバ側が良い習慣をしているのかを明確にしたいのであれば、サーバ側ではなくクライアント側でページ分割とソートを行うと何が影響を受けるのかを知りたい。私はそれがなぜagoodオプションではないのかを意味します。そのような巨大なデータのために、ネットワークやブラウザ上でこのような巨大なデータを転送するのに時間がかかるためですか? –

+0

どこかのバランスがあると思います。ハッシュテーブルとリンクリストを考えてみましょう。小さなレコードセットの場合、リンクされたリストは正常に動作します。しかし、レコードセットのサイズが大きくなるにつれ、ハッシュテーブルが手に入ることになります。同じことがページングにも当てはまります。クライアント側の作業は小さなレコードセットになりますが、レコードセットのサイズが大きくなるにつれて、ますます多くのデータ量が送信され、少数のレコードしか表示されません。 – dana

+1

一番下の行はサーバーサイドページング* SCALES *です。あなたのアプリは最初からうまくいくかもしれませんが、データベースがより多くのレコードを取得するにつれて、レコードセット全体をクライアントにストリーミングするのに時間がかかります。つまり、決してあまりにも多くのレコードを取得することはできませんし、クライアント側のページネーションは常に実行される状況があります。しかし、サーバー側のページングに関してあなたのために働くパターンを開発すれば、それは長期的にはるかに柔軟になります。 – dana

関連する問題