複数のスキーマと巨大なテーブル

Question

電話にインストールしたアプリを保存するテーブル、監査、通知情報など、すべてのユーザーの情報を含むモバイルデバイスマネージャーシステムを検討してください。対応するテーブルを持つ各ユーザーの別のスキーマを作成することは賢明ですか？テーブルの数は、それぞれ約30のテーブルに相当する単一のユーザーに大きいです。これらすべての情報がこれらのテーブルに配置され（順番に巨大なテーブルを作成しますか？）、各ユーザーにスキーマがある別のスキーマがある方が良いでしょうか？

前もって感謝します

Answer 1

データベースでのクエリに関して、どの方法がより効率的であるかを確認したいと思います。

マルチテナントデータベースでは、クエリは問題の一部にすぎません。問題の他の部分は、コスト、データの分離と保護、メンテナンス、災害復旧です。これらは重要です。あなた できません 検討 それだけ マルチテナントデータベースのクエリ効率。

マルチテナントソリューションは、テナントごとに1つのデータベース（共有されていない）から、テナントごとに1列（すべてを共有）までの範囲です。

「共有されていない」、「個別のデータベース」、またはテナントごとに1つのデータベース

• クライアントごとに最も高価です。 （多数のクライアントが多数のサーバーを暗示しています。）
• 最も高いデータ分離。
• 単一のテナントの災害復旧は、シンプルで簡単です。
• メンテナンスはです 理論的に すべてのデータベースで変更を実行する必要があるため、より難しいです。ただし、DBMSは、各データベースでのストアドプロシージャの実行を簡単にサポートする場合があります。 （SQL Serverには、文書化されていないシステムストアドプロシージャがあります。たとえば、SP_MSFOREACHDBです。おそらく独自のものを書くことができます。）「共有されたものは何もない」も最も簡単にカスタマイズ可能ですが、メンテナンスの問題も発生します。
• テーブルあたりの行の最低数。クエリ速度は最適です。

「すべてを共有」、または「共有スキーマ」、または「惑星ごとに1つのデータベース」

• テナントごとに少ない。
• データ分離の最低度。すべてのテーブルには、行が属するテナントを識別する列があります。テナントの行はすべてのテーブルに混合されているため、他のテナントのデータを誤って公開するのは比較的簡単です。
• 単一のテナントの災害復旧は比較的複雑です。多くのテーブルで個々の行を復元する必要があります。一方、単一テナントの災害は比較的珍しいです。ほとんどの災害は、おそらくすべてのテナントに影響を与えるでしょう。
• すべてのテナントがテーブルを共有していることを考えると、構造のメンテナンスはより簡単です。ただし、各変化をすべてのテナントと通信して調整する必要があるため、通信負荷が増加します。簡単にカスタマイズできません。
• テーブルあたりの行の数。クイッククエリは難しくなりますが、テナントの数といくつの行によって異なります。 VLDBの領土に簡単に傾けることができます。

「Shared Nothing」と「Shared Everything」の間では「共有スキーマ」です。

「共有スキーマ」

• テナントはデータベースを共有していますが、各テナントには独自の名前のスキーマがあります。 「共有されていない」と「共有されたすべて」の間にコストがかかります。大規模なシステムは通常、「共有されていない」よりも、「共有されたすべてのもの」よりも多くのサーバーよりも少ないサーバーが必要です。
• 「すべてを共有した」よりもはるかに良い隔離。 「共有されていない」ほど孤立していません。 （スキーマに許可を付与および取り消すことができます。）
• 単一のテナントの災害復旧には、多くのスキーマの1つを復元する必要があります。これは、DBMSに応じて比較的簡単であるか、かなり硬いです。
• メンテナンスは「共有されていない」よりも簡単です。 「すべてを共有した」ほど簡単ではありません。データベース内の各スキーマで実行されるストアドプロシージャを作成するのは比較的簡単です。 「共有されていない」よりも、テナント間で一般的なテーブルを共有する方が簡単です。
• 通常、サーバーごとのアクティブなテナントが「共有されていない」よりもアクティブなテナントが多いため、より多くのリソースを共有（劣化させる）ことを意味します。しかし、「すべてを共有した」ほど悪くはありません。

Microsoftには良い記事があります マルチテナントアーキテクチャ 詳細が付いています。 （リンクは、マルチページドキュメントの1ページのみです。）