3

これまでのストーリー：最初に、1つのWebアプリケーションと1つのデータベースを取得しました。次に、製品所有者は最初のアプリケーションのスピンオフを行うことを決定しました（最初のアプリケーションが衣料品のサイトである場合、2番目のサイトはベビー服専用のサイトです）。2番目のアプリ用に2番目のデータベースを作成しました。そして3番目、4番目、n番目。データベースの情報が交差していなかったので、私はその決定を正当化することができます。

現在：プロダクトオーナーは、スーパーアプリケーションを作成することを決定しました。1つのアプリケーションですべてを統治します。一般的な話：ユーザーがいくつかの製品に対してクエリを実行し、その結果には、さまざまなデータベースからの集約データが含まれている必要があります（すべてではありませんが、nからのk）。

質問：私たちの前に発生する一般的な問題を解決するためのいくつかの一般的なパターンはありますか？

最初のアプローチ：スーパーデータベース（すべてのデータベースデータ、1つの巨大なデータベースにコピー）

  • 長所：必要なクエリは1つだけです。並べ替えやその他のフィルタリングを適用する方が簡単です
  • 短所：アイテムのオリジンデータベースをどのように区別するか。IDの競合の可能性があります。時間のかかる危険な情報のコピーを実行する必要があります。古いアプリケーションとの下位互換性はありません

2番目のアプローチ：同じデータベース（変更なし）

  • 長所：アプリケーションには下位互換性があります。危険な対処法はありません
  • 短所：1つのクエリが複数のクエリになります（遅く、集約が困難）
4

1 に答える 1

2

MongoDB (もちろん) には JOIN がないため、これをすべて複数のデータベースに格納しても問題ありません。ここで集計の問題が発生するという実際の脅威はありません。10gen が集計関数内のサブセレクトなどの機能をリリースして、一種の疑似型の結合を許可する場合、将来問題が発生する可能性があると思います。

同じコレクションに出力する複数の MR を実行する場合、ここで MR に 1 つの問題が発生する可能性がありますが、現在は MR が異なる DB に出力できるため (しばらくの間利用可能でした)、問題ありません。

また、複数のデータベース (2.2 の場合) では、2.2 のロック機構が DB レベルであるため、ロックはあなたの味方になります。

私の個人的な意見では、ID のコピーと競合の問題を考慮して、私はあなたが持っているものに固執し、抽象化レイヤーを作成して、1 つのデータベースから来ているように見せます。

もちろん、それを別のデータベースに格納するのが実際の論理問題であり、データを簡単に混同してしまうと思われる場合は、選択の余地がないかもしれません。

于 2012-10-01T13:16:44.667 に答える