3

我正在使用 LAMP 构建一个提要（rss、twitter、其他服务等）聚合器。它与谷歌阅读器非常相似，人们可以根据需要添加任意数量的提要，然后能够一次阅读他们的提要、对其进行排序、查看单个提要或提要组。

我之前已经构建过这种类型的服务，但只是针对一小部分有限的人，其中整个组都可以访问所有聚合的提要项目。所以，这很简单。

然而，这一次，我正在构建一个人们可以订阅的服务，所以我可能（理想情况下）有成千上万的用户和 10 的数千个提要，反过来，还有数百万个提要项。

我对数据库模式（简化）的方法是这样的：

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

但是，由于用户可以订阅 100 个提要，因此我正在尝试计划出最佳和最优化的方式来查询数据库以获取他们订阅的提要（或子集）的 feed_items。

4

2 回答 2

2

我认为你在正确的轨道上。我以前做过（几次），重要的是要弄清楚哪个表需要包含哪些信息。例如，在我的 USERS 表中，我保留了用户订阅列表（或 OPML）的缓存副本。如果您要允许用户跟踪每篇文章的已读/未读状态，您可能希望将该元数据保存在单独的表中。相反，我看到您已经为用户<->提要关系设置了一个关系表。这允许您在 FEED 表中仅保留每个提要的一份副本，但查询复杂性（和性能）的权衡可能不值得。考虑您希望运行的查询。

例如，我的用户的主“主页”是一个“文件夹”列表（即 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 回答