マルチテナントデータベースです:
たとえば、上記のオプション#1では、MySQLサーバーがmydb01.example.com
、およびcustomer1
その中のデータベース。この customer1
データベースには、たとえば、アプリケーションを強化する10個のテーブルがあるかもしれませんその特定の顧客向け(顧客#1)。また、customer2
データベースにはまったく同じ10個のテーブルが含まれていますが、顧客#2のデータのみが含まれています。 customer3
データベース、customer4
データベースなど。
上記のオプション#2では、単一のデータベース/スキーマ、たとえばmyapp_db
、再び10個のテーブルが含まれます(上記と同じ)。しかし、ここでは、すべての顧客のデータがこれらの10個のテーブル内に存在するため、テーブルを「共有」します。また、アプリケーション層では、10のテーブルのどのレコードにどの顧客がアクセスできるかをロジックとセキュリティで制御し、顧客#1がアプリにログインせず、顧客#3のデータなどを表示しないように細心の注意を払っています。
これらのパラダイムのうち、従来の「マルチテナント」DBを構成するものはどれですか?また、どちらでもない場合、マルチテナントDBの例を(上記のシナリオを使用して)誰かに教えてもらえますか?
これらのパラダイムのどれが伝統的な「マルチテナント」DBを構成するか
両方の概念はマルチテナンシーと呼ばれます。これは、論理的な概念 "であり、ソフトウェアの単一のインスタンスがサーバーで実行され、複数のテナントにサービスを提供する" (- Wikipediaから )。しかし、この概念を「物理的に」どのように実装するかはあなた次第です。
もちろん、アプリケーションには異なるテナントのデータを分離できるデータベースの概念が必要です。マルチテナンシーのアイデアは、リソースの利用率を高め、管理を容易にするために、サーバーリソース(少なくともハードウェア)を共有することです。したがって、「マルチテナントDB」は、これを直接サポートするものであり、dbモデルまたはテーブルの一部が共有されます。
正確には、非マルチテナントDBを使用してマルチテナントアプリケーションを構築し、クライアントごとに個別のDBインスタンスを提供することが可能です。ただし、これにより、DBリソースをテナント間で直接共有することができなくなり、アプリケーションレイヤーは、適切なテナントを適切なデータベースに確実に接続する必要があります。
Microsoftによると、この用語には3つの潜在的な意味があります(すべてのテナントに対して1つのデータベース、またはテナントごとに1つのデータベース作成者)。
この例を使用するには、各顧客がそれ自体のテナントになります。
テナントごとのデータベース(顧客)
共有データベース、個別のスキーマ。
共有データベース、共有スキーマ。
それぞれに長所と短所があり、この記事でよく説明されています: https://msdn.Microsoft.com/en-us/library/aa479086.aspx
おまけ:あなたはそれを居住区と考えることができます(かなり単純化されています)。
すべてのテナントは自分の家を持っています。彼らは彼らがやりたいことを何でもすることができます、そしてそれが燃え尽きても、それは他の誰にも影響を与えません。
すべてのテナントは同じ建物内にありますが、独自のアパートがあります。
誰もが同じアパートに住んでいて、すべてのものには付箋が付いています。