0

SaaS として提供される Silverlight アプリケーションを構築しています。最終製品は、WCF サービスに接続する Silverlight クライアントです。クライアントの数が多くなる可能性があるため、できればすべてのインスタンスを一度に更新できるように、更新を簡単にする必要があります。

以前にマルチテナンシーを実装したことがないので、達成方法について意見を求めています

  • 簡単なアップグレード
  • データセキュリティ
  • スケーラビリティ

考慮すべき 3 つの異なるモデルがmsdnにリストされています

  1. データベースを分離します。すべてのスキーマ変更を各顧客のデータベースに個別に適用する必要があるため、これを維持するのは容易ではありません。他に欠点はありますか？プロはデータの分離とセキュリティです。これにより、顧客ごとにわずかな変更を行うこともできます (その価値よりも手間がかかる可能性があります!)。
  2. 共有データベース、個別のスキーマ。TenantID 列が各テーブルに追加されます。各顧客が正しいデータを取得できるようにすることは、潜在的に危険です。保守が容易で、拡張性に優れています (?)。
  3. 共有データベース、個別のスキーマ。最初のモデルと似ていますが、各顧客はデータベース内に独自のテーブル セットを持っています。単一の顧客のバックアップを復元するのは困難です。それ以外はモデル 1 と同様の保守性 (?)。

このテーマに関する記事の推奨事項はありますか? Silverlight SaaS アプリで同様のことを調べた人はいますか? クライアント側で何を考慮する必要がありますか?

4

5 に答える 5

1

Apprenda の SaaSGrid のようなすぐに使えるアーキテクチャを提供するソリューションについてはどうでしょうか? これらを使用すると、設計時ではなく、デプロイおよびメンテナンス時にデータベースの決定を下すことができます。データ層を積極的に変換および管理し、アップグレード エンジンを提供しているようです。

于 2009-03-09T03:16:49.943 に答える
1

SaaS 製品もあり、ソリューション #2 (TenandId を使用した共有 DB/共有スキーマ) を使用します。共有 DB / すべての同じスキーマについて考慮すべき事項:

  1. 前述のように、注意しないと、1 つのテナントの大量のデータが他のテナントのパフォーマンスに影響を与える可能性があります。手始めに、テーブルを適切に/慎重にインデックス付けし、テーブルスキャンを強制するクエリを決して実行しないでください。クエリのパフォーマンスを監視し、少なくとも計画/設計して、ドメインにとって意味のあるいくつかの基準に基づいて後で DB を分割できるようにします。

  2. データの分離は非常に重要です。他のテナントに属する一部のテナントにデータを表示することは望ましくありません。すべてのクエリには WHERE TenandId = ... が含まれている必要があり、開発中にこれを確認/適用できるはずです。

  3. スキーマの拡張性は、ソリューション 1 と 3 で得られるものですが、ドメイン内のドキュメント/テーブルに関連付けられているフィールドを拡張する方法を設計することで回避できます (つまり、テーブルのメタデータとしてmsdnの記事で言及されています）

于 2009-02-03T22:32:45.700 に答える
1

アプリケーションの種類とデータの規模によって異なります。それぞれに落とし穴があります。

1a) 個別のデータベース + WCF/クライアントの単一インスタンス。すべてを同期させることは困難です。X 台の DB サーバーを同時にアップグレードする方法は?

1b) 「サイロ」、顧客ごとに個別の DB/WCF/クライアント。同期の問題はありませんが、各レイヤーのさまざまなインスタンスを多数管理するオーバーヘッドがあります。また、SQL のライセンスも確認する必要があります。SQL の個別のインスタンスが個別にライセンスされているかどうか ($$$) は覚えていません。必要な数のインスタンスをインストールできたとしても、特定の時点以降、複数のインスタンスのオーバーヘッドは些細なものではなくなります。

3) ライセンスを除いて、基本的に 1a/b と同じ問題。

2) 最適なアップグレード/管理シナリオ。データの分離を維持することが大きな懸念事項であることは間違いありません (1a は、この問題をより高いレベルで技術的に共有しています)。もう 1 つの問題は、アプリケーションがデータ集約型の場合、データのスケーラビリティについて心配する必要があることです。たとえば、すべての顧客が数千万行または数億行のデータを持つことが予想される場合です。その後、顧客ベースの総量が原因で、個々の顧客の問題とクエリ パフォーマンスが発生し始めます。クライアントは、自身のデータ量が原因で発生する速度低下に対してより寛容です。他の 99 クライアントのデータが大きいために遅いと言われることは、通常はありません。

最初から膨大な量のデータを処理するという事実が分かっていない限り、現時点ではおそらく 2 を使用し、将来必要に応じてクラスタリングを検討するか、1a/b セットアップに移行することを検討します。

于 2009-02-03T21:39:51.673 に答える
1

同様のケースがありますが、私の解決策は両方を利用することです。

データがどこに、どのように配置されるかは、テナントからの質問です。もちろん、テナントであるため、自分のデータを共有したくありません。自分のデータを分離して安全に保ち、いつでも取得できるようにしたいのです。

特定のデータを共有する可能性があります。例: 会社リスト。したがって、データベースはグローバルでテナント データベースである必要があります。操作テナント データベース スキーマでロックされていることを確認し、すべてのテナント データベースを一度に更新する手順を実行してください。

とにかく、SaaS モデルはすべてサーバー/Web サービスとして提供されるため、データベースがサービスとしてクライアントに提供される場所に関係なく、クライアント GUI によってのみレンダリングされます。

ありがとう

于 2010-09-24T03:02:45.797 に答える
0

既存の答えは良いです。複数のデータベースのアップグレードと管理の問題を深く調べる必要があります。特定のアプリを知らなくても、複数のデータベースを使用する方が簡単で、TenantIDを追跡するための追加コストを支払う必要がない場合があります。これは正しい決定ではないかもしれませんが、データ共有の開発コストには確かに注意する必要があります。

于 2009-02-04T05:15:49.427 に答える