SaaSモデル、クライアントごとに1DB
コンテキスト
私たちはウェブベースのシステムを構築しており、設計上の決定の1つ（database related）は、1つのメインDBがすべてのクライアントデータVSを管理するかどうかでしたクライアントごとに1 DB。問題についてたくさん読んだ後（特にこれらのフォーラム）、クライアントごとに1 DBの方が全体的に良いアプローチであるようです。長期的に、特に私たちのユースケースで。
基本アーキテクチャ
私たちのシステムは主にフロントエンドシステムであり、RESTful Webサービスからデータをプルして（クライアントデータが配置されている場所）、一意のWebサービスにアクセスしますキー、各キーはCLIENT：DATABASEの特定のペアに属しています。
物事がトリッキーになるところ
新しいクライアントがアカウントを作成するときのアイデアは、Webサービスに新しい[〜＃〜] db [〜＃〜]、DBユーザーおよび-を自動作成させることですAPIキーそのアカウント用。これを実装する標準的な方法を探しましたが、決定的なものは見つかりませんでした。明らかに、SaaSプロバイダーはこれを自動化しますが、私が理解できないのはどのようにしてこれを行うか安全にです。
私が現在持っている唯一の解決策は、ある種のMASTER MySQLユーザーを作成することです。これは、これらのDBとDBユーザーのペアを作成するために使用する、MySQLに対して絶対的なフルパワーを持ちます。 しかし、これは非常に危険なセットアップのように感じられるため、唯一の解決策とは言えません。このユーザーへの妥協は致命的です。これは私があなたの助けを必要とするところです...
もう1つの疑問は、MySQL/innoDBでDBサイズを制限する方法です。私が見つけた唯一のことは、MySQLがTABLE SIZEのみを制限できることです。そして、より洗練されたコンテキストでは、そのDBは特定のディスククォータを持つ別のディレクトリに格納されます（これは一部のWebホスティングプロバイダーによって使用されているようです...しかし、確認できません）。 誰かがDBサイズを制御する他の方法を知っていますか？
これは、従来のシングルテナントとマルチテナントのジレンマです。複数のクライアントにサービスを提供するには、次のことを行う必要があります。
- すべてのクライアントのデータを含む単一のデータベースを用意する（つまり、単一のデータベースのすべてのテナントにする）、または
- 複数のデータベースを用意し、各クライアントをパーティション分割して、単一のテナントが独自のデータベースとのみ対話するようにします。
私が知っているSaaS（およびその他のXYZ-as-a-service）ショップ）のほとんど、およびほとんどすべてのインターネット規模のプロパティ（Google、Facebook、Twitterなど）は、強く好みますマルチテナントモデル。通常、マルチテナントの方がパフォーマンスの点でより効率的ですが、管理オーバーヘッドを最小限に抑えるにはさらに効率的です。client_idで区切られたさまざまなクライアントのデータを使用して、設定して心配するデータベースは1つだけです。価値がありますが、魔法のような解決策はありません。「すべての卵を1つのバスケットに入れる」場合、そのバスケットを保護するためにさらに努力する必要があります。また、成功すると、オールインワンデータベースが急速に大きくなる可能性があります多くのクライアントがいて、配布、レプリケーション、インデックス作成、その他のスケーラビリティとサービス品質の最適化への投資を必要としています。SaaSの開発者とインターネット規模のサービスは、インフラストラクチャに膨大な時間とエネルギーを投資しています。
一部のas-a-serviceショップはシングルテナント構成を使用しており、クライアントはそれぞれ独自のデータベースインスタンスを持っています（多くの場合、個別の仮想マシンまたは仮想環境）。 1つの理由は、明らかな「より大きな分離」の美徳です。これは、より強力なセキュリティとプライバシー保護を備えているとしばしば認識されています。これは単なる技術的な属性ではありません。それはまた、顧客の好みと販売の容易さの問題でもあります。
シングルテナントとマルチテナントは優れたラベルですが、2つの極の間には多くの中間的アプローチとハイブリッドアプローチがあります。たとえば、複数の「データベースインスタンス」を実行している単一のデータベースマネージャーは、多くのWordPressホストによって使用されているアーキテクチャです。これは、「マルチテナントライト」または「ハウスメイト」のシナリオ。設定をより小さくしていくためには、多くの利点があります。
使用前にいくつかのデータベースを事前に作成することを検討し、新しいクライアントがアカウントを作成するときに、クライアントのアカウント名から事前に作成されたDBへのマッピングを記録しましたか？このようにして、DBMSが管理するには多すぎるデータベースを自動作成するサービス拒否攻撃を制限できます（事前に作成されたデータベースのリストが不足するため）。また、日常のデータベース作成特権の必要性を回避できます。 1日のユーザーインタラクション。
同時にデータベースサーバーをマッピングに含めた場合、つまり「クライアント名」->「サーバー：事前作成されたデータベース名」のマッピングを使用した場合、データベースをサーバーからサーバーに移動するだけでシャーディングを動的に管理することもできます。サーバーとマスターマップの更新。これは、中央のlib/fileとして、またはマスターDBに保存できます。
（たとえば）事前に作成されたDBのセットに毎日データを入力した場合、一度に番号を自動調整できます。