組織が多くの部門やアプリケーション間で重要なデータを共有するための良い方法は何ですか?
例として、顧客データを管理するための主要なアプリケーションとデータベースが 1 つあるとします。組織内には、そのデータを読み取って独自のデータに関連付けるアプリケーションとデータベースが他に 10 個あります。現在、このデータ共有は、データベース (DB) リンク、具体化されたビュー、トリガー、ステージング テーブル、再キー化情報、Web サービスなどの組み合わせによって行われています。
データを共有するための他の良いアプローチはありますか? そして、次のような懸念に関して、あなたのアプローチは上記のものとどのように比較されますか?
共有顧客データは、単純な単一レコード クエリから、複雑な複数述語、複数並べ替え、さまざまなデータベースに保存されている他の組織データとの結合まで、さまざまな方法で使用されることに注意してください。
あなたの提案やアドバイスをありがとう...
あなたはこれが来るのを見たと確信しています、「それは依存します」。
それはすべてに依存します。また、部門 A の顧客データを共有するソリューションは、部門 B と顧客データを共有する場合とはまったく異なる場合があります。
ここ数年で私が気に入っている概念は、「結果整合性」の概念です。この用語は、分散システムについて話している Amazon から来ました。
前提として、分散型エンタープライズ全体のデータの状態は、現時点では完全に一貫していない可能性がありますが、「最終的には」そうなるということです。
たとえば、システム A で顧客レコードが更新されると、システム B の顧客データは古くなり、一致しなくなります。しかし、「最終的に」、A からのレコードは何らかのプロセスを経て B に送信されます。したがって、最終的に 2 つのインスタンスは一致します。
単一のシステムで作業する場合、「EC」はなく、即時の更新、単一の「信頼できる情報源」、および通常は競合状態と競合を処理するためのロック メカニズムがあります。
オペレーションが「EC」データを処理できるほど、これらのシステムを分離するのが容易になります。簡単な例は、営業が使用するデータ ウェアハウスです。DW を使用して日次レポートを実行しますが、レポートは早朝まで実行せず、常に「昨日」(またはそれ以前) のデータを確認します。したがって、DW が日常の運用システムと完全に一致している必要はありません。プロセスがたとえば営業終了時に実行され、大規模な単一の更新操作でトランザクションとアクティビティがまとめて移動することは完全に許容されます。
この要件がいかに多くの問題を解決できるかがわかります。トランザクション データの競合はありません。レポートがライブ データベースに対して 2 つの個別のクエリを実行したため、統計の蓄積中に一部のレポート データが変更される心配はありません。日中、ネットワークや CPU 処理などを吸い上げる高精細なおしゃべりをする必要はありません。
これは EC の極端で単純化された非常に粗い例です。
しかし、Google のような大規模なシステムを考えてみてください。検索の消費者として、Google が収集した検索結果が検索ページに表示されるまでに、いつ、どのくらいの時間がかかるかわかりません。1ms? 1秒？10代？10時間？Google の西海岸のサーバーにアクセスした場合、東海岸のサーバーにアクセスした場合とは異なる検索結果が得られる可能性があることは容易に想像できます。これら 2 つのインスタンスが完全に一致しているわけではありません。しかし、大まかに言えば、それらはほとんど一貫しています。そして、彼らのユースケースでは、消費者は遅れや遅延の影響を実際には受けていません.
メールを検討してください。A は B にメッセージを送信しようとしていますが、その過程でメッセージはシステム C、D、および E を介してルーティングされます。各システムはメッセージを受け入れ、そのメッセージに対する完全な責任を負い、別のシステムに渡します。送信者は、電子メールが進行中であることを確認します。受信者は、それが来ることを必ずしも知っているわけではないので、実際にそれを見逃すことはありません。そのため、そのメッセージがシステム内を移動するのにかかる時間は大きく、その速さを誰も気にかけたり気にしたりする必要はありません。
一方、A は B と電話をしていた可能性があります。
したがって、何らかの潜在的なパフォーマンスと応答のレベルがあります。最終的に、「最終的に」A の送信ボックスは B の受信ボックスと一致します。
これらの遅延、古いデータの受け入れは、それが 1 日前のものであろうと 1 ～ 5 秒前のものであろうと、システムの最終的な結合を制御するものです。この要件が緩いほど、結合が緩くなり、設計に関して自由に使える柔軟性が高くなります。
これは、CPU のコアにまで当てはまります。同じシステムで実行されている最新のマルチコア、マルチスレッド アプリケーションは、「同じ」データの異なるビューを持つことができます。相互に矛盾する可能性のあるデータを使用してコードが正しく機能する場合は、幸いなことに、コードは順調に進みます。そうでない場合は、揮発性メモリの修飾や構造のロックなどの手法を使用して、データが完全に一貫していることを確認するために特別な注意を払う必要があります。これらはすべて、コストパフォーマンスに影響します。
したがって、これが基本的な考慮事項です。他のすべての決定はここから始まります。これに答えると、マシン間でアプリケーションを分割する方法、共有されるリソース、およびそれらがどのように共有されるかがわかります。データを移動するために利用できるプロトコルと手法、および転送を実行するための処理にかかるコスト。レプリケーション、負荷分散、データ共有など。すべてこの概念に基づいています。
最初のコメントに応じて編集します。
正しい、正確に。ここでのゲームは、たとえば、B が顧客データを変更できない場合、変更された顧客データの害は何ですか? 短期間で古くなる「リスク」を冒すことはできますか? おそらく、顧客データがゆっくり入ってくるので、A から B にすぐに複製できます。変更がキューに入れられ、ボリュームが少ないためにすぐに取得される (< 1 秒) としますが、それでも元の変更では「トランザクション外」であり、A が持つ小さなウィンドウがあるとします。 B が持っていないデータ。
今、心は本当に回転し始めます。その「ラグ」の 1 秒の間に何が起こるか、考えられる最悪のシナリオは何ですか。そして、あなたはそれを回避することができますか? 約 1 秒のラグを設計できる場合は、約 5 秒、1 メートル、またはそれ以上のラグを設計できる可能性があります。B で実際に使用している顧客データの量はどれくらいですか? おそらく、B は在庫からの注文のピッキングを容易にするために設計されたシステムです。単なる顧客 ID とおそらく名前以上に必要なものは想像しがたいです。それが組み立てられている間、注文が誰のためのものであるかを大まかに特定するための何か。
ピッキング システムは、ピッキング プロセスの最後まですべての顧客情報を必ずしも印刷する必要はありません。その時点までに、注文は別のシステムに移動している可能性があります。そのシステムは、特に出荷情報が最新である可能性があります。最終的に、ピッキング システムは顧客データをほとんど必要としません。実際、ピッキング オーダー内の顧客情報を埋め込み、非正規化することができるため、後で同期する必要はなく、期待する必要もありません。顧客 ID が正しい (変更されることはありません) および名前 (変更されることはめったにないため、議論する価値はありません) である限り、それが唯一の実際の参照情報であり、すべてのピック スリップはその時点で完全に正確です。創造。
秘訣は、システムを分割し、タスクに必要な重要なデータに集中するという考え方です。不要なデータは、複製または同期する必要はありません。人々は、特にリレーショナル データ モデリングの世界にいる場合、非正規化やデータ削減などに苛立ちます。そして、それには十分な理由があるため、慎重に検討する必要があります。しかし、いったん分散すると、暗黙のうちに非正規化されます。一体、あなたは今それを大々的にコピーしています。だから、あなたはそれについてもっと賢いかもしれません。
これらすべては、確実な手順とワークフローの完全な理解によって軽減できます。リスクを特定し、それらを処理するためのポリシーと手順を作成します。
しかし難しいのは、最初に中央データベースへのチェーンを壊すことであり、単一の中央の完全な情報ストアを持っている場合に期待されるように、「すべてを手に入れる」ことはできないと人々に指示することです.
これは間違いなく包括的な回答ではありません。申し訳ありませんが、私の長い投稿のために、それがここに提示される考えに追加されることを願っています。
私はあなたが言及したいくつかの側面についていくつかの観察を持っています。
duplicate data
これは通常、部門化または専門化の副作用であるというのが私の経験です。ある部門は、他の専門グループによって有用であると見なされている特定のデータのコレクションを開拓しています。他のデータ収集と混ざり合っているため、このデータへの一意のアクセス権がないため、データを利用するために、データの収集/保存を開始し、本質的にデータを複製します。この問題は解消されることはなく、コードのリファクタリングと重複の削除に継続的な取り組みが行われているように、一元化されたアクセス、ストレージ、および変更のために重複データを継続的に提供する必要があります。
well-defined interfaces
ほとんどのインターフェースは、他の制約を念頭に置いて意図的に定義されています。ただし、以前に定義されたインターフェイスによって課せられた制約から成長する習慣があります。繰り返しますが、連続リファクタリングの場合です。
tight coupling vs loose coupling
どちらかといえば、ほとんどのソフトウェアはこの問題に悩まされています。緊密な結合は通常、私たちが直面する時間の制約を考えると、適切な解決策の結果です。緩い結合は、物事を成し遂げたいときに私たちが嫌うある程度の複雑さを招きます。Webサービスのマントラは何年にもわたって回ってきましたが、ポイントを完全に軽減するソリューションの良い例はまだ見ていません。
architectural simplification
私にとって、これはあなたがあなたの質問で言及したすべての問題と戦うための鍵です。SIPとH.323VoIPの話が頭に浮かびます。SIPは非常に単純化されており、構築が簡単ですが、典型的な通信規格のようなH.323は、VoIPに関する地球上のあらゆる問題を想定し、そのソリューションを提供しようとしました。その結果、SIPははるかに急速に成長しました。H.323に準拠したソリューションになるのは面倒です。実際、H.323コンプライアンスはメガバック業界です。
On a few architectural fads that I have grown up to.
何年にもわたって、私はその単純さのためにRESTアーキテクチャが好きになり始めました。データへのシンプルでユニークなアクセスを提供し、その周りにアプリケーションを簡単に構築できます。エンタープライズソリューションは、パフォーマンスなどの他の問題よりも、データの複製、分離、アクセスに苦しんでいるのを見てきました。私にとってのRESTは、これらの病気のいくつかに万能薬を提供します。
これらの問題の多くを解決するために、私は中央の「データハブ」の概念が好きです。データハブは、特定のエンティティの「信頼できる唯一の情報源」を表しますが、IDのみを保存し、名前などの情報は保存しません。実際には、IDマップのみを保存します。たとえば、これらはシステムAの顧客IDをシステムBからのクライアント番号とシステムCの顧客番号。システム間のインターフェイスはハブを使用して、あるシステムの情報を別のシステムに関連付ける方法を認識します。
それは中央翻訳のようなものです。A-> B、A-> C、およびB-> Cからマッピングするための特定のコードを記述する代わりに、システムを追加するにつれて出席率が指数関数的に増加し、ハブとの間で変換するだけで済みます。A- >ハブ、B->ハブ、C->ハブ、D->ハブなど。