2

私は、全国の複数の生産拠点 (すべての情報が 1 つの拠点にある) にフィードするために使用されるシステムを設計している最中であり、さらに追加する可能性があります。最初は、データベースを 1 つだけ使用すれば済むと思っていました。私は現在、元の設計を再考し、よりスケーラブルなソリューションに傾倒しています。各データベース/テーブルのサイズを抑えることも重要です。

サイトの概念にまたがる情報を持つ「マスター」データベースと、サイト固有の情報を含む各サイトの個別のデータベースがあります。

私の苦労は、データをどこで分離するかです。データはすべてかなり関連しています。どこで行っても、参照整合性が失われます。私が読んだものはすべて、非常に正当な理由だと思うので、これを絶対に避けるように言っていますが、それを回避する方法はわかりません.

トリガーを調べましたが、データベースが別のサーバーにある場合は機能しないと思います（ただし、Oracleがこれを行っていると思います）。私はオープン ソース ソリューションに限定されているため、それが役立つ場合は MySQL または postgre になります。

この問題を軽減するための提案や、別の設計上の提案はありますか?

4

5 に答える 5

1

あなたの特定の状況についてもっと知らなければ、助けるのは少し難しいです-しかし、これが私の直感です...

あなたが提案した情報は、おそらく各サイトのデータベースよりも安定している（データへの変更の数が少ない）可能性が高いと思います。

おそらく、「マスター」データベースのデータが各サイトのデータベースにも保存されているソリューションを検討することができます。次に、ある種のレプリケーションシステムを調べて、マスターデータベースに加えられた変更をサイトデータベースに伝達することができます。

そうすれば、各サイトのデータベース内で参照整合性を維持できます。

于 2008-10-21T23:44:09.897 に答える
0

MySQLにはフェデレーションテーブルがありますが、外部キー制約がそれら全体で機能するかどうかは不明です。私はそれを少し疑っていますが、トリガーは必要です。

それ以外の場合は、参照整合性をレイヤーの上位に移動する必要があります-アプリに。

于 2008-10-21T23:37:54.560 に答える
0

問題のドメインのより良い概要を示すことができるかどうか見てみましょう:

n個の本番サイトがn個増加する「エンタープライズ」ソリューションの作成を検討しています。

データを処理して、Web と印刷の両方のドキュメントを作成します。

このシステムは、データ ファイルを (一元化された Web サイト経由で) 提出からプリンターまたは Web またはその両方に送信するプロセス フローを管理します。

各生産サイトには独自の顧客などがいます。そのすべての情報はデータベースに保存されます。その情報のほとんどの管理は中央サイトで行われます

使用するソフトウェアのライセンス制限により、データはすべて 1 つのサーバーで処理されます。

そのため、(データベース内の) キューを調べてジョブを処理するデーモンが存在します。フローはデータベースのステータス列によって制御されるため、他のプロセスはプロセス内のどこにあるかを知ることができます。

大量のデータが入ってくるのは、Web ツールです。Web 用に作成する各ドキュメントの検索インデックスを保存する必要があります。これはかなり急速に大きくなります。これらのレコードは永久に保持されるわけではありませんが、少なくともほとんどの場合、サイズが大きくなります (推定 5 億行)。

テーブルサイズの問題を取り除くには、個別のデータベースが答えになるだけでなく、異なるサーバー上の運用サイトを分離する機能もあると考えました。

問題は、別のサイトがいつ買収されるか、またはその規模がどのくらいになるかはわかりません。

モンスターを収容するためのより良いサーバーを購入する必要がないように、1年後にサイトを取得して限界を超えてしまうのではなく、スケーラビリティのことをつぼみに挟み込みたいと思います. 残念ながら、お金はオブジェクトです。

成長が未知数でなければ、データベースを検討することすらありません。

また、サイトごとに完全に別個のデータベースを作成することも検討しました。これにより、アプリの管理やその他の問題がはるかに難しくなります。

的外れな回答で申し訳ありません。1日12時間です。私は本当に永遠に続けることができましたが、とにかくそれがもう少し洞察を与えることを願っています.

1 つの DB との関係の例

サイトには多くの顧客がいます 顧客には多くの提出者がいます 提出者には多くの提出があります 提出には多くの文書があります ドキュメントには多くの索引があります

したがって、結合を使用して顧客のドキュメントの数を簡単に数えることができました

于 2008-10-22T00:40:58.800 に答える
0

あなたが正しく理解していれば、リモートデータベースで参照整合性が維持されているかどうかを挿入/更新/削除するたびに、(おそらく)トリガーを使用してチェックしたいですか?

もしそうなら、私はあなたがこれを避けるべきだと思います.パフォーマンスのオーバーヘッドがあまりにも大きな問題であることがわかります. 特に、ソリューションをスケーラブルにしたい場合。

私はデータがどのように挿入されるかを心配し、それについて非常に厳密にします.アプリのロジックはこれをカバーする必要があります.これは高レベルの詳細です. 毎週のレポートを実行して、どのデータが正しくないのか、なぜ間違って挿入されるのかなどを確認することもできますが、アプリが適切に行われた場合、複数データベースの参照整合性を適用するのは難しいと思います.

しかし、誤解しないでください。私はデータを堅固で堅牢な状態に保つことに 100% 賛成ですが、これが常に強制できるとは限りません。

しかし、先に述べたように、解決策に関する詳細情報がなければ、アドバイスを与えるのは難しいです... :)

于 2008-10-22T00:11:08.440 に答える
0

どのくらいのデータについて話しているのですか？このアーキテクチャは本当に必要ですか? DB は多くの容量を駆動できます。

「これをしてはいけない」という警告は、つらい、苦い経験から来ています。また、分散データセットは、維持と管理が本当に面倒です。だから、それをすることを一生懸命考えてください。

おそらく、データをオペレーショナル ストアとレポート ストアまたはデータ ウェアハウスに分割して、毎晩または毎週フィードできるようにすることを検討してください (必要な分析レポートの最新性に応じて)。多くのオペレーショナル データ ストアは、それほど大きくする必要はありません。

また、バックエンドでのみ維持されるテーブル (たとえば、データの整合性のため) と、ユーザーによって頻繁に更新および追加される操作テーブルに関する別の問題もあります。より「静的」なテーブルは、単に静的であると見なすことができます。必要に応じてノード間でそれらを更新するための確実な手順を用意し、理想的にはめったに更新しないようにします。

データが「動的」テーブルと「静的」テーブルに分割されると、静的データを単一マスター化し、必要に応じて (ルート インスタンスから) レプリケートできるため、パーティショニングは少し簡単になりますが、パーティショニングされたストアは真実の単一ソースですバックエンドのデータ ウェアハウスとレポート システムにフィードするために使用されます。その場合、実際のレプリケーションはほとんど必要ありませんが、むしろ、容易に自動化できる「どのマシン上にあるのか」という問題の方が多くなります。

于 2008-10-21T23:54:42.280 に答える