テナントごとのデータベースアプローチ、単一または複数のデータベースサーバー？
マルチテナンシーのためのさまざまなアプローチを調査する必要があります。現在、私はデモアプリケーションを拡張して、テナントごとのデータベースアプローチを使用しています。
ここで、単一のデータベースサーバーアプリケーションで独自のスキーマを使用して複数のデータベース構造を作成できることを確信できなくなりました。テナントごとのデータベースが何を参照しているのか疑問に思います。
異なるポートで実行されている実際のデータベースサーバー。
または
単一のデータベースサーバー内のデータベース構造。
テナントごとのデータベースが何を指しているのかと思います
それは両方を参照することができます、その用語の「唯一の」正しい定義のようなものはありません。
ただし、どちらの方法を使用するかを尋ねる場合、接続先のデータベース名とサーバーを自由に構成できるようにクライアントアプリケーションを設計することをお勧めします。次に、単一のサーバーハードウェアで、選択したDBMSスタックが許可する最も単純なソリューションから始め、それが（パフォーマンスまたはセキュリティの観点から）要件を満たさなくなった場合は、より複雑なソリューションを選択します。
TLDR;これを考えすぎないでください。大きく考え、小さく始めます。
これは主にアプリケーションの要件によって異なります。
- 1つのオプションは、単一のデータベースサーバー/クラスターを用意し、テナントごとにデータベースを用意することです。
- 単一のデータベースを使用することもできますが、マルチテナンシーを提供するようにテーブルを配置します。最上位には組織テーブルがあり、すべてがそれにアタッチされています。セキュリティと監査はよりトリッキーであることがわかるかもしれませんが、これもかなり一般的です。
- 実際に複数のデータベースサーバーを使用することもできますが、特に単一のバックエンドを使用する場合は、それには十分な理由があるはずです。通常、その組み合わせは私にはあまり意味がありません。おそらく、データベースクラスター自体をリージョンごとに設定するのが容易ではなく、レイテンシやデータの保存場所に関する要件がある場合でも、複数のバックエンドが必要になると思います。
「異なるポートで実行されている実際のデータベースサーバー」を使用しないことをお勧めします。これにより、不要な構成の問題（ファイアウォール）が発生するためです。
2番目のアプローチ「単一のデータベースサーバー内のデータベース構造」は、より優れたアプローチです。 @Sebastiaan van den Broekは、マルチテナンシーを提供するために別々のテーブルを用意することを提案しましたが、これの問題は、データベースとの間でデータをマップするスキーマや自動ツール（ORMなど）がうまく機能しないことです。
複数の個別のデータベースサーバーを用意することは、それを保証するだけの十分なトラフィックがない限り、実際にはやりすぎです。次に、複数のテナントをサーバー間で（かなり透過的に）分割できます。