共有テーブル構造を持つマルチテナントデータベースを作成する方法
現在、当社のソフトウェアはMySQLで実行されています。すべてのテナントのデータは同じスキーマに保存されます。 Ruby on Railsを使用しているので、どのデータがどのテナントに属しているかを簡単に判断できます。妥協したため、他のソリューションを評価しています。
これまでのところ、3つのオプションを見てきました。
- マルチデータベース（各テナントが独自に取得-顧客ごとに1台のサーバーとほぼ同じ）
- マルチスキーマ（MySQLでは使用できません。各テナントは共有データベースで独自のスキーマを取得します）
- 共有スキーマ（現在のアプローチ、各列に追加の識別レコードがある場合があります）
マルチスキーマは私のお気に入りです（コストを考慮）。ただし、新しいアカウントを作成して移行するのは非常に苦痛のようです。すべてのスキーマを反復処理し、テーブル/列/定義を変更する必要があるためです。
Q： Multi-Schemaは、テナントごとにわずかに異なるテーブルを持つように設計されているようです-これは望ましくありません。テーブル構造がすべてのテナント間で共有されるマルチスキーママルチテナントソリューションを使用できるRDBMSはありますか？
追伸マルチとは、ウルトラマルチ（10.000+テナント）のようなものを意味します。
ただし、データが危険にさらされることを恐れる企業はもちろんあるため、他のソリューションを評価しています。
物理的な隔離だけで十分なセキュリティを提供できるという誤解に顧客が苦しむことがあるため、これは残念です。
Multi-Tenant Data Architecture というタイトルの興味深いMSDN記事がありますので、確認してください。これは、著者が共有アプローチに対する誤解に対処した方法です。
物理的な分離のみが適切なレベルのセキュリティを提供できるという一般的な誤解があります。実際、共有アプローチを使用して保存されたデータは、強力なデータ安全性も提供できますが、より洗練された設計パターンの使用が必要です。
技術的およびビジネス上の考慮事項に関して、この記事では、特定のアプローチが他のアプローチよりも適切である可能性のある場所について簡単に分析します。
提供するテナントの数、性質、およびニーズはすべて、データアーキテクチャの決定にさまざまな形で影響します。次の質問の中には、より孤立したアプローチに偏っている場合もあれば、より共有されたアプローチに偏っている場合もあります。
あなたは何人の見込み入居者をターゲットにすると思いますか？権限を使用して将来の使用を推定することはほとんどできないかもしれませんが、桁違いに考えてください。数百のテナント用のアプリケーションを構築していますか？何千人？何万もの？もっと？テナントベースの規模が大きいほど、より共有されたアプローチを検討する可能性が高くなります。
平均的なテナントのデータが占めると予想されるストレージスペースはどれくらいですか？一部またはすべてのテナントが非常に大量のデータを保存すると予想される場合は、おそらく個別データベースのアプローチが最適です。 （実際、データストレージ要件により、とにかく個別のデータベースモデルを採用しなければならない場合があります。その場合、後で個別のデータベースアプローチに移行するよりも、最初からアプリケーションを設計する方がはるかに簡単です。）
平均テナントは何人の同時エンドユーザーをサポートすると予想していますか？数値が大きいほど、エンドユーザーの要件を満たすためのより適切なアプローチがより適切になります。
テナントごとのバックアップおよび復元機能など、テナントごとの付加価値サービスを提供する予定ですか？このようなサービスは、より分離されたアプローチを通じて提供する方が簡単です。
UPDATE：さらに、予想されるテナント数について更新します。
予想されるテナント数（10k）は、すべてではないにしても、ほとんどのシナリオで、マルチデータベースアプローチを除外する必要があります。 10,000のデータベースインスタンスを維持し、毎日何百もの新しいインスタンスを作成しなければならないという考えに夢中になるとは思いません。
そのパラメーターだけからは、共有データベース、単一スキーマのアプローチが最も適しているように見えます。テナントごとに約50Mbだけを保存し、テナントごとのアドオンがないという事実により、このアプローチはさらに適切になります。
上記のMSDNの記事では、共有データベースアプローチのセキュリティに関する考慮事項に取り組む3つのセキュリティパターンについて言及しています。
アプリケーションのデータ安全対策に自信があれば、強力なデータ安全性保証を提供する Service Level Agrement をクライアントに提供できます。 SLAでは、保証とは別に、データが危険にさらされないようにするために講じる対策を説明することもできます。
更新2：どうやらMicrosoftの関係者はこの主題に関して移動/新しい記事を作成したようで、元のリンクはなくなり、これは新しいものです： マルチテナントSaaSデータベーステナントパターン （Khais to Shai Kerer）
以下は、マルチテナンシーの実装方法に関するSalesforce.comのホワイトペーパーへのリンクです。
http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf
500個の文字列列（Value0、Value1、... Value500）を持つ1つの巨大なテーブルがあります。日付と数値は、データベースレベルでネイティブタイプに変換できる形式の文字列として保存されます。テナントごとに一意のデータモデルの形状を定義するメタデータテーブルがあります。インデックス付け、関係、一意の値などのための追加のテーブルがあります。
面倒なのはなぜですか？
各テナントは、データベースレベル（変更テーブルなど）で変更を行うことなく、実行時に独自のデータスキーマをカスタマイズできます。これは間違いなくこのようなことをするのに難しい方法ですが、非常に柔軟です。
私の経験（SQL Serverとはいえ）は、各クライアントが独自のデータベースを持っているマルチデータベースが道であるということです。したがって、mySQLがないかRuby on Railsの経験がありますが、入力に何らかの価値が加わることを期待しています。
含まれる理由：
- データセキュリティ/災害復旧。各企業のデータは他と完全に別々に保存され、データが危険にさらされるリスクを低減します（コードバグを導入すると、他のクライアントデータを誤って見るべきではないことを意味します）。特定のデータベースが破損するなど。クライアントに認識されるセキュリティ上の利点はさらに大きくなります（ボーナスの副作用が追加されます！）
- スケーラビリティ。基本的に、データをパーティション化して、スケーラビリティを高める必要があります。データベースを別のディスクに配置できるため、複数のデータベースサーバーをオンラインにしたり、データベースを簡単に移動して負荷を分散したりできます。
- 性能調整。 1つの非常に大きなクライアントと1つの非常に小さなクライアントがあるとします。使用パターン、データ量などは大きく異なる場合があります。必要に応じて、クライアントごとに簡単に調整/最適化できます。
これがいくつかの有用な入力を提供することを願っています！他にも理由はありますが、私の心は空になりました。キックバックされたら、更新します:)
編集：
この回答を投稿したので、10,000人以上のテナントと話していることが明らかになりました。私の経験は数百の大規模なデータベースにあります-10,000の個別のデータベースがあなたのシナリオにとって管理しすぎるとは思わないので、私はあなたのシナリオにmulti-dbアプローチを支持しません。特に今では明らかなように、あなたは各テナントの小さなデータ量について話しているのです！
とにかく、同様のボートの他の人々のためにいくつかの用途があるかもしれないので、私の答えをここに保持します（より少ないテナントで）
あなたが言及したように、テナントごとに1つのデータベースはオプションであり、それといくつかの大きなトレードオフがあります。これは、1桁または数十のテナントなどの小規模でうまく機能しますが、それを超えると管理が難しくなります。両方の移行だけでなく、データベースの稼働を維持するだけでも。
スキーマごとのモデルは、それぞれの一意のスキーマに対してのみ有用ではありませんが、すべてのテナント間で移行を実行することは依然として難しくなり、数千のスキーマでPostgresに問題が発生する可能性があります。
よりスケーラブルなアプローチでは、テナントをランダムに分散し、同じデータベースに格納しますが、異なる論理シャード（または tables ）に格納します。言語に応じて、これを支援できるライブラリがいくつかあります。 Railsを使用している場合は、テナントを強化するライブラリがあります acts_as_tenant 、テナントクエリがそのデータのみをプルバックするようにします。 gemもあります apartment -スキーマモデルを使用しますが、すべてのスキーマにわたる移行を支援します。 Djangoを使用している場合、いくつかありますが、より人気のあるものの1つは schemas です。これらはすべて、アプリケーションレベルでさらに役立ちます。 'データベースレベルで直接何かを探しています Citusmulti-tenancy のこのタイプのシャーディングをPostgresでより簡単に動作させることに焦点を当てています。