2011-02-02 5 views
3

データベースには約2,500,000行(約3GB)のテーブルがあります。 WCFを使用してこのデータを照会するSilverlightアプリケーションでこのテーブルのデータを表示することは技術的に可能ですか?潜在的に、最大バッファサイズとタイムアウトエラーに関する問題があります。私たちは、可視化の目的でデータ全体を使用する必要があるかもしれません。WCFのパフォーマンス

この問題の実際の解決策がある場合は、私に案内してください。

+4

3GBのデータを一度に表示する必要がありますか? Silverlightがクライアント上で実行されていることを理解していますか?単にネットワーク経由で3GBのファイルをコピーしようとすると、WCFが遅いと想像してください。このように動作しないことがわかります。 –

答えて

7

でクライアントに3ギガバイトを動かすことをやっていることは仕事に行くのではありません。

です。

視覚化サーバー側をよりよく準備します。それは十分に遅いでしょう。

+0

はい、遅くなります。私たちはそれを認識します。ユーザーは過去35年間の過去のデータを表示するチャートのようなGoogleファイナンスを求めていました.Google Financeチャートもインタラクティブで、銀色を使用して複製しようとしています。 – JohnC

+0

それでも、それを分ける必要があります。 SLクライアントはUIであり、ユーザー規模でデータを保持/ロードします。 –

+1

@JohnC:しかし、Google Financeのチャートはサーバー上で処理されます。 FirefoxとFirebugをインストールし、Netタブを使用して、転送されたデータの量を確認します。私はBroadcom Corporationを閲覧しただけで、転送されたデータ211KBで動作します。グラフをズームしたりスクロールしたりすると、動的に再クエリー(AJAX)することができます。実際に表示されているデータの量だけで動作します - btw。あらゆる視覚化において不可欠です。 –

2

まずはhereをご覧ください。

ディスクからディスクに3GBのデータを転送すると、ネットワークを横断しても、かなりの時間がかかります。私はあなたが揚げるために大きな魚を持っていると思う - WCFの制限はここでは無関係です。

だから、数分後にデータを取得したとしましょう。どこに保存しますか?ブラウザ内で実行している場合、Silverlightアプリは3GB(64ビットマシンでも)に成長することはできませんし、それでも可能ではありません。特に、オブジェクトに変換されたときのデータの量は、より多くのスペースを必要とします。ここで

は、私がどうなるのかです:

  • は、サーバは、例えば、有益であるデータのスナップショット/ビューを提供するには、Get要約、OLAPキューブを提供します。
  • 各レコードについて、必要な最小限のデータを提供してください。
  • あなたは、各レコードに詳細が必要な場合は、別のコール
1

まあ、私は信じて、同じリストに2,5百万行を表示しないことをお勧めします。

データの良好なページングを開発し、データをクエリする方法が最適な場合は、WCFで問題が見つかりません。

インフラストラクチャへのスタンドアロンの直接アクセスよりも効率的なWCFインターフェイスを使用してデータを照会することに同意しますが、SOAソリューションにアクセスするために一部のビジネスデータとNクライアントをホストする必要がある場合それはクライアント/サーバーソリューションであるため、クエリが効率的であることを確認する必要があります。

提案:

  • OR/Mを使用してください。 NHibernateは、NHibernate 3.0のQueryOver APIを使用したLINQサポートのために、パフォーマンスを調整したり、ページングを簡単にする方法がたくさんあるので、最良の選択となります。この製品は非常に興味深いキャッシング方式を採用しており、アプリケーションで2,5百万行のデータベースを効率的に視覚化できます。

  • キャッシングを実行します。 NHibernateはこの分野であなたを助けてくれるかもしれませんが、それについて考えると、クライアント技術(Web、Windowsなど)によっては、プレゼンテーションビューをキャッシュするための良いオプションがあります(ASP.NET出力キャッシングなど)。

  • WCFのオブジェクトをシリアル化する方法について考えてみましょう:SOAPまたはJSON?シリアライズされたオブジェクトはネットワークのトラフィックを節約するために十分小さいため、JSONに興味があるかもしれません。

質問がある場合は、コメントアウトしてください。

4

通常、この種の状況では、個々のレコードを表示する必要がある場合は、ページング戦略を使用します。したがって、あなたのWCFへの呼び出しは1ページ分のレコードになり、そのレコードを表示し、ユーザーは次/前のボタンなどをクリックします。

視覚化に関しては、250万のレコードが画面上に1ピクセルあたり1データポイントを表示するのと同じように、サーバー上で変換/縮小を行う必要があります。

0

多くのユーザーが、あなたが技術的に何をしているのかを話した後、あなたがそこにいると思っていない感覚は何ですか?

  • 250万行はグリッドに意味をなさない。ゼロ。 1ページに80行(幅広いsdcreen、90度傾けられている)、31250ページ分のデータが表示されます。あなたは特定のページにscrippすることさえできません。ロード時間を無視してもIF(!)をロードするなど、グリッド内にこの量を入れるのは意味がありません。それをフィルタリングして、ページワイズに必要なものをロードします。しかし、ここで重要なのは、ユーザーがグリッドについて考える前にフィルタリングするように強制することです。一度あなたがそれらを覚えたら、グリッドのパフォーマンスを取り消すことはできません。

  • これがどれほど悪いかを示します。グリッドを取得します。 ONE PIXELまたはすべてのデータ項目を割り当てると、データを表示するために1024×768ピクセルの1.33画面が表示されます。これはアイテムごとに1ピクセルです。

ので、(不可能であるが)、この作業を取得するために管理する場合でも、一日の終わりに、あなたは非無意味/非使用可能なapplciationで終わります。

関連する問題