9

私は SAAS アプリケーションを構築しており、クライアントごとに 1 つのデータベースと共有データベースについて話し合っています。私はここSOでいくつかのトピックを含め、たくさん読んだことがありますが、まだ多くの疑問があります.

私たちのプラットフォームは、各クライアントが高度にカスタマイズできる必要があります。(カスタム テーブルを作成し、カスタム フィールドを既存のテーブルに追加できる必要があります)。この場合、複数データベースのアプローチは素晴らしいようです。

問題は。私の「ユーザー」テーブルは、マスターデータベースまたは各クライアントデータベースにあるべきですか?. ユーザーは 1 つ以上の組織を持つ場合があるため、複数のデータベースに存在します。また、国のテーブルなどの一般的なテーブルはどうですか?

master データベースにあることは理にかなっています。しかし、ユーザーへの外部キーを持つ created_by フィールドを持つ多くのテーブルがあります。また、クライアントごとにいくつかの権限関連のテーブルがあります。

データベースが複数ある場合、外部キーの力が失われます。これは、データベースへのクエリが増えることを意味します。データベースが同じサーバーにある場合、データベース間でクロス結合を使用できることはわかっていますが、スケーラビリティが失われます。（将来、複数のデータベースサーバーが必要になるかもしれません）。連合テーブルについて考えました。パフォーマンスについては不明です。

私が使用しているテクノロジーは、php と symfony 2 フレームワーク、およびデータベース用の mysql です。

また、そのようなシステムのメンテナンスが怖いです。すべてのデータベースでスキーマの変更を自動化するスクリプトをいくつか作成することもできますが、クライアントが 10,000 の場合、10,000 のデータベースを意味します。

これについてどう思いますか。私のアプリの主な特徴は柔軟性である必要があるため、クライアントがベース プラットフォームにないものよりも具体的なものが必要な場合は、それを実行できるはずです。

4

1 に答える 1

22

ここにいくつかの古典的な問題。http://highscalability.com/に行ったことはありますか？そこにいくつかの良いケーススタディ。

個人的な経験から、1つのサーバーでクライアントを共有しようとすると、非常に成功したアクティブなユーザーが時間の経過とともにマシンのすべてのリソースを使用することがわかります。SAASに1人のクライアントがいて、共有サーバーを破壊したため、彼を別の場所に移動する必要がありました。

グローバルな列挙をサービスにリッピングします。国のリスト、州のリストなどの1つの中央データベースを作成し、それをWebサービスレイヤーの背後に配置できます。また、そのデータベースでは、ユーザー管理/どのサーバーがどのユーザーに属するかなどを管理できます。ユーザーベースを管理するために、このデータベースに対して読み取り/書き込みを行う管理ポータルを作成できます。

もう一度SAASを実行する場合は、小さく始めて、痛みが発生するのを待ちます。本当に必要なのは、スケーリングの問題が発生したときに対処するための優れたツールです。サーバー間でスキーマ変更をローリングする準備ができているスクリプトをいくつか用意します（複数のサーバーがある場合、これを回避する方法はありません）。スキーマを変更している間、マシンを停止するスクリプトを用意します。ユーザーを共有サーバーから専用サーバーに移行するためのスクリプトを用意します。

中央データベースからレプリケーションを設定することを検討してください。これにより、多くのコードを記述しなくても、各ユーザーパーティション/データベースに必要なグローバル情報が削減されます。

しかし、私が見た、そして直接経験した最大のアドバイスは、規模を拡大するために次のFacebookを構築するために一生懸命努力しないでください。単純なものから始めて、スケーラビリティの大きな問題を心配する前に、実際に何が起こるかを確認してください。ユーザーベースが拡大するにつれて、拡張性の高いものとそうでないものに驚かれるかもしれません。

于 2013-01-28T19:12:34.203 に答える