2

シナリオは次のとおりです。

さまざまなクライアントをホストする Symfony2 アプリを構築したいと考えています。1 つの環境 (事実上の "prod" 環境としましょう) を持つ代わりに、各クライアントは独自の環境を取得します。

では、クライアント "foo" と "bar" があるとします。その場合、3 つの環境が必要になります。1 つは「foo」用、もう 1 つは「bar」用、そしてもう 1 つは開発用 (「dev」と呼びましょう) です。私はこの例を示しているだけですが、数十から数百のクライアントを持つことができるとしましょう。

これのポイントは、クライアントのデータを分離したいということです。私たちのアプリはすべてのクライアント (同じバンドルなど) で同じように動作しますが、それぞれに独自のデータがあり、他のクライアントからアクセスできないようにする必要があります (これにより、データのセキュリティが確保され、簡単になります)。各クライアントのデータをバックアップ、復元、インポート、およびエクスポートします)。この種の機能 (環境ごとに 1 つのクライアント) を許可する方法は既にありますが、データベース データの保存に関しては、問題が発生すると考えられます。

ドキュメンテーションで読んだことから、Symfony2 環境では (他の変更が行われない限り) さまざまな構成ファイルをロードできるだけであると想定しています。したがって、これらの構成ファイルで、それらがすべて同じデータベース構成を指している場合、環境がデータベースを「共有」することも想定しています。多かれ少なかれ、環境「foo」で誰かが入力したものは、環境「bar」でも同じようにアクセスできます。これは望ましくありません。

すぐに使用できるこの環境の概念を使用すると、次の 3 つの選択肢があります。

  1. 各クライアントに独自のデータベース サーバーを提供します。これにより、最大のパフォーマンスが得られ、データが分離されます。この情報を構成ファイルに取り込むのも簡単です。ただし、高価であり、維持するのは困難です。
  2. 1 つのデータベース サーバーを使用しますが、それぞれに独自のスキーマを与えます。これはデータを分離し、最もコスト効率に優れていますが、最終的にはパフォーマンスの問題が発生し (スキーマ数がかなり大きくなるため)、維持するのは難しいでしょう (テーブルを更新する必要がある場合など)。構造)。
  3. すべての情報を 1 つのデータベースと 1 つのスキーマに入れますが、何らかのアプリケーション ロジックを使用してそれらを区別します。これはもっともらしいことですが (これは私たちが現在レガシー アプリで行っていることです。すべてをクライアント PKID に結び付けています)、使用したい ORM を使用してこれがどれほど簡単になるかはわかりません...

個人的には、3 番目のオプション (1 つのデータベース、1 つのスキーマ、およびアプリケーション ロジックによるフィルタリング) と、1 番目と 2 番目のオプションのハイブリッド (各クライアントに独自のスキーマを与え、新しいサーバーをプロビジョニングし、パフォーマンスを向上させるために人々を移動させる) の間でちょっと悩んでいます。問題が表示されます)。1 と 2 のハイブリッドが最も簡単だと思います。構成オプションを変更するだけでよいためです (環境をサーバーとスキーマに向ける)。しかし、オプション 3 がパフォーマンス的には最高だと思います。可能であれば、セットアップが難しくなる可能性があります。

したがって、私が知りたいのは、3 番目のオプション (アプリケーション ロジックを使用してデータを分離する) を介してこれを達成する方法があるかどうかです。私は本当に「簡単な」解決策を探しています。「簡単」とは、Symfony2 または Doctrine に既に組み込まれているツールと機能を使用することを意味します。たとえば、doctrine の構成設定や、データの一部の環境を何らかの方法で記録してリンクする Doctrine 拡張機能を作成するようなものです。

または、誰か他の提案があれば、私もそれらを聞くことに興味があります.

データベースには MySQL を使用する予定です。このアプリは、Apache と PHP がインストールされた Linux VM 上で実行されます。Symfony2 の最新リリースも使用します。

4

2 に答える 2

1

最初に、symfony の環境はクライアント間ではなく、dev/test/staging/prod 間で異なるということを述べたいと思います。環境の使用方法が問題を引き起こすユースケースを頭の中で知りませんが、フレームワークに対して作業することは通常悪い考えです。

もちろん、あなたのプロジェクトについてすべてを知っているわけではありませんが、プロジェクトにアクセスするさまざまな「ユーザー」(クライアントと呼びます)の非常に一般的なユースケースがあり、さまざまな「設定」を持ちながらさまざまなデータを表示する必要があるようです。 (これを構成と呼びます)。

しかし、これがアプリケーションの構造化を決定した方法である場合は、それを使用してみましょう。解決策のポイント 1 と 2 は、symfony でも同じです。symfony は、dbms が別のサーバー上にあるかどうか、またはサーバー上で 100 個のデータベースが実行されているかどうかを気にしません。ホストと正しい資格情報だけが必要です。したがって、1 台のデータベース サーバーから始めて、パフォーマンスが低下した場合は、2 台目を追加できます。

ただし、このソリューションは、更新に直面したときにもちろん重要です。アプリケーションをデプロイし、100 個のデータベースを更新する必要があります。1 つのクライアントのみに展開することはできないため、データベースの移行が完了するまでアプリケーション全体を停止するか、下位互換性を備えたアプリケーションを開発します。これは機能するかもしれませんが、スキーマ レイアウトに関する不適切な決定に対する 3 番目の回避策が必要になると、見苦しくなります。

3 番目の解決策は、古典的なアプローチです。セキュリティ リスクに応じて、アプリケーションとドクトリンの間に別のレイヤーを追加して、特定のクライアントのデータのみにアクセスできるようにクエリを変更します。

私はオプション3に行きます。パフォーマンスの問題があると思われる場合は、特に MySQL (または任意の RDBMS) ではそれほど簡単ではない傾向があるため、スケーリング手法について検討することをお勧めします。

于 2012-11-07T22:48:10.110 に答える
0

私たちのリソース(私たちはそれを買う余裕がなく、MySQLを使いたいと思っています)のため、これは私たちにとって実際にはオプションではありませんが、非常に興味深いと思い、データベースで問題を解決するので言及したいと思いますレベル。

Oracle Database(私が信じるEnterprise Edition)には、「仮想プライベートデータベース」と呼ばれる機能があり、必要なことを正確に実行します。基本的に、データベースに接続しているユーザーに基づいて、SQLエンジン内のテーブル、行、または列にアクセスポリシーを追加できます。このように、データはすべて同じテーブルに存在できますが、SQLエンジンを使用して、ユーザーが表示できないデータの行/列へのアクセスを自動的に非表示にし、防止することができます。

これは素晴らしい機能のように思えますが、ライセンス要件やその他のコストにより、私たち(そしておそらく多くの人々)がこれを使用できなくなります...

仮想プライベートデータベース

Oracle VirtualPrivateDatabaseを使用したデータアクセスの制御

于 2012-11-08T21:34:33.453 に答える