顧客ごとに個別のDBスキーマを使用するマルチテナントアーキテクチャを使用する利点は何ですか？
SaaSアプリケーションをマルチテナントアーキテクチャで構築することを望んでいるクライアントがいます。この場合、異なるクライアントが同じdbサーバー上の別々のスキーマに移動します。このアーキテクチャは以前に見たことがあります。でも実際に使ったことはなかったので、私はこのコンセプトにかなり慣れていません。
アプリにある程度の複雑さが加わると思うので、私はこれに強く反対します。彼らの最大の懸念はセキュリティです。
これを使用することで確認できる唯一のセキュリティ改善は、開発者の過ちからユーザーを保護することです。
- SQLインジェクション
- SQLクエリの無効または不足している顧客フィルター。
これらの問題はどちらも、最新の開発フレームワーク（Djangoを使用する予定です）でかなりうまく処理されます。これ以外に、私は本当に利点を見ることができません。
「アプリがある程度複雑になると思います」
...何に反対します-すべてのテナントに1つのスキーマのみを使用しますか？
その場合、通常はその逆になります。 1つのスキーマにマルチテナンシーを実装すると、データが異なるテナントに属している可能性があるすべてのテーブルに複雑さが追加されます。つまり、この種の複雑さはアプリにも影響します。特に多くのテーブルがある場合、実際には別々のスキーマを持つreducesアプリの複雑さ。スキーマをランタイムの構成可能なパラメーターにすると、テナントが1つしかないかのようにアプリを開発できます。
さらに、テナントごとの個別のバックアップ/復元などの個別の管理タスクが非常に簡単になります。異なるバージョンのスキーマを持つ異なるテナントを同時に本番環境で許可することもできます。
すべてのテナントに1つのスキーマがあることは、スキーマ内のデータの大部分がすべてのテナントで同じであり、そのデータがテナントによって個別に管理されていない場合にのみ有益です。
もちろん、複数スキーマのアプローチで避ける必要があるのは、個々のテナントに対する異なるスキーマのカスタマイズです。これは、避けたい一種の複雑さを実際に追加します。スキーマの変更は常にバージョン管理されたスクリプトによって実装され（「オンザフライ」ではなく）、それらのスクリプトをすべてのスキーマに対して自動的に実行できるようにします（単一のスキーマを使用している場合でも、通常は少なくとも開発用データベース、テスト用データベース、管理用の本番用データベース）。
DBMSによっては、さまざまなデータベースインスタンスの使用を検討することもできます。これにより、スケーリングのエクスペリエンスが向上する場合があります。 Oracleのようなシステムでは、さまざまなDBインスタンスを管理するための管理オーバーヘッドがあるため、さまざまなスキーマの方が適している場合があります。 MySqlのようなシステムの場合、さまざまなデータベースインスタンスが有効で、おそらくより良いアプローチです（ケースによって異なります）。
マルチテナントアーキテクチャには、スケーラビリティとセキュリティの利点があります。 1つのテーブルにすべてのクライアントデータがある場合、すべての顧客はすべての顧客データにアクセスできます。このアクセスを制限するために記述したコードは計算されません。マルチテナントアーキテクチャでは、dbにさまざまなユーザーを設定し、認証プロセスの設計をはるかに簡単にすることができます。
スケーラビリティの観点から見ると、クエリをスローダウンさせるような巨大なインデックスを検索する必要はありません。データは異なる顧客に属しているため、少なくとも顧客の視点からのデータには関係がありません。このため、データを分離することには意味があります。
異なるインスタンスでアーキテクチャをセットアップする場合も、必要な場所にリソースを割り当て、セキュリティのレベルを追加できます。
さまざまなインスタンスを使用すると、アプリケーションの機能によっては複雑になるだけでなく、非常に適切になる場合があります。
このアーキテクチャがアプリケーションを複雑にすることに同意しません。どちらかといえば、それは単純化する必要があります。