前言
对于数据库来说,使用场景是很重要的。什么样的场景适合什么样的数据库,这些只能通过实践才能加深理解。同时也能更加深入的了解对应的数据库的原理。接下来讨论一下在关注列表这个特定的场景下,后端数据库的选型与设计。
访问模式
在选型之前,先确定数据的访问模式。对于关注列表来说,主要的访问模式如下:
- 读
- A 都关注了哪些人
- 有哪些人关注了 A
- A 是否关注了 B
- 写
- A 关注 B
- A 取消关注 B
选型
传统关系型数据库
使用传统的关系型数据库,比如 mysql,可不可以呢?肯定是可以的。创建如下的 schema:
CREATE TABLE followed '
user_id varchar(255) PRI NOT NULL,
followed_list text,
'
在 followed 这张表里定义了两列,一列是 user_id,一列是 followed_list,followed_list 表示该 user_id 的关注列表。关注列表是用特殊分隔符分开的 user_id 字符串,这个列表可能会很长,所以数据类型被定义成了 text。下面我们看下这张表能否满足上面的访问模式。
-
获取用户 A 关注了哪些人
这个是完全可以的,只需要找到 A 对应的那一行,返回 followed_list 的内容就可以了。由于 user_id 是主键,这个查询也会很快。
-
有哪些人关注了 A
要获取到这个信息,我们需要遍历整张表,在所有用户中查看哪些用户的关注列表里有 A,将这些用户返回。遍历整张表的这种操作基本上都是不可接受的。
-
A 是否关注了 B
获取到 A 的关注列表,然后遍历 A 的关注列表里是否有 B,当 A 的关注列表很长时,这个操作可能会比较耗时。
-
A 关注 B
这个写操作是在 A 没有关注 B 这个前提下进行的,A 只需要在对应的关注列表里把 B 添加进去就可以了。
-
A 取消关注 B
把 A 对应的关注列表里把 B 删除。
可以看到,2 对应的访问模式基本是没法满足的,而 3,4,5 这三种访问模式在关注列表特别大的情况下,是会比较耗时的。2 对应的解决办法就两种,一种是用两张表,一张表存储关注列表,一张表存储被关注列表。但没法解决在关注列表或者被关注列表很大的情况下的耗时问题。