SaaS Web アプリケーション サービスの多くは、企業ベースのコンセプトを持っています。そのため、サービスを使用する各企業には、独自のユーザー、ファイル、およびその他のデータのセットがあります。通常、Web アプリは DB 側でこれをどのように処理しますか? 会社ごとに新しいデータベース (その会社に関連するデータ テーブルを含む) を作成しますか? それとも、単一の DB から関連データを選択するために、ある種の company_id 関係がありますか?
3237 次
4 に答える
12
数か月前、複数のクライアントにサービスを提供する組織でよく使用される製品で、まさにこの問題が発生しました。彼らは、クライアントごとに完全で個別の Web サイトを作成できるように、SaaS システムを変更するように依頼してきました (オンラインのドメイン固有の Web サイト構築ツールを構築しています)。
簡単にまとめると、すべての人を 1 つのデータベースに配置するのは当然のことのように思えるかもしれませんが、詳しく調べてみると、それが常に完全であるとは限らないことがわかります。作業を進めていく上で覚えておきたい課題がいくつかあります。いくつかのポイント：
まず、「Company_id」をいくつかのテーブルに追加するだけでは不十分です。実際、企業ごとにデータベース/アプリを用意するのはばかげているという Sai のコメントにもかかわらず、複数の個別のクライアント用に SaaS システムをホストすることの根本的な複雑さのために、これが理にかなっているケースは絶対にあります。あなたが単にいくつかの異なる会社にサービスを提供している (例えば、請求書を作成している) 場合、Sai のコメントはまったく真実です。ただし、ソフトウェア アプリケーションを複数の組織に提供している場合は、複雑さがかなり高くなり、個別のデータベースが適している可能性があります。
第 2 に、マルチクライアント データベースでのユーザーのクエリおよびレポート作成作業が非常に複雑になることに備えてください。たとえば、ユーザー クエリ機能を構築する際には、HIPAA で保護されたデータが関係しているため、組織間で「漏れ」が発生しないことを完全に確認する必要がありました。これは、クエリ機能とレポート機能に、以前よりもはるかに高いレベルのエンジニアリングが必要であることを意味していました。私たちの場合、クエリ機能は非常に柔軟であり、本質的にユーザーがその場でクエリを作成することを許可していました (明らかに、かなり厳しい制約がありました - SQL を受け入れていませんでした!)。したがって、必要に応じて「Company_ID」制約を使用するようにすべてのクエリが自動的に変更されるようにする必要がありました。データの出所やクエリを送信するスタッフの許可に関係なく。しわ？私たちの「スーパーユーザー」分析アカウントは、そのような制約なしでクエリを実行できる必要がありました...
第 3 に、分離する必要があるものの数をまだ予測していない可能性があります。たとえば、非常に洗練された「設定」オブジェクトをサイトに組み込みました。このオブジェクトは、起動時にデータベースから設定を取得し、「アプリケーション」オブジェクト (これは .NET アプリです) でそれらを維持します。複数の組織を処理するには、これらすべてをフローティングする必要がありました。
別の例として、以前は一意であったフィールド (ログインなど) は、Company_ID、LoginID キーの一部として実行する必要がありました。ゼロから構築している場合、これはそれほど大きなアイデアではありませんが、改造していたのでそうでした.
とにかく、ビルドを進めていくと、これを正しく行うにはどれだけの作業が必要かを知って驚きました。
第 4 に、私は常に「メタプログラミング」アプローチを使用してソフトウェアを構築します。つまり、単一目的のページを作成することはめったになく、エンド ユーザーのカスタマイズと内部コードの再利用を容易にするために、高度にカスタマイズ可能なフレームワークを作成することがよくあります。これが複数組織のデータベースへの移行に役立つことを期待していましたが、多くの場合、そうではありませんでした! このようなコーディングは最初はかなり複雑であることが多いため、組織をフローティングすることは、単純な Web ページを持っている場合よりも難しいことがよくありました。
最後に、データを共有する必要がなければ (全体的な使用パターンの分析など)、スケーリングを容易にするためだけに個別のデータベースを使用することをお勧めします。新しい複数組織データベース (2 番目の個別システム) を追加する際、私たちのスケーリングには、突然の成長を経験した既存のクライアントが含まれることがよくありました。それらを既存のデータベースから剥がして新しいサーバーに移すことは、既存のデータベースを使用して新しいサーバーに移動するよりも少し困難です。
これらすべての注意事項があるため、1 つのデータベースで複数の組織を処理できるシステムを構築することはお勧めできないと思われるかもしれません。ただし、これは事実ではありません。複数組織のアプローチを採用することで、いくつかの真のメリットが得られます。使用状況分析、組織間レポート、アプリケーション展開などはすべて大幅に強化されています。私たちの経験の恩恵を提供したいと思います.
于 2009-05-10T16:43:33.377 に答える
2
確かにcompany_idです。
新しいデータベースは言うまでもなく、あらゆるものに対して新しいテーブルを作成することはばかげています (実際、多くのデイリー WTF 投稿の餌食になっています)。
リレーショナル データベースを使用することの要点は、すべてをリンクすることです。
その後、データベースを大きくする必要がある場合は、それを行う方法がたくさんあります (マスター/スレーブ、マスター/マルチスレーブ、デュアルマスター、水平スケーリング、大量の RAM の購入など)。
FWIW: 私の最後のアプリには ~1200 万ユーザー (1 日あたり ~300k) がありました。それには 2 つのデータベースがありました (水平方向のスケーリング。以前の人たちによって行われました。私はその決定に同意せず、単にスレーブを使用していたでしょう)。
編集: 警告 - これは、アプリ (Web インターフェイスまたは API) を介してのみアクセスを公開していることを前提としています。
データベースを顧客に直接公開する必要がある場合は、a) 悪い考えなのでもう一度考え直すよう顧客に伝え、b) 必要なファイアウォールを維持しながら維持しやすいものを選択する必要がある場合があります。しかし、あなたがそれを助けることができるなら、あなたはそこに行きたくありません.
于 2009-05-10T15:19:30.423 に答える
1
私は最近、アプリケーションとデータベースが企業間で共有される SaaS にこの種の名前があることを知りました。
于 2009-05-10T15:38:41.673 に答える