HBase 设计实践

前言

对于数据库来说，使用场景是很重要的。什么样的场景适合什么样的数据库，这些只能通过实践才能加深理解。同时也能更加深入的了解对应的数据库的原理。接下来讨论一下在关注列表这个特定的场景下，后端数据库的选型与设计。

访问模式

在选型之前，先确定数据的访问模式。对于关注列表来说，主要的访问模式如下：

• 读
  • 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。下面我们看下这张表能否满足上面的访问模式。

1. 获取用户 A 关注了哪些人

   这个是完全可以的，只需要找到 A 对应的那一行，返回 followed_list 的内容就可以了。由于 user_id 是主键，这个查询也会很快。

2. 有哪些人关注了 A

   要获取到这个信息，我们需要遍历整张表，在所有用户中查看哪些用户的关注列表里有 A，将这些用户返回。遍历整张表的这种操作基本上都是不可接受的。

3. A 是否关注了 B

   获取到 A 的关注列表，然后遍历 A 的关注列表里是否有 B，当 A 的关注列表很长时，这个操作可能会比较耗时。

4. A 关注 B

   这个写操作是在 A 没有关注 B 这个前提下进行的，A 只需要在对应的关注列表里把 B 添加进去就可以了。

5. A 取消关注 B

   把 A 对应的关注列表里把 B 删除。

可以看到，2 对应的访问模式基本是没法满足的，而 3,4,5 这三种访问模式在关注列表特别大的情况下，是会比较耗时的。2 对应的解决办法就两种，一种是用两张表，一张表存储关注列表，一张表存储被关注列表。但没法解决在关注列表或者被关注列表很大的情况下的耗时问题。