architecture - 3 層パターンと大量のデータ

Question

これが私の状況です。3 層パターン (つまり、プレゼンテーション層、ビジネス層、データ層) にできるだけ従おうとしています。DB からのデータが必要な場合、ビジネス層は情報を返すデータ層を呼び出します。データ層は SqlDataReader または DataTable オブジェクトを返すことはありませんが、多くの場合、データアクセス層によって認識されるカスタムオブジェクトの列挙を返します。データレイヤーがオブジェクトの少ないリストを返す必要がある場合、これは非常にうまく機能します。

私は現在、この問題に直面しています。アプリケーション (ビジネス層) は 500000 レコードを処理する必要があります。データレイヤーに別のメソッドを追加して IEnumerable を返すこともできますが、これは非常に悪いように思えます。メモリに 50 万件のレコードをロードしたくありません。

私の質問は、3 層モデルを考慮して、このケースをどのように処理すればよいですか? 3 層パターンがなければ、単純にビジネスクラスで SqlDataReader を使用します。助言がありますか？

UPDATE : データは表示されないため、これはページングの問題ではありません (ここではプレゼンテーション層はまったく関係ありません)。各レコードを分析し、それらの一部を保持するだけです。

ありがとう

score 2 · Accepted Answer

フロントエンドに一度に 500,000 件のレコードを表示していないと思いますか? あなたはおそらくページネーションを行っていますよね？そのため、データベースから一度に 1 ページ分のデータのみを返します。

score 1 · Accepted Answer

はい、あなたの本能は正しいです。

あなたの UI クライアントは、一度に 50 万件のレコードを表示したくないに違いありません。Google は 1 つのページにすべてのヒットを返すわけではありません。あなたもそうしません。

アプリケーションがこれらの 50 万件のレコードをいつどこで処理するかを選択できます。それらを小さな作業単位にチャンクできます。それらを非同期に処理できます。ストアドプロシージャを作成し、それらをすべて中間層に持ち込むことなく、データベースで処理できます。

MVC パターンは素晴らしいですが、それは聖なる令状ではありません。アプリに適した選択を行ってください。

score 1 · Accepted Answer

場合によっては、3 層の境界を破る必要があります。しかし、そうする前に、次のことを自問してみてください。

「各レコードを分析し、その一部を保持する」場合、それは本当にビジネスロジックの一部ですか? それともデータアクセス機能ですか？これは、データアクセス層に属している可能性があります。
ビジネスロジックの一部である場合、個々のレコードを「保持」するかどうかを決定するために、500000 件すべてのレコードが必要ですか? ビジネス層が一度に 1 つのレコードを処理する必要がある場合があります。500000 回連続してデータベース呼び出しを行うのは適切ではありませんが、概念的な観点からアプリが行うべきことである場合は、それを軽減する方法があります。

3 つの層を分離しておくためだけに愚かなことをすることはお勧めしません。しかし、一線を越えなければならないと思うとき、それはデザインに再検討が必要な何かがあるからです。

--
bmb

score 1 · Accepted Answer

データベースでフィルタリングを行います。いずれにせよ、除外する 500000 を超えるレコードを持ち込む必要はありません。それらを削除するためだけに、それらすべてを中間層に移動するのはなぜですか。バックエンド (sproc) で SQL エンジンを使用して、操作 (データ) をできるだけ早く処理します。IIS に送信する前に、プレゼンテーション層で基本的な入力チェックをチェックするのと同様に、最も効率的です。

score 1 · Accepted Answer

一枚の紙が現実を打ち負かすことはできません。あなたの特定の問題が 3 層のパラダイムを破る必要がある場合は、それを実行してください。

score 1 · Accepted Answer

SqlReader クラスの上に抽象化を構築できます。そうすれば、SqlReader を直接渡す必要はありませんが、一度に 1 つずつオブジェクトを処理できます。

イテレータを考えてください。

score 0 · Accepted Answer

データベースレベルで必要な分析を行うのは恥ずべきことではありません。ストアドプロシージャで必要なものをスライスしてダイスするか、ストアドプロシージャと必要な相関関係を作成し、より複雑な操作にアプリケーションを使用できる場合は、問題ないはずです。

問題は、ユーザーがボタンを押してすべての500Kレコードを処理し、結果を確認することを期待しているのかということです。もしそうなら、彼らは座って回転するgifを見て喜んでいますか、それともプロセスが完了したときに何らかの種類の通知を受け取っても十分ですか？500Kの処理が最も重要な場合、このプロセスをサポートするためにデータモデルを変更する必要がありますか？この大量の処理を対象としたHadoopやメッセージキューなどの処理方法がありますが、この程度まで実行する必要がありますか？パフォーマンスよりも髪の毛を抜く前に、ユーザーの期待を設定できる場合があります。

score 0 · Accepted Answer

私がこれを正しく理解している場合は、レコードを「分析」してから、一部を保持し、残りを削除する必要があります。その場合、データベース自体 (PL/SQL または T/SQL) 内でこれを処理するのが最善だと思います。このような要件は、アーキテクチャではなく最優先事項であるべきです。分析するだけで表示しているわけではないので、手順自体で行うのが最善です。

score 0 · Accepted Answer

これは珍しい問題ではなく、大量のデータを統合してユーザーに要約を提示する必要がある状況で頻繁に発生します (レポートは典型的な例です)。ソリューションは、これらの考慮事項を念頭に置いて設計する必要があります。特定のアーキテクチャモデルへの厳密な一貫性によってアプリケーションが非効率になる場合、SQL リーダー (または同様のツール) によって提供される効率を無視するのは意味がありません。多くの場合、これらの問題のいくつかは、アーキテクチャモデルをニーズに適合させることで解決できます。一般的なアーキテクチャモデルがすぐに適用できることはめったにありません。これらは、特定のニーズに適用する必要があるガイドラインです。

architecture - 3 層パターンと大量のデータ

9 に答える 9

Related

Reference