mysql - この種のレプリケーションには、どの戦略/テクノロジを使用する必要がありますか?

Question

私は現在、まだ良い解決策を見つけられていない問題に直面しているので、皆さんからのアドバイスを期待しています.

写真のように私の問題 ここに画像の説明を入力

コアデータベースは、すべてのクライアントが接続して、常に非常に大きく忙しいライブデータを管理する場所です。

Feature Database はそれほど頻繁には使用されませんが、Core Database からのライブデータの一部 (おそらく 5%) が必要ですが、このサーバーへの要求タスクには時間がかかり、多くのリソースが消費されます。

私の現在の解決策は何ですか:

Core Database と Feature Database の間でデータベースレプリケーションを使用しましたが、正常に動作します。しかし問題は、不要なデータを保存するために多くのディスク領域を浪費していることです。(レプリケートデータ中のフィルタリングは、データベーススキーマでは機能しません)
コアデータベースへの要求が多いため、キューイングシステムを使用すると、データが時間どおりにライブになるわけではありません。

これに会ったことがある場合は、何かアイデアを提案してください。

ありがとう、

パン

score 0 · Accepted Answer

定義するのは、古典的なデータ統合タスクです。任意のデータ統合ツールを使用して、コアデータベースからデータを抽出し、注目のデータベースにロードできます。データ統合ジョブは、リアルタイムから任意の時間枠までスケジュールできます。

中規模（10GB）の半科学的なPostgreSQLデータベース統合プロジェクトでTalendを使用しました。それは美しく働きました。

SQL Server Integration Services（SSIS）を試すこともできます。このツールも非常に強力です。すべての一流のRDBMSで動作します。

score 0 · Accepted Answer

あなたが心配しているのがディスク容量だけなら、私はあなたが今持っている解決策に固執するでしょう。最近では、100 GBのディスク容量は1ドル未満です。そのお金では、システムに新しいソリューションを導入する余裕はありません。

論理的には、同じアプリケーションでフィルタリングを維持する場合もあります。不思議な統合レイヤーではなく、アプリ自体の内部で関連するレコードを知る責任を維持することで、ソリューション全体の複雑さを軽減できます。本当に必要な場合にのみ、特別な統合レイヤーの追加の複雑さを受け入れてください。

2 に答える 2