1

私の現在のプロジェクトでは、ビジネスロジックはストアドプロシージャ（1000以上）に実装されており、ビジネスの成長に合わせてスケールアップしたいと考えています。アーキテクトは、パフォーマンスとスケーラビリティを向上させるために、ビジネスロジックをアプリケーション層（.net）に移動することを決定しました。しかし、彼らは何も再設計/書き直していません。つまり、SPから起動される同じSQLクエリは、ADO.Netを使用して.net関数から起動されます。これはどのようにパフォーマンスを生み出すことができますか？

私の理解する限りでは、DBに依存しない必要がある場合、またはRDBMSエンジンよりもOOP言語でより適切に実装できるビジネスロジックがある場合（階層のトラバースや画像処理など）、ビジネスロジックをアプリケーション層に移動する必要があります。等..）。残りの場合、実装する複雑なビジネスロジックがない場合は、ビジネスロジックをDB自体に保持する方がよいと思います。少なくとも、アプリケーション層とDBの間のネットワーク遅延はこの方法で回避できます。

ご意見をお聞かせください。私は少しためらってアーキテクチャの決定を検討している開発者です。この件についての私の無知を許してください。

4

4 に答える 4

1

このようなアーキテクチャの議論では、多くの場合、多くのトレードオフを検討する必要があり、パフォーマンスを個別に検討するか、応答時間などのパフォーマンスの 1 つの側面のみを考慮すると、全体像を見落とす傾向があります。

データベース層でロジックを実行することと、データをアプリケーション層に送り返してそこで処理することの間には、明らかにトレードオフがあります。データ送信コストと処理コスト。ビジネスロジックのコストと複雑さが重要な要素になることを示しているように、出荷されるデータのサイズは別のものになります。

DB 層がビジー状態になった場合、別の層に処理をオフロードすることで、個々の応答時間が増加しても全体のスループットが向上する可能性があると考えられます。次に、余分な負荷に対処するために、アプリケーション層をスケーリングできます。パフォーマンスが改善された (全体的なスループットが向上した) か、悪化した (応答時間が少し増加した) と思いますか?

ここで、アプリ層が興味深いキャッシュ戦略を実装する可能性があるかどうかを検討してください。おそらく、パフォーマンスが大幅に向上する可能性があります。一部のリクエストでは、DB にまったく負荷がかかりません!

于 2009-07-13T08:14:56.933 に答える
1

他の人がすでに言ったように、それは多くの要因に依存します. しかし、あなたの質問から、アーキテクトは、ストアド プロシージャを DB 内からアプリケーション内の動的 SQL に移動することを提案しているようです。それは私には非常に疑わしく聞こえます。SQL はセット指向の言語であり、大量のデータ レコードの処理を必要とするビジネス ロジックには、SQL の方が適しています。複雑な検索とレポート型の機能を考えてみてください。一方、対応するビジネス ルールの検証を伴う項目の編集は、プログラミング言語で行う方がはるかに優れています。アプリ層での変化の遅いデータのキャッシュは、もう 1 つの利点です。すべてのデータへのゲートウェイとして機能する専用の中間層サービスがある場合、これはさらに優れています。異なるアプリケーション間でデータを直接共有する場合は、ストアド プロシージャを使用することをお勧めします。また、組織内での SQL の才能とプログラミングの才能の可用性/経験も考慮に入れる必要があります。この質問に対する一般的な答えは実際にはありません。

于 2009-07-13T10:00:29.747 に答える
1

ビジネス ロジックがまだ SQL ステートメント内にある場合、データベースは以前と同じように多くの作業を行っているため、パフォーマンスが向上することはありません。(ストアド プロシージャが使用されたときほど効果的にクエリ プランをキャッシュできない場合は、より多くの作業が必要になる可能性があります)

パフォーマンスを向上させるには、一部の作業をアプリケーション レイヤーに移動する必要があります。たとえば、アプリケーション サーバーにデータをキャッシュし、データベースにアクセスせずにルックアップや検証チェックを実行できますか?

于 2009-07-13T08:52:52.830 に答える
1

これらの決定は、アーキテクチャのドグマを使用して正当化されるべきではないと思います。データは、はるかに理にかなっています。

「すべてのビジネス ロジックはストアド プロシージャに属している」または「すべてが中間層にある必要がある」などのステートメントは、知識がそれぞれデータベースまたはオブジェクトに制限されている人々によって作成される傾向があります。判断するときは両方を組み合わせて、測定に基づいて判断することをお勧めします。

たとえば、プロシージャの 1 つが大量のデータを処理し、少数の結果を返す場合、それをデータベースに残す必要があるという議論があります。何百万もの行を中間層のメモリに取り込み、それらをクランチしてから、別のラウンド トリップでデータベースを更新することにはほとんど意味がありません。

もう 1 つの考慮事項は、データベースがアプリ間で共有されているかどうかです。その場合、ロジックはデータベースに残して、すべてが使用できるようにする必要があります。

中間層は行き来する傾向がありますが、データは永遠に残ります。

私自身オブジェクトの男ですが、軽く踏みます。

複雑な問題です。白黒のステートメントがすべての場合に機能するとは思いません。

于 2009-07-13T09:44:37.593 に答える