共有テーブル構造を持つマルチテナントデータベースを作成するにはどうすればよいですか？

私たちのソフトウェアは現在MySQLで実行されています。すべてのテナントのデータは同じスキーマに格納されます。Ruby on Railsを使用しているため、どのデータがどのテナントに属しているかを簡単に判別できます。ただし、データが危険にさらされるのではないかと恐れている企業もあるので、他のソリューションを評価しています。

これまでのところ、3つのオプションを見てきました。

• マルチデータベース（各テナントは独自に取得します-顧客ごとに1つのサーバーとほぼ同じです）
• マルチスキーマ（MySQLでは使用不可、各テナントは共有データベースで独自のスキーマを取得します）
• 共有スキーマ（現在のアプローチ。各列に追加の識別レコードがある場合があります）

Multi-Schemaは私のお気に入りです（コストを考えると）。ただし、新しいアカウントを作成して移行を行うのは、すべてのスキーマを繰り返し処理し、それらのテーブル/列/定義を変更する必要があるため、非常に困難なようです。

Q：マルチスキーマは、テナントごとにわずかに異なるテーブルを持つように設計されているようです-これは必要ありません。テーブル構造がすべてのテナント間で共有されているマルチスキーマ、マルチテナントソリューションを使用できるRDBMSはありますか？

PSマルチとは、ウルトラマルチ（10000以上のテナント）のようなものを意味します。

ただし、データが危険にさらされるのではないかと恐れている企業もあるので、他のソリューションを評価しています。

物理的な分離だけで十分なセキュリティを提供できるという誤解に顧客が悩まされる場合があるため、これは残念です。

マルチテナントデータアーキテクチャというタイトルの興味深いMSDNの記事がありますので、確認してください。これは、著者が共有アプローチに対する誤解に対処した方法です。

よくある誤解は、物理的な分離だけが適切なレベルのセキュリティを提供できるということです。実際、共有アプローチを使用して保存されたデータも強力なデータの安全性を提供できますが、より洗練された設計パターンを使用する必要があります。

技術的およびビジネス上の考慮事項について、この記事では、特定のアプローチが他のアプローチよりも適切である可能性がある場所について簡単に分析します。

提供する予定のテナントの数、性質、およびニーズはすべて、データアーキテクチャの決定にさまざまな方法で影響します。次の質問の中には、より孤立したアプローチに偏る可能性のあるものもあれば、より共有されたアプローチに偏るものもあります。

• どれくらいの見込みテナントをターゲットにすると思いますか？権限を使用して将来の使用を見積もることはほとんど不可能かもしれませんが、桁違いに考えてください。何百ものテナントのアプリケーションを構築していますか？何千？何万もの？もっと？テナントベースが大きくなると予想されるほど、より共有されたアプローチを検討する可能性が高くなります。

• 平均的なテナントのデータが占めると予想されるストレージ容量はどれくらいですか？一部またはすべてのテナントに非常に大量のデータを格納することが予想される場合は、個別のデータベースによるアプローチがおそらく最適です。（実際、データストレージの要件により、とにかく個別のデータベースモデルを採用する必要がある場合があります。その場合、アプリケーションを最初から設計する方が、後で個別のデータベースアプローチに移行するよりもはるかに簡単です。）

• 平均的なテナントがサポートすると予想される同時エンドユーザーは何人ですか？数値が大きいほど、エンドユーザーの要件を満たすための適切な分離アプローチが適切になります。

• テナントごとのバックアップや復元機能など、テナントごとの付加価値サービスを提供する予定はありますか？そのようなサービスは、より分離されたアプローチにより提供しやすくなります。

更新：予想されるテナント数についてさらに更新します。

予想されるテナント数（10,000）では、すべてではないにしても、ほとんどのシナリオで、マルチデータベースアプローチを除外する必要があります。10,000のデータベースインスタンスを維持し、毎日何百もの新しいインスタンスを作成する必要があるとは思いもしません。

このパラメーターだけから、共有データベースの単一スキーマアプローチが最も適しているように見えます。テナントごとに約50Mbしか保存しないこと、およびテナントごとのアドオンがないことにより、このアプローチはさらに適切になります。

上記のMSDNの記事では、共有データベースアプローチのセキュリティに関する考慮事項に取り組む3つのセキュリティパターンについて言及しています。

• 信頼できるデータベース接続
• テナントビューフィルター
• テナントデータの暗号化

