0

私の Web サイトには、クライアントごとに非常に細かい権限システムがあり、サイズがかなり大きくなっています。

データベース クエリを制限するために、ユーザー セッションの開始時に mysql データベースからビットマスクをロードし、それをセッション データとして保存したので、次のようになりました。これにより、巨大なセッション ファイルを作成することなく、ユーザー セッションごとに 1 つの (複雑な JOIN クエリではありますが) クエリを作成することができました。

"permissions" => array(
    "type 1" => 'bitfield'
    "type 2" => 'bitfield'
     "type 3" => array(
         entity id = 'bitfield'
         entity id = 'bitfield')
     "type 4" => array(
         entity id = 'bitfield'
         entity id = 'bitfield')
)

パーミッションは完全にグループ ベースであるため、特定のグループ内のすべての人は、これをセッション データにレプリケートします。

ただし、ビットマスクを使用するのが面倒になり始めており、ACL の使用に移行しようとしています。そもそも ACL を使用しなかった理由は、データベースの使用を最小限に抑えるためでした..

だから..今、私はビットマスクなしで完全にデータベース/キャッシュ駆動型のACLを持つつもりです. ただし、ユーザー セッション データにアクセス許可の膨大な配列を格納することは、理想的ではないようです。（同意しますか？）

進むべき道は、フラット ファイル キャッシュを使用してグループのアクセス許可を保存することだと思います。これを行う最も簡単な方法は、グループごとのファイルでしょうか? これは、それぞれ 4 つの権限タイプを持つ 4,000 以上のグループがある場合に変わりますか (2 つの権限タイプは、組み合わせて 40 程度の権限を持つグローバルであり、2 つのタイプは、エンティティごとに組み合わせた 40 程度の権限を持つローカル権限です (各タイプには、おそらく 3 つか 4 つの多くの権限があります)。 20 パーミッション!).編集: 明確にするために、これはグループごとに 160 - 200 パーミッション エントリを意味します

これは、かなり巨大なキャッシュになるようです。ページの読み込みごとに大量のデータベースを使用するのが最善でしょうか? この種のデータサイズにより、ビットマスクははるかに簡単になりましたが、もはや十分な柔軟性がありません.

これは、ファイルが 2 つの異なるサーバーによって提供されるという事実によって難しくなります (セッションは固定されているため、ビットフィールドをセッション データに保存することは問題ではありませんでした)。サーバー間でキャッシュを同期する必要があります。データベースは、おそらく1ギグ接続のプライベートネットワークで接続された別のサーバー上にあります。

解決策を提案できますか? この大量のデータを含む memcached などのクイック アクセス キャッシュは、メモリ使用量を水から吹き飛ばすだけだと思いますか? 多くのデータベース クエリを使用するだけの誘惑に駆られますが、db サーバーに負担がかかりすぎる可能性があると思います。

かなり大きな質問ですが、明確になることを願っています。説明が必要な場合はお知らせください。どんな解決策も大歓迎です！

クリス

4

1 に答える 1

0

セッションに保存された最大 40 エントリのデータ構造が特に巨大であるとは思いません。したがって、実際のところ、これが設計的に考えられるのは、この情報を最高のパフォーマンスでアプリケーションに取り込む方法です。

パフォーマンスの問題に直面し始めていて、インフラストラクチャの予算が許す場合は、このソリューションを、任意の数のサーバー間で共有できるサービス指向アーキテクチャに移行することを検討するかもしれません. 私は個人的に、この種のアーキテクチャを大いに信じています。規模の問題に対処するのに本当に役立つからです。

このアプリケーション (または、将来開発する必要がある他のアプリケーション) で使用できるサービスとして「アクセス許可」を公開できます。次のようになります。

  • アプリケーションがグループに基づいてアクセス許可情報を探すために最初の呼び出しを行う場所であるインメモリ キャッシュ レイヤー (memcached など)。ここにデータが存在しない場合、次のレイヤーがリクエストを処理します
  • RESTful API。最初にキャッシュ ミスが発生した後、グループのアクセス許可に対して単純な GET 要求を行います。これは、情報を取得するためにデータベース層を呼び出す必要があります。また、クライアントが新しいアクセス許可データを POST したり、既存のアクセス許可のセットを更新したりする場合に、キャッシュ ミスでキャッシュにデータを入力したり、キャッシュを無効にして再入力したりすることもできます。
    • RESTful サービスのみがアクセスする DB 層。より複雑な非リレーショナル データ構造がある場合、おそらく MySQL はおそらく NoSQL テクノロジです。

サービスの場合、おそらく非常に小さなデータベース サーバーを使用できます (キャッシュにデータが入力されると、データベース自体が頻繁にクエリされないため)。ストレージのニーズを満たすのに十分なメモリを備えたメモリ キャッシング サーバー (または、冗長性が必要な場合はサーバーの小さなクラスター)、および REST API を処理するための比較的小さなサーバー (キャッシュが開発されると、これも頻繁にはアクセスされません。良いことは、比較的安価に使用できるいくつかの memcached または同様のサービスがあることです (Amazon Elasticache など) 実際には、インメモリ キャッシュがアプリケーション サーバーからのトラフィックの矢面に立たされるため、スケーリングする必要はありません。トラフィックが増加するにつれて、DB サーバーの REST サーバーをまったくアップします。

これがあなたの思考プロセスに少し役立つことを願っています.

于 2012-08-30T22:25:46.857 に答える