2

これは概念的な問題なので、同じ概念を達成できるスタックのバリエーションは歓迎されます。現在、MySQL を使用しており、いくつかのサービスを MongoDB に拡張しています。

アイデアは、構造を利用するクライアントの数が数千、数万、数百に成長するにつれて、調整、拡張などが過度に面倒にならないように、単一の物理データベース スキーマ/構造を管理できるようにしたいということです。などですが、より厳格な分離を提供するために、単にアプリケーション層ではなくこのレベルでデータを分離したいと考えています。同じ構造を使用して各クライアントの仮想ビンを作成することは可能ですが、それらのデータは構造的に互いに分離されていますか?

通常の方法では、直接または外部関係を介してデータのすべての行にクライアント キーを追加することは明らかですが、「クロス クライアント」データ取得を可能にするシステムへのハッキングがどのように発生するかを 20/20 で予測できないことを考えると、事実上構造レベルで分離を埋め込むためにもう少し進んでください。

ここで別の投稿も読みました: MySQL: how to do row-level security (like Oracle's Virtual Private Database)? メソッドとして「ビュー」を使用しますが、クライアントのリストが大きくなるほど、これはより多くの作業になるようです。

ありがとう！

- - 編集 - -

以下に提案された文献のいくつかに基づいて、ここに私たちの意図に関するもう少しの情報があります:

@Stennie によって提供された MSDN の記事で概説されている 3 つの最も近い状況は、単一のデータベース、複数のスキーマになりますが、違いは、作成後にクライアント スキーマをカスタマイズすることには興味がなく、実際にはロックされたままにすることを好むことです。親/マスタースキーマに。

理想的には、ソリューションでは、親スキーマまたはマスター スキーマへの変更がすべてのクライアント/テナント スキーマにカスケードされることを期待して、単純に複製するのではなく、各スキーマを親テーブル セット構造にリンクしたままにします。

さらに一歩進んで、クラスターでは、マスター スキーマを持つ 1 つのマスターと、そこからレプリケートする各スレーブを持つことができますが、テナントのシャード セットを持ちます。マスターへの変更は、中断することなくクラスターを介してフィルター処理され、すべてのインスタンスで一貫性が維持され、すべての DB が更新されたスキーマと互換性があることがわかっているため、アプリケーション層をより迅速に更新できます。

それが理にかなっているといいのですが、私はこのレベルではまだ少し新鮮です.

4

1 に答える 1

1

「何も共有しない」(別名multi-instance) から「すべてを共有する」(別名multi-tenant) まで、いくつかの一般的なインフラストラクチャ アプローチがあります。

たとえば、「仮想ビン」への直接的なアプローチは、共有データベース サーバーを使用してクライアントごとにデータベースを割り当てることです。これは、顧客がデータベース サーバー インフラストラクチャを共有しているが、データとスキーマを別々に保持しているため、2 つの極端な共有の間のどこかです。

クライアントごとのデータベース アプローチにより、次のことが可能になります。

  • データベースの認証とアクセス制御を使用して、クライアントごとに認証とアクセスを管理します
  • さまざまなデータベースソフトウェアをサポートします（ビューをサポートするMySQLとサポートしないMongoDBの両方を使用することに言及しています）
  • クライアントごとのデータのバックアップと復元がより簡単に
  • データベース レベルで潜在的なクロス クライアント漏洩を回避する
  • 単一の大規模データベースの過度のテーブルの成長と関連する管理の問題を回避する

いくつかの潜在的な欠点は次のとおりです。

  • 管理するデータベースが増える
  • 特定のスキーマ (MySQL など) を強制したいデータベースの場合、スキーマの変更をすべてのデータベースに適用するか、何らかの形式のバージョン管理をサポートする必要があります。
  • ストレージを事前に割り当てるデータベース (MongoDB など) の場合、クライアントごとにより多くのストレージを使用できます (特に実際のデータ サイズが小さい場合)。
  • 名前空間または開いているファイルの制限に遭遇する可能性があります
  • あなたはまだアプリケーションとデータのセキュリティについて心配する必要があります:)

マルチテナンシーについて調査すると、この例 (共有データベース サーバー アーキテクチャ上のクライアントごとに分離された DB) から、より複雑なパーティション分割されたデータ スキームまで、さまざまなソリューションが見つかります。

この Microsoft の記事には、アプローチと考慮事項の有用な概要が含まれています:マルチテナント SaaS データベース テナンシー パターン。

于 2012-08-21T15:00:38.643 に答える