[解決済み] テーブル構造を共有するマルチテナントデータベースを作成するには？

質問

私たちのソフトウェアは現在 MySQL で動作しています。すべてのテナントのデータは、同じスキーマに格納されています。私たちは Ruby on Rails を使用しているので、どのデータがどのテナントに属しているかを簡単に判断できます。しかし、データが漏洩することを恐れる企業ももちろんありますので、他のソリューションを評価しているところです。

今のところ、3つのオプションを見ています。

• マルチデータベース (各テナントがそれぞれを取得します。顧客ごとに 1 台のサーバーとほぼ同じです)
• マルチスキーマ (MySQLでは利用できません。各テナントが共有データベースで独自のスキーマを取得します。)
• 共有スキーマ (現在のアプローチ。各カラムに識別レコードが追加されるかもしれません)

マルチスキーマは私のお気に入りです (コストを考慮すると)。しかし、新しいアカウントを作成し、移行を行うことは、すべてのスキーマを繰り返し、それらのテーブル/列/定義を変更しなければならないので、かなり苦痛になるようです。

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

追伸：マルチというのは、超マルチ (10.000 以上のテナント) のようなものを意味しています。

どのように解決するのですか？

しかし、企業によっては しかし、中にはデータの漏洩を恐れる企業もあります。 そのため、私たちは他のソリューションを評価しています。 他の解決策を検討しています。

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

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

よくある誤解として 物理的な分離のみが適切なレベルのセキュリティを提供することができる 適切なレベルのセキュリティを提供できると考えられています。しかし を使用して保存されたデータも、強力なデータセキュリティを提供することができます。 て保存されたデータも、強力なデータ安全性を提供することができます。 の安全性を確保することができますが、より高度な設計パターンを使用する必要があります。 より洗練されたデザインパターンを使用する必要があります。

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

サービスを提供するテナントの数、性質、ニーズは テナントの数、性質、およびニーズはすべて データアーキテクチャの決定に 影響を与えます。次のような は、より分離されたアプローチに偏るかもしれません。 を選択する場合もあれば、より共有化されたアプローチを選択する場合もあります。 より共有的なアプローチに偏るものもあります。 アプローチに偏るかもしれません。

• ターゲットとする入居希望者は何人くらいでしょうか？このままでは 推定することはできませんが を推定するのは難しいかもしれませんが 桁数で考えてみてください。 数百人のテナントを対象としたアプリケーションを構築するのですか？ 数百人のテナント？数千人？数万人？ 数千人？それ以上？テナント数が多ければ多いほど テナントの規模が大きくなればなるほど より共有型のアプローチを検討することになります。 より共有のアプローチを検討することになるでしょう。

• 平均的なテナントのデータが占めるストレージ容量はどの程度になると予想されますか？ 一部またはすべてのテナントが非常に大量のデータを保存することを想定している場合 非常に大量のデータを保存するのであれば 分離データベースのアプローチがおそらく がベストでしょう。(実際、データストレージの要件により を採用せざるを得ないかもしれません。 を採用せざるを得ないかもしれません。もしそうなら を設計するのはずっと簡単です。 アプリケーションを最初からそのように設計する方が を設計する方が、後で分離型に移行するよりもずっと簡単です。 後で別々のデータベースのアプローチに移行するよりも、最初からそのようにアプリケーションを設計する方がはるかに簡単です)。

• 平均的なテナントがサポートする同時使用エンドユーザーは何人くらいを想定していますか? 数が多ければ多いほど、より より分離されたアプローチが適切です。 が適切です。

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

UPDATE 入居予定者数について、さらに更新しました。

予想されるテナントの数 (10k) は、すべてのシナリオではないにしても、ほとんどの場合、マルチデータベース方式を除外する必要があります。10,000 個のデータベース インスタンスを維持し、毎日何百もの新しいインスタンスを作成しなければならないというのは、あまり好ましいこととは思えません。

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

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

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

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

UPDATE 2: どうやらマイクロソフトの連中はこの件に関して新しい記事を移動/作成したようで、元のリンクはなくなり、これが新しいものです。 マルチテナント型 SaaS データベースのテナントパターン (Shai Kererに感謝)