2

私は現在、約 90 KLOC の保険ブローカー向けの、データベースを多用する基幹業務 Rails アプリケーションに取り組んでいます。そのほとんどは、ビジネス トランザクションによるデータ操作と、そのすべてのデータを集計するための複数のレポートです。

私たちは非常に小さなチームに所属しており、コード ベースのサイズと複雑さが管理能力を超え始めています。そのため、私たちはそれを飼いならす方法を研究しています。そのうちの 1 つはサービス指向アーキテクチャに変換することです。つまり、いくつかの小さなアプリケーションに分割します。

このアプローチの問題は、レポート側にあります。通常、レポートには最大 7 つの結合が離れたテーブルが含まれ、途中で複数のテーブルにフィルターが作用します。サービスがテーブルを共有する可能性 (複数の記事でアンチパターンとして述べられている) を破棄した場合、パフォーマンスをそれほど損なわない方法でこのすべてのデータを結合することは可能でしょうか?

では、SOA はそのような問題に対して推奨されるアプローチでしょうか? それとも、解決するよりも多くの問題をもたらしますか?

私たちの専門知識は主に Ruby (Rails と Sinatra) と Python (Plone と Grok) にありますが、他のテクノロジ (.NET、Java) に関するコミュニティが通常この問題をどのように扱っているかも知りたいです。

前もって感謝します！

4

3 に答える 3

1

SOAは確かに、尊敬されるサービスのコードベースをより小さく、より適切に分離して維持するのに役立ちます。また、各サービスのデータベースが分離されるため、運用データベースが簡素化されます。もちろん、欠点は、レポートにはうまく機能しないことです。

一方、learn4livingが指摘したように、運用データベースはレポートに便利ではなく、非正規化されたデータは操作しやすいため、とにかくレポート用に別のスキーマを使用する方がよいでしょう。

私はこの集約されたレポートの周りのパターンと呼んでいます。数年前に私が書いた、BIとSOAの間のギャップを埋める記事を読むことができます。

于 2012-10-08T07:52:34.713 に答える
1

私はデータ ウェアハウスの出身で、Ruby/Rails に興味があります。あなたの投稿を読んで、レポート アーキテクチャを再設計し、基本システムから切り離す必要があるのではないかと感じました。

そのセグメントを再設計すると、おそらく元のシステムはそれほど大きく/複雑ではなくなります。

一言で言えば、7 レベルの結合を通過するレポート要件は、私を「ぎこちなく」感じさせます。レポートにトランザクション システムを使用しようとしているように見えますか?

事前に計算された集計を使用して別のスキーマ/データベースに移動することをお勧めします (もちろん、レバレッジはビジネス ケースによって異なります)。これは、基本システムの複雑さを軽減するのに役立つだけでなく、より高速で比較的シンプルなレポート環境を実現するのにも役立ちます。ストレージ コストが発生する可能性があります (aggs env の個別の db/schema の場合) が、単純化/設計のために支払う費用はわずかです。

h番目

于 2012-10-07T21:15:04.000 に答える
1

SOA、バッチ処理、およびキャッシングを組み合わせることで、懸念事項を大幅に解決できます。どのプロセスを特定する必要があるか

  1. 高可用性のために作成する必要があります ( Webservices/Messaging )
  2. ユーザーは結果を待つ余裕がありますか (バッチ処理)
  3. 古いデータの表示/消費を許容できる (キャッシング)

長期的な利益のために、少しの非正規化に投資することも価値があるかもしれません。

于 2012-10-08T13:42:33.327 に答える