9

Web/SaaS モデルで販売されるカスタム CRM ソリューションを開発しています。このソリューションを使用するクライアントは、数十または数百に上ると予想されます。MS SQL を db エンジンとして使用します。

オプション 1 は、単一の DB を持ち、テーブルに TenantId 列、適切なインデックスを含め、各 db アクセスで「where tenantId={...}」を使用することです。

オプション 2 は、クライアントごとに個別の DB を用意し、TenantId および where 句の必要性を回避することです。

各クライアントには、数百万ではなく、数十万のレコードがあると予想しています。

私が見ているように、どのオプションを選択しても、データページの総数があります。SQL が複数の DB を管理するのに優れているのか、それとも TenantId とインデックスを持つ単一の DB を管理するのに優れているのかが、決定の中心になっているようです。最初は、ソリューションは単一の DB サーバーで実行されますが、最終的には SAN に移行します。

誰もこれについて意見を持っていますか?

4

2 に答える 2

4

Multi-Tenant Data Architectureというタイトルの興味深い MSDN 記事があり、ぜひチェックしてみてください。著者は、特定のアプローチが別のアプローチよりも適切な場合について簡単な分析を行います。

サービスを提供すると予想されるテナントの数、性質、およびニーズはすべて、さまざまな方法でデータ アーキテクチャの決定に影響します。以下の質問の中には、より孤立したアプローチにバイアスをかけるものもあれば、より共有されたアプローチにバイアスをかけるものもあります。

  • ターゲットとする見込みテナントは何人ですか？権限を持って将来の使用を見積もることはできないかもしれませんが、桁違いに考えてみてください。何百ものテナント用のアプリケーションを構築していますか? 数千？何万もの？もっと？テナント ベースが大きくなると予想されるほど、より共有されたアプローチを検討する可能性が高くなります。

  • 平均的なテナントのデータが占めると予想されるストレージ容量はどれくらいですか? 一部またはすべてのテナントが非常に大量のデータを格納することが予想される場合は、個別のデータベース アプローチがおそらく最適です。(実際、データ ストレージの要件により、いずれにせよ分離データベース モデルの採用が余儀なくされる場合があります。その場合、後で分離データベース アプローチに移行するよりも、最初からそのようにアプリケーションを設計する方がはるかに簡単です。)

  • 平均的なテナントがサポートすると予想される同時エンド ユーザー数は? 数値が大きいほど、エンド ユーザーの要件を満たすために、より分離されたアプローチが適切になります。

  • テナントごとのバックアップや復元機能など、テナントごとの付加価値サービスを提供する予定はありますか? このようなサービスは、より分離されたアプローチによって提供しやすくなります。

あなたの場合、「共有アプローチ」はオプション1であり、「分離アプローチ」はオプション2であることに注意してください。最初の 2 点に関してはどちらの側にも偏っていないので、最後の 2 点に基づいて決定すると思います。

于 2010-06-24T08:51:28.283 に答える
0

テナント間でデータをリンクする必要がない場合は、複数のデータベースを持つことをお勧めします。メンテナンスとセットアップが簡単になり、パフォーマンスが大幅に向上します。1 つのテーブルに複数のテナントからのデータがある場合、テーブル ロックと大きなテーブルに対する検索クエリにより、ソリューションが遅くなる可能性があり、その可能性が最も高くなります。

1 つのデータベースを共有する唯一の理由は、クライアントが非常に多く、クライアントごとの行数が非常に少ない場合です。

于 2010-06-24T08:51:45.540 に答える