非常に論争の多いデータベース用に、組織内で Linkedin のデータバス アーキテクチャを再作成しようとしています。私の最初の考えは、SQL サーバーの変更データ キャプチャ (CDC) 機能を使用してすべてのイベントをキャプチャし、LI が「ブートストラップ」で行うのと同じ方法でそれらを外部データストアに公開することです。cdc テーブルを常にプールするサービスを作成すると、それらをブートストラップ db に書き込み、pub/sub システムでイベントを発行できます。
ここでの私の質問は、誰かがこのようなことを試みたかどうか、そして私の前述のアプローチが良いアプローチのように見えるかどうか、またはこれらのイベントをキャプチャして公開するためのより良い方法があるかどうかです.
ありがとう。
編集：[詳細を追加]
セカンダリ データストアを完全に決定したわけではありません。少なくとも短期的には、別のサーバー上の別の SQL Server 2008 インスタンスになる可能性があります。このセカンダリ ストアの主な目的の 1 つは、メイン サーバーの負荷を軽減することです。私たちのメイン データベースは非常に大きくなり (>2.5 TB)、負荷を追加することは嫌われます。このアーキテクチャを実装できれば、追加の利点として、レプリケーションを本質的に管理できるようになり、メイン サーバーからレプリケーションの責任を大幅に取り除くことができます。
理想的には、CDC も使用しないでください。これは素晴らしいテクノロジーだと思いますが、これらの変更をローカルに保存するため、サーバーのパフォーマンスが低下することがわかりました。しかし、当分の間、これが私の最良の選択肢のようです。
編集 2: [その他のプロセスの詳細]
私が達成しようとしていることは、実際、複製と非常によく似ています。このセカンダリ サーバーでは、基本データベースのコピーと、変更を追跡するための一連のテーブルから始めます。次に、CDC テーブルを監視し、これらのイベントを新しいデータベースに移動し、ソースからクリアして、2 番目のサーバーのベース コピーに変更を適用するサービスを用意します。
次のコンポーネントは、発行されたすべての変更イベントを取得する pub/sub サービスであり、すべてのコンシューマーがこれらの変更イベントを取得するためにサブスクライブすることを選択できます。新しいコンシューマーがオンラインになると、完全な db コピーが「ブートストラップ」に使用されるため、変更イベントの取得を開始する前に完全で最新の db を取得できます。トラッキング テーブルは、コンシューマーがオフラインになり、イベントを見逃した場合にデルタを取得するためにも使用されます。
クライアントは、適切と思われるデータを変換するルールを適用できます。最初のアプリケーションは、元のデータベースの読み取り専用コピーを作成するためのものです。将来の計画には、データの非正規化と、MongoDb コレクションなどの他の形式への転送が含まれます。
この最初の部分は、リモート サーバーで CDC テーブルを維持できれば、おそらく最も簡単に達成できます。ただし、これを行う方法はありません。
これは複雑に聞こえるかもしれませんが、linkin の解決策から明らかなように、最近ではそれほど珍しくない実際の問題を解決します。
うまくいけば、これが役に立ちます。