Question

我正在开发一个具有相同关注系统的社交Android应用程序，例如 soundcloud 。

我知道它可以在 MySQL 中轻松实现，这是一个跟随关注者和跟随者的关注表

follower_id   following_id
1             2
4             1
6             2
9             6
.             .
.             .
.             .

并使用两个ID作为主键。

但问题是我们期待网络能够增长到数百万用户。

想象一下，只有100万用户，平均每个人都会有500名粉丝和500名粉丝。

这将产生一张约 1,000 * 1,000,000 = 1,000,000,000条记录的表格，并且会继续增长！

MySQL 能否在这种情况下表现良好？

我可以使用 MongoDB 并像这样存储它

user_id     followers                                   following
1           [embedded documents holding followers]       [embedded documents holding following]
2           [embedded documents holding followers]       [embedded documents holding following]
3           [embedded documents holding followers]       [embedded documents holding following]
...

这里的问题不是性能 - 正如我想的那样 - 但 mongo不支持交易 因为以下每一个动作我都应该将它存储在2个文件中！

那么，您认为最好的方法是什么？如果表增长到数十亿行，MySQL能否表现良好？!!还有其他有效的设计吗？！

Answer 1

CREATE TABLE Follow (
    er_id INT UNSIGNED NOT NULL  COMMENT 'follower',
    ee_id INT UNSIGNED NOT NULL  COMMENT 'followee',
    PRIMARY KEY(er_id, ee_id),
    INDEX(ee_id, er_id)
) ENGINE=InnoDB;

这样，你可以从er到ee 和反之亦然。

使用MySQL表结构和十亿行以及500个关注者，SELECT er_id FROM tbl WHERE ee_id = 1234;（反之亦然）通常只需10-20毫秒，即使在旋转驱动器上也是如此。

（follower_id和followee_id的相同性使我缩短了列名。）

数据库设计 - 遵循数十亿条记录的系统

1 个答案: