3

LAMP を使用してフィード (RSS、Twitter、その他のサービスなど) アグリゲーターを構築しています。フィードを好きなだけ追加して、フィードを読んだり、並べ替えたり、個々のフィードやフィードのグループを一度に表示したりできるという点で、Google リーダーと非常によく似ています。

私は以前にこのタイプのサービスを構築したことがありますが、グループ全体が集約されたすべてのフィード項目にアクセスできる少数の限られたグループを対象としていました。だから、それはかなり簡単でした。

しかし今回は、人々がサブスクライブできるサービスを構築しているので、潜在的に (理想的には) 数千のユーザーと数万のフィード、そして数百万のフィード アイテムを持つことができます。

データベーススキーマ（簡略化）に対する私のアプローチは次のとおりです。

users (id, name, ...)
feeds (id, name, url, ...)
feed_items (id, title, timestamp, feed_id, ... )
user_feeds (id, user_id, feed_id, ...)

ただし、ユーザーは何百ものフィードをサブスクライブできるため、サブスクライブしたフィード (またはそのサブセット) の feed_items をデータベースに照会するための最適かつ最適化された方法を計画しようとしています。

4

2 に答える 2

2

あなたは正しい軌道に乗っていると思います。私はこれを以前に (数回) 行ったことがありますが、重要なことは、どのテーブルにどの情報を含める必要があるかを把握することです。たとえば、私の USERS テーブルでは、ユーザーのサブスクリプション リスト (または OPML) のキャッシュ コピーを保持しています。ユーザーが各記事の既読/未読ステータスを追跡できるようにする場合は、そのメタデータを別のテーブルに保持することをお勧めします。逆に、ユーザー <-> フィードの関係のためだけにリレーショナル テーブルを設定したようです。これにより、FEED テーブルに各フィードのコピーを 1 つだけ保持することができますが、クエリの複雑さ (およびパフォーマンス) のトレードオフは価値がない場合があります。実行するクエリを検討してください。

たとえば、私のユーザーのメインの「ホームページ」は、フィードが分離された「フォルダー」(つまり、Google リーダー ラベル) のリストであり、各フォルダーには、そのフォルダー内の未読記事の数がラベル付けされています (重複記事はカウントされません)。 . 優れたインデックスを使用しても、リレーショナル アプローチを使用したクエリには耐えられません (そして時間がかかります)。ただし、非正規化すると (つまり、FEEDS テーブルに各フィードの複数のコピーが含まれる場合があり、スキーマに user_id (および私の場合はフォルダー名) が含まれる)、テーブルは大きくなりますが、そのクエリは簡単で瞬時に実行されます。

また、私の POSTS テーブル (または FEED_ITEMS -- なんでも) で、元の記事の説明/コンテンツ:エンコードを DESCRIPTION_ORIGINAL 列に格納し、「クリーン」バージョンを DESCRIPTION 列に配置します。クリーン バージョンでは、HTML がサニタイズされ、広告が削除され、既知のエンコーディングの問題が修正されています。

于 2011-12-28T04:24:00.547 に答える
0

ここではキャッシュが非常に役立ちます。ユーザーがフィードを編集するときに、フィード クエリを実行し、結果を memcache に保存できます。

その後、 を実行できますがWHERE (feed_items.feed_id IN ( ... ))、これらのクエリの結果もキャッシュすることをお勧めします。

于 2011-12-22T21:57:16.447 に答える