C*建模timeLine

Question

为了好玩，我正在构建一个tweeter克隆，以便更好地理解C*。

我所见过的所有建议的C*方案或多或少都使用了相同的建模技术。问题是，我对以这种方式建模twitter时间线的可伸缩性表示怀疑。

的问题：，如果我有一个非常流行的userA (摇滚明星)或更多，然后是10k+用户，会发生什么？每次userA发布一条推文时，我们都必须将他的每个追随者的10k+推文插入到时间表表中。

问题：这个模型真的能推广吗？有人能建议我用另一种方法来建模时间线吗？

C* Schema:

CREATE TABLE users (
 uname text, -- UserA
 followers set, -- Users who follow userA
 following set, -- UserA is following userX
 PRIMARY KEY (uname)
);
-- View of tweets created by user
CREATE TABLE userline (
 tweetid timeuuid,
 uname text,
 body text,
 PRIMARY KEY(uname, tweetid)
);
-- View of tweets created by user, and users he/she follows
CREATE TABLE timeline (
 uname text,
 tweetid timeuuid,
 posted_by text,
 body text,
 PRIMARY KEY(uname, tweetid)
);


-- Example of UserA posting a tweet:
-- BATCH START
-- Store the tweet in the tweets
INSERT INTO tweets (tweetid, uname, body) VALUES (now(), 'userA', 'Test tweet #1');

-- Store the tweet in this users userline
INSERT INTO userline (uname, tweetid, body) VALUES ('userA', now(), 'Test tweet #1');

-- Store the tweet in this users timeline
INSERT INTO timeline (uname, tweetid, posted_by, body) VALUES ('userA', now(), 'userA', 'Test tweet #1');

-- Store the tweet in the public timeline
INSERT INTO timeline (uname, tweetid, posted_by, body) VALUES ('#PUBLIC', now(), 'userA', 'Test tweet #1');

-- Insert the tweet into follower timelines
-- findUserFollowers = SELECT followers FROM users WHERE uname = 'userA';
for (String follower : findUserFollowers('userA')) {
INSERT INTO timeline (uname, tweetid, posted_by, body) VALUES (follower, now(), 'userA', 'Test tweet #1');
}
-- BATCH END

谢谢您的建议。

Answer 1

在我看来，您所描述的或类似的模式最好给出用例(参见最新的tweet，用户X订阅了+查看我的tweet)。

然而，有两个问题。

1. 我不认为Twitter使用Cassandra来存储tweet，可能与你开始考虑的原因相同。在Cassandra上运行这个提要似乎不是一个好主意，因为您不希望永远保存这些无数其他人的tweet副本，而是为每个用户保持某种滑动窗口更新(我猜，大多数用户不会从他们的feed顶部读取1000 s的tweet)。因此，我们讨论的是一个队列，在某些情况下，队列实际上是实时更新的。卡桑德拉只能在一定程度上强制支持这一模式。我不认为它是专为大规模搅动而设计的。 在生产中，可能会选择另一个对队列具有更好支持的数据库--也许类似于对列表支持的切分Redis。

1. 例如，问题并不像看上去的那么糟糕，因为您不需要在同步批处理中执行此更新。您可以将文章发布到作者的列表中，快速返回，然后使用集群中运行的异步工作人员执行所有其他更新，并使用尽最大努力的QoS推送更新。

最后，既然您已经询问了备选方案，这里有一个我可以想到的变化。从概念上讲，它可能更接近我提到的队列，但在这个框架下，它将遇到许多与大量数据频繁有关的问题。

CREATE TABLE users(
 uname text,
 mru_timeline_slot int,
 followers set,
 following set,
 PRIMARY KEY (uname)
);

// circular buffer:  keep at most X slots for every user.  
CREATE TABLE timeline_most_recent(
 uname text,
 timeline_slot int, 
 tweeted timeuuid,
 posted_by text,
 body text,
 PRIMARY KEY(uname, timeline_slot)
);