大規模な分散システムのレポートを設計するにはどうすればよいですか?

Question

本当に言葉が出ません。2 回目の提出もまた却下されました。理由は、「内容は技術的な議論に属するものです。他の人との技術的な意見交換をより良くするために、この問題についての考えを簡単に話すことをお勧めします。」 " "レイアウトのせいで初めてならそれを認めますが、Q&A の投稿はなぜこれほど難しいのでしょうか。はい、必要に応じて表現してください。本当にわからない場合は、ランダムに作成する必要がありますか?ウェブサイトチームは良い意図を持っていると思いますが、新人にとってはこれが原因で放棄される可能性があります。質問するのが本当に難しいので、これを最後にこのフォーラムは利用しません。

以下は原文であり、最後に私個人の考えを少し付け加えます。

私が初めてここに来たとき、おそらく初めて組版が乱雑すぎて審査に落ちたのですが、その後、この目的のためにマークダウン構文をいくつか学びました。さっそく本文に入りましょう。

1. システムの背景

   • ある大手上場国営企業は、さまざまな省や都市に支店を持ち、全国の支店や子会社の業務プロセスや財務データを一元管理するために、管理プラットフォームを開発、配布しました。各都市の本来の分散型金融システムや業務管理システムなどを、実際のニーズに基づいて二次開発して置き換える。

2. プラットフォームの紹介

   • フロントエンドは angularJs、ブートストラップ、html を使用し、バックエンドは springMVC、MyBatis を使用し、データベースには Oracle と Mysql が含まれ、rpc フレームワークは dubbo を使用し、登録センターは Zookeeper を使用し、キャッシュは Redis を使用します。全体的なシステム アーキテクチャは分散クラスターです。システム全体は複数の業務モジュールで構成されており、主に「プロジェクト管理」「契約管理」「調達管理」「販売管理」「会計管理」の5つのモジュールから構成されています。

3. 既存の要件

   • 既存のビジネスに基づいて 100 件のレポートを作成します。レポート モジュールには、独立したデータベースとアプリケーションが含まれます。

4. ＃＃＃技術的な問題＃＃＃
   すべてのレポートで使用する大きなテーブルを作成するにはどうすればよいですか?
   • ビジネス部分を明確にすることはもちろん最も基本的なことですが、各モジュールはインターフェイスを通じてサービスを呼び出します。

     
     

   分散データベースから大量のデータを抽出するにはどうすればよいですか?
   • 各モジュールには独自のデータベースがあり、一部は Oracle を使用し、一部は MySQL を使用し、データ量レベルは 1,000 万を超えます。

     
     

   データを同期するためのより合理的な方法は何でしょうか?どのような技術で?
   • 増分同期は困難です。ビジネス モジュールから増分データが失われないようにする良い方法はありません。完全データの場合、毎回のデータ量が非常に大きくなります。さらに、レポートの表示時やデータのエクスポート時のパフォーマンスを確保するにはどうすればよいでしょうか?

     
     

このような大きなプロジェクトに取り組むのは初めてなので、とても戸惑っています。うまく表現できていないかもしれませんが、何か補足がございましたらメッセージをお願いいたします。フォーラムの先輩方からアドバイスをいただければ幸いです、よろしくお願いします。

ps:
マークダウンについてはまだ理解できない部分が多いのですが、たとえば、順序付きリストと順序なしリストが入れ子になっている場合、黒塗りの点が白丸になるのはなぜですか?
順序なしリストの行の折り返しが現在の行に対してのみ有効であり、現在の行が有効な場合、上で折り返された行は無効になるのはなぜですか?
わかりません。エディタによって構文が異なるということでしょうか?
他の人が投稿した投稿のマークダウンを確認するにはどうすればよいですか?それを見ることができれば、そこから学ぶことができます。

---

個人的なデザインのアイデア

1. すべてのレポートの統計ディメンションと共通フィールドを分析し、レポート モジュールに新しい Oracle ユーザーを作成し、モジュールに従ってすべてのフィールドをテーブルに分割し、それをレポートの基本テーブルとして使用します。

2. データの抽出方法を検討する必要があります。現在考えられる方法は次の 2 つです。

   • 各モジュールを通じてインターフェイスを提供し、レポート モジュールの基本的な大きなテーブルにデータを挿入します。利点: 抽出ルールの保守が容易です。欠点: パフォーマンスが低下します。

   • DBLink を介して Oracle データベースと Mysql データベースを接続し、ストアド プロシージャを使用して基本的な大きなテーブルにデータを直接挿入します。メリット：パフォーマンスの向上、デメリット：他者によるルールの維持が困難になる。

3. データは毎回完全に同期されます。長所: ロジックがシンプル; 短所: データ同期の量が多すぎ、時間がかかりすぎます。

以上は個人的な意見ですので、先輩方からアドバイスをいただければ幸いです。

Answer 1

あなたが言及した需要は基本的にデータ ウェアハウスの構築です。基本的なアイデアは次のとおりです。

1. データ ウェアハウスのデータベースとビジネス システムは独立しています。データ ウェアハウスのモデリングには、単に大きなテーブルを構築するだけではなく、階層的な設計が必要です。

一般に、バッファ層、ベース層、集約層、レポート層などに分かれています。各層の焦点は異なります。ベース層は依然としてパラダイムモデルに基づいており、集約層は一般にデータを冗長化する必要があります。レポート レイヤーは一般に、多くの列を含む幅の広いテーブル デザインです。

2. データの量が大きい場合は、増分メカニズムが必要です。そうでない場合は、システムの変更を適用する必要があります。

3. 同期方法にはいくつかのアイデアがあります:

リーリー