标签服务实现漫谈

本贴最后更新于 2713 天前,其中的信息可能已经时过境迁

标签服务是一个较为通用的基础业务服务,比如博客系统对文章加标签、社交网络中为好友添加印象、收藏的歌曲贴标签方便整理等等。

其主要提供两类接口:

  • 标签实体的管理/查询:负责标签实体的 CRUD
  • 标签关联的管理/查询:将外部业务实体与标签建立/删除关联,根据外部业务实体 id 查询标签集

RDB 实现

基于关系型数据库的实现是最容易的,并且上大多数应用也是这样做的。

  1. 建立 tag 表,其中包含了 tag 的基础属性,例如 namedescription
  2. 建立 tag_rel 关联表,其中主要包含了 object_idtag_id

管理服务(创建/更新/删除)的实现非常容易;根据 object_id 查询其对应的标签集也很容易实现:

SELECT
  tag_rel.tag_id,
  tag_rel.object_id,
  tag.name
FROM
  tag_rel
LEFT JOIN tag ON tag_rel.tag_id = tag.tag_id
WHERE
  tag_rel.object_id = '2db775c1d2174a8c67fc39b86c3fc168'

问题

RDB 实现标签服务时最主要会面临的是性能问题,随着 tag_rel 数据量的不断增长,上面查询的性能会不断下降。

优化

数据库
  • 给列 tag_rel.object_id 加普通索引
  • 升级数据库服务器硬件配置
  • 使用数据库产品的特性,比如表分区/内存表

在应用层面,可以缓存查询结果,如果实时性要求不高,缓存机制是比较容易实现的,但大多数业务场景可能并不适用。

分表

前面提到的数据库产品的表分区特性(Oracle)我们也可以在应用层代码通过分表来实现。

  • 建立多张标签关联表 tag_rel_0tag_rel_1、...、tag_rel_31
  • 将查询条件 object_id 通过某种散列算法(比如 UUID 字符串的话可以通过 FNV Hash 后取模 32)得到 [0, 31] 的结果
  • SQL 落到具体的某张具体的分表上 FROM tag_rel_16

大部分应用应该通过分表就能解决性能问题,还解决不了的话可以通过这个思路进行分库、分实例。

NoSQL 实现

基于前文的背景可知,标签服务的定位是一个独立的服务,并不维护业务主体(object),所以将标签嵌套到业务主体中的设计在这里并不适合。

排除了这一条,我们还是只能用 RDB 的思想来进行设计:

  • 数据结构沿用 RDB 设计,即同样分为两个“表”:tagtag_rel
  • 将 SQL 中的 join 分成两步进行:1. 根据 object_id 查询出 tag_id 集合;2. 根据 tag_id 集合查询出 tag 集合

Redis

Redis 介绍和“为什么选用 Redis”略过。下面我们介绍一下如何使用 Redis 实现上述思路。

数据类型

我们可以使用 Redis Hash 类型来保存标签,使用 Redis Set 来保存标签关联(这也是 Redis 官方文档的示例)。

给新闻(id: 1000)添加 4 个标签(通过 id 关联):

> sadd news:1000:tags 1 2 5 77
(integer) 4

添加反向关联:

> sadd tag:1:news 1000
(integer) 1
> sadd tag:2:news 1000
(integer) 1
> sadd tag:5:news 1000
(integer) 1
> sadd tag:77:news 1000
(integer) 1

查询该新闻的标签 id 集合:

> smembers news:1000:tags
1. 5
2. 1
3. 77
4. 2

然后根据返回的标签 id 集合查询标签。虽然分了两步进行查询,但 Redis 的高性能将为我们带来很低的耗时。

结论

  • 数据库分表能够解决标签服务的性能问题
    • 实现简单,在现有实现的基础上改造很小
    • 依然是基于关系型数据库,不用调整技术架构,开发模式、运维等保持不变
  • 使用 Redis 同样可以实现标签服务
    • 使用 Hash 保存标签、Set 保存关联关系
    • 分两步进行查询,Redis 自身的实现解决性能问题
打赏 25 积分后可见
25 积分 • 7 打赏
  • Redis

    Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。从 2010 年 3 月 15 日起,Redis 的开发工作由 VMware 主持。从 2013 年 5 月开始,Redis 的开发由 Pivotal 赞助。

    286 引用 • 248 回帖 • 74 关注
  • 标签
    19 引用 • 127 回帖
  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    338 引用 • 705 回帖 • 1 关注
  • 分表
    3 引用 • 13 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • Comdex

    很好

  • 其他回帖
  • someone1764

    所以最好还是记录到 redis

  • zonghua

    我更关心的是关注与被关注功能的实现。
    都不敢在用户列表中显示,因为查询太多了。
    只有在用户主页显示关系,因为只要查两个关系。

  • 通常标签不单单需要从 object 查出标签

    还需要从标签查出 object

    如果两种查询都很需要大量查询的时候,第一种优化就歇菜来。

  • 查看全部回帖