アプリケーションのデータ安全対策に自信がある場合は、強力なデータ安全性を保証するサービスレベルアグリメントをクライアントに提供できます。SLAでは、保証とは別に、データが侵害されないようにするために講じる措置を説明することもできます。

更新2：どうやらMicrosoftの担当者はこの件に関して移動/新しい記事を作成しました。元のリンクはなくなり、これは新しいものです：マルチテナントSaaSデータベースのテナントパターン（kudosからShai Kererへ）

私の経験（SQL Serverとはいえ）は、マルチデータベースが進むべき道であり、各クライアントが独自のデータベースを持っているということです。mySQLやRuby On Railsの経験はありませんが、私の入力が何らかの価値を追加することを望んでいます。

含める理由：

1. データセキュリティ/災害復旧。各企業のデータは他の企業のデータとは完全に別々に保存されるため、データが危険にさらされるリスクが軽減されます（コードバグを導入して、何か他のクライアントのデータを誤って見るべきではないことを意味するなど）、1つのクライアントの損失を最小限に抑えます特定のデータベースが破損するなど。クライアントに認識されるセキュリティ上の利点はさらに大きくなります（ボーナス副作用が追加されます！）
2. スケーラビリティ。基本的に、データをパーティション分割してスケーラビリティを向上させます。たとえば、データベースを別のディスクに置くことができる場合、複数のデータベースサーバーをオンラインにして、データベースを移動し、負荷を分散しやすくすることができます。
3. 性能調整。1つの非常に大きなクライアントと1つの非常に小さなクライアントがあるとします。使用パターン、データ量などは大幅に異なる場合があります。必要に応じて、クライアントごとに簡単に調整/最適化できます。

これがいくつかの有用な情報を提供してくれることを願っています！他にも理由はありますが、私の心は空っぽでした。キックバックした場合は、更新します:)

編集：
私がこの回答を投稿して以来、10,000以上のテナントについて話していることは明らかです。私の経験は何百もの大規模データベースでの経験です-10,000の個別のデータベースがシナリオに対して管理しすぎるとは思わないので、今のシナリオではマルチDBアプローチを好みません。特に、今では明確になっているので、テナントごとに少量のデータを話していることになります。

とにかくここで私の答えを保持することは、同様のボートに乗っている他の人々（テナントの数が少ない）に役立つ可能性があるためです。

以下は、Salesforce.comのマルチテナンシーの実装方法に関するホワイトペーパーへのリンクです。

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

それらには、500個の文字列列（Value0、Value1、... Value500）を持つ1つの巨大なテーブルがあります。日付と数値は、データベースレベルでネイティブ型に変換できるような形式の文字列として格納されます。テナントごとに一意にすることができるデータモデルの形状を定義するメタデータテーブルがあります。索引付け、関係、一意の値などのための追加のテーブルがあります。

なぜ面倒なのか？

各テナントは、データベースレベル（変更テーブルなど）で変更を加える必要なく、実行時に独自のデータスキーマをカスタマイズできます。これは確かにこのようなことをするのは難しい方法ですが、非常に柔軟です。

あなたが言及するように、テナントごとに1つのデータベースはオプションであり、それといくつかの大きなトレードオフがあります。1桁や10の数少ないテナントなど、小規模ではうまく機能しますが、それを超えると管理が難しくなります。移行だけでなく、データベースの稼働を維持するためにも。

スキーマごとのモデルは、それぞれの一意のスキーマに役立つだけでなく、すべてのテナント間で移行を実行することが困難になり、数千のスキーマでPostgresが問題を抱え始める可能性があります。

よりスケーラブルなアプローチでは、テナントをランダムに分散させ、同じデータベースに格納しますが、異なる論理シャード（またはテーブル）にまたがります。言語によっては、これに役立つライブラリがいくつかあります。Railsを使用している場合、テナンシーをacts_as_tenant実行するためのライブラリがあります。これにより、テナントクエリがそのデータのみをプルバックできるようになります。gemもありapartmentます。これはスキーマモデルを使用していますが、すべてのスキーマにわたる移行に役立ちます。Djangoを使用している場合はいくつかありますが、より一般的なものの1つはスキーマ全体にあるようです。これらはすべて、アプリケーションレベルでさらに役立ちます。データベースレベルでさらに何かを直接探している場合、Citusはこのタイプのシャーディングをマルチテナンシーは、Postgresを使用すると、追加設定なしで機能します。