cassandra 的架构设计
我正在开发一个论坛项目，该项目允许用户从他的网络中关注有关某些主题的问题。
用户的新闻源墙仅包含由其联系人发布并标记为以下主题的问题。我很困惑哪种数据库的数据模型最适合这样的应用程序。 到目前为止，我一直在研究 Cassandra 和 MySQL 解决方案。
在研究 Cassandra 之后，我意识到显示来自网络的所有帖子的简单新闻源设计可以很容易地使用 Cassandra 进行设计，方法是向用户的所有关注者执行有关用户帖子的快速写入。 但对于我的应用程序来说，有一个额外的“关注主题”过滤器，我无法说服自己在 Cassandra 中进行良好的架构设计。我希望如果我因为对 cassandra 的了解不够而错过了一些东西，也许您能帮我提供有关如何在 Cassandra 中实现此新闻源的建议吗？
I am working on a project of forum that allows a user to follow questions on certain topics from his network.
A user's news-feed wall comprises of only those questions that have been posted by his connections and tagged on the followed topics. I am confused what database's datamodel would be most fitting for such an application.
I have been looking at Cassandra and MySQL solutions as of now.
After my study of Cassandra I realized that Simple news-feed design that shows all the posts from network would be easy to design using Cassandra by executing fast writes to all followers of a user about the post from user.
But for my kind of application where there is an additional filter of 'followed topics', I could not convince myself with a good schema design in Cassandra. I hope if I missed something because of my short understanding of cassandra, perhaps, can you please help me out with your suggestions of how this news-feed could be implemented in Cassandra ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您已经研究过 Twissandra 示例应用程序。与你所描述的非常接近。以下是一些有用的链接：
与您的应用程序的主要区别在于主题的介绍。您存储数据的方式完全取决于您希望如何查询数据。例如，您可能愿意在同一时间线中呈现所有主题，或者您可能希望能够仅查看特定主题的时间线（例如 SO 标签）。
如果您不需要单独的时间线，我建议使用 Twissandra 数据模型作为基础：
为每个主题的每个用户维护一行关注者，而不是普通的 FOLLOWERS 列族。显然，这会在创建/更改/删除用户时带来一些额外的工作，但它可以在创建新帖子时节省您的工作量，这是您需要处理的大部分操作。
当用户 Joe 就主题 A、B 和 C 发表帖子时，您将能够通过如下查询获得所有感兴趣的用户：
where 'Joe::A', 'Joe::B', and 'Joe::C' 是行键。对于您返回的每个关注者，您只需将帖子的 UUID 作为列名称添加到每个关注者的时间线中（并且您不必担心时间线中的重复项，因为您对列使用相同的 UUID姓名）。
如果您希望能够支持每个用户的每个主题时间线，我建议您为用户感兴趣的每个主题使用一行，为所有主题时间线使用一行。由于您已经按主题获取关注者，因此很容易知道关注者对帖子的哪些主题感兴趣，只需将帖子附加到正确的每个主题时间线即可。
I'm assuming you've already studied the Twissandra example application. It's very close to what you're describing. Here are a couple of useful links:
The primary difference with your application is the introduction of topics. How you store the data depends on exactly how you want to be able to query it. For example, you might be fine with all topics being presented in the same timeline, or you might want to be able to see a timeline only for a specific topic (like SO tags, for example).
If you don't need separate timelines, I recommend the following, using the Twissandra data model as the base:
Instead of the normal FOLLOWERS column family, maintain one row of followers for every user for each topic. Obviously, this causes a little extra work when creating/altering/dropping users, but it saves you work when new posts are created, which is the bulk of the operations you need to handle.
When a post is made by user Joe on topics A, B, and C, you'll be able to get all of the interested users with a query like:
where 'Joe::A', 'Joe::B', and 'Joe::C' are row keys. For each of the followers that you get back, you can simply add the post's UUID as a column name to each follower's timeline (and you won't have to worry about duplicates in the timeline since you're using the same UUID for the column name).
If you want to be able to support per-topic timelines for each user, I suggest you use one row for each topic that a user is interested in and one row for the all-topics timeline. Since you are already fetching followers by topic, it's easy to know which topic(s) the post has that the followers are interested in, it's to append the post to the correct per-topic timelines.