マルチテナントDBには複数のデータベースまたは共有テーブルがありますか?


24

マルチテナントデータベースです:

  • 顧客/テナントごとに異なる(同一の)データベース/スキーマを持つDBサーバー。または
  • 顧客/テナントが同じテーブル内でレコードを共有するデータベース/スキーマを持つDBサーバー?

たとえば、上記のオプション#1では、たとえばにMySQLサーバーmydb01.example.comがあり、customer1その中にデータベースがあります。このcustomer1データベースには、たとえば、特定の顧客(顧客#1)のアプリケーション駆動する10個のテーブルがあります。またcustomer2、まったく同じ10個のテーブルを持つデータベースがありますが、顧客#2のデータのみが含まれている場合があります。customer3データベース、データベースなどがある場合がありますcustomer4

上記のオプション#2では、たとえば、myapp_db10個のテーブル(上記と同じもの)を持つ単一のデータベース/スキーマのみが存在します。しかし、ここでは、すべての顧客のデータがこれらの10個のテーブル内に存在するため、顧客はテーブルを「共有」します。また、アプリケーション層では、ロジックとセキュリティにより、どの顧客がこれらの10個のテーブルのどのレコードにアクセスできるかを制御し、顧客#1がアプリにログインして顧客#3のデータなどを表示しないように細心の注意を払っています。

これらのパラダイムのうち、従来の「マルチテナント」DBを構成するものはどれですか?どちらでもない場合、マルチテナントDBとは何かの例を(上記のシナリオを使用して)提供してくれますか?


「マルチテナント」は、どこかで実装された強力なセキュリティを意味するため、あるテナントは他のテナントのデータを見たり、変更したり、アクセスを拒否したりできません。そのセキュリティは何らかの方法で実装する必要があります。OPのオプション#1と#2は両方とも機能しますが、セキュリティ分析とセキュリティの実装に必要な作業は異なります。価値のあるものとして、私はオプション#2を介してマルチテナントを実装するスタートアップで働いていました。そこでは、複数のテナントに属する行を持つテーブルがすべてのエンドユーザーから(権限を介して)隠され、セキュリティは完全にストアドプロシージャに実装されていました。
-davidbak


1
これが重複として閉じられた場合、両方の質問にいくつかの本当に良い答えがあるので、重複ターゲットとマージするようにフラグを立てるべきだと思います。

回答:


29

これらのパラダイムのうち、従来の「マルチテナント」DBを構成するものはどれですか

両方の概念はマルチテナントと呼ばれます。これは、「ソフトウェアの単一インスタンスがサーバー上で実行され、複数のテナントにサービスを提供する」という論理的な概念にすぎないためです(Wikipediaから)。しかし、この概念を「物理的に」どのように実装するかはあなた次第です。

もちろん、アプリケーションには異なるテナントのデータを分離できるデータベースの概念が必要です。マルチテナンシーの考え方は、リソースの利用率を高め、管理を容易にするために、サーバーリソース(少なくともハードウェア)を共有することです。したがって、「マルチテナントDB」は、dbモデルまたはテーブルの一部が共有される場合、これを直接サポートするものです。

具体的には、非マルチテナントDBを使用してマルチテナントアプリケーションを構築し、クライアントごとに個別のDBインスタンスを提供することが可能です。ただし、これにより、テナント間でDBリソースを直接共有することができなくなり、アプリケーション層は適切なテナントを適切なデータベースに接続する必要があります。


おかげ@Docブラウン(1)が、その後、どのようにあなたは、おそらく持っている可能性がどんなだったのデータベースではないマルチテナントを?!?
smeeb

4
@smeeb:マルチテナンシーは、異なるテナントが使用するアプリケーションのプロパティであり、アプリケーションの「背後」にあるデータベースのプロパティではありません。もちろん、これを可能にするために、dbコンセプトはマルチテナンシーをサポートする必要があります。
ドックブラウン

4
@smeeb:ユーザー名が一意であるという制約のあるUserテーブルがあり、テナントの従業員が別のテナントで働いている別の人がすでにそれを使用しているという理由だけでユーザー名を使用できなくなったとします。
-RemcoGerlich

5
@smeeb:2つのテナントにサービスを提供する唯一の方法が、2つの異なるデータベースを備えた2つの異なるサーバーにアプリケーションを2回インストールして実行することである場合、このマルチテナンシーとは呼ばないでしょう。
Doc Brown

1
しばらく前に、MYOBがAzureでクラウドソリューションを実行し、各テナントが独自のDB(およびおそらくWebサーバーも)を取得するというAzureのプレゼンテーションに行きました。必要な数百のDBインスタンスを管理するための優れた自動化ツールがいくつかあります。一方、私が現在働いている組織では、単一のデータベースで何百人もの顧客を抱えており、顧客のデータの分離を強制するためにソフトウェアでかなりの作業が行われています。また、最大の顧客が独自のDBを取得し、他の顧客が元のDBを共有するハイブリッドを検討しました。
デビッドキーベニー

36

Microsoftによると、この用語には3つの潜在的な意味があります(すべてのテナントに対して1つのデータベース、またはテナントごとに1つのデータベース)。

この例を使用すると、各顧客はそれぞれのテナントになります。

  1. テナントごとのデータベース(顧客)

    • 各テナントは他のテナントから分離されています(他のテナントのデータへの偶発的なアクセスはありません)
    • また、分離により、データの復元を管理しやすくなり、テナントのニーズに合わせてストレージのニーズを調整できます。
  2. 共有データベース、個別のスキーマ。

    • 各テナントには独自のスキーマがあり、データは独自のテーブルにあります。
    • 全員が同じデータベースにいるため、復元には時間がかかる場合があります。データベースを以前のバックアップに復元することはできません(すべてのテナントのデータをロールバックします)。オプションは、新しいデータベースに復元し、1テナントのデータのみをマージ/コピーすることです。
  3. 共有データベース、共有スキーマ。

    • すべてのテナントのデータは同じテーブルにあります。たとえば、注文を追跡する場合、すべてのテナントの注文は「dbo.Orders」に配置されます。
    • テナントのデータは、各テーブルの列(TenantIdの場合もあります)で区切られ、行の所有者を示します。

それぞれに長所と短所があり、この記事で詳しく説明されています:https : //msdn.microsoft.com/en-us/library/aa479086.aspx

ボーナス:居住区と考えることができます(非常に単純化されています)。

  1. すべてのテナントには自分の家があります。彼らは何でも好きなことをすることができ、燃え尽きたとしても、それは他の誰にも本当に影響しません。

  2. すべてのテナントは同じ建物内にありますが、自分のアパートがあります。

  3. 誰もが同じアパートに住んでおり、すべてのものには誰が所有しているのかを示すために付箋が付いています。


2
ご回答ありがとうございます。少し答えを教えてください。それはより良い答えを作成します。
トーマスジャンク

1
ボーナスの例は素晴らしい@ imms90
アラビン

3
Microsoftは、MSDNからリンクしたページを削除しました。ウェイバックマシンは、まだコピーされています。
マイクシェリル 'キャットリコール'

1
MSからの同様の記事(移動したことを多分同じ):docs.microsoft.com/en-us/azure/sql-database/...
ピエール・アンリ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.