“点赞” 数据库表设计

[skyandcode]

需求类似于微博，可以为主题点赞，但不能重复点赞。
目前的设计是有一个字段(varchar(max))，记录所有点过的用户id，类似于：311000|3110001|3110002
这样每次用户点赞就要根据这个字段判断是否已经赞过。
感觉这样设计不是很好，请问这样的表怎么设计比较好？
谢谢。

[oraclecaicai]

今天刚好碰到了新浪微博的DBA，向他请教了这个问题。把点赞用户的ID都塞到一个LOB字段中，最大的问题还是不便于检索和更新。比如，一个用户打开一条微博，会显示出他有没有点过赞，这就要扫描LOB字段的内容，而字段内容是无序的，远没有索引高效；点赞之后，如果取消或者重点，需要把整个字段读出来进行修改，这无形中读写了很多不相关的内容。当然，你可以在用户表中增加一个类似字段，包含用户点过赞的所有微博的ID，这个字段的长度会相对小得多，但对于长期使用的用户，依然存在上述问题。 我也跟他提了把数据加载到内存中操作的想法。他认为，这样的方式内存开销过大，即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存，如果业务量很大的话，会造成缓存的“赞”数据频繁换入换出，即turnover，性能根本无法保障。所以，是我有点想当然了。其实，问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。 按照他的说法，新浪采用的还是传统的关系表的方式。我也提了这样集中存储，是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading，有效地将数据分散在多个节点上。因为时间仓促，也没来得及详细问他们的数据库设计和架构方案。

[skyandcode]

引用 4 楼 ap0405140 的回复:

建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞

嗯。这是一种方案。

[weixin_50595510]

@weixin_50595510 fsdf

[weixin_50595510]

@weixin_50595510 sdff

[weixin_50595510]

@skyandcode sdff

[skyandcode]

引用 5 楼 oraclecaicai 的回复:

[quote=引用 4 楼 ap0405140 的回复:] 建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞

就像楼上所说的这样，这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多，每一个用户赞过的每一条微博都会有一条记录，如果真的像新博微博业务量那么大的话，就要考虑做分库分表（即sharding）了。这种方案就复杂多了，我也没做过。你再根据你的业务情况考虑一下吧。[/quote] 好的。感谢你的回答。

[oraclecaicai]

引用 4 楼 ap0405140 的回复:

建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞

就像楼上所说的这样，这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多，每一个用户赞过的每一条微博都会有一条记录，如果真的像新博微博业务量那么大的话，就要考虑做分库分表（即sharding）了。这种方案就复杂多了，我也没做过。你再根据你的业务情况考虑一下吧。

[skyandcode]

引用 2 楼 oraclecaicai 的回复:

今天刚好碰到了新浪微博的DBA，向他请教了这个问题。把点赞用户的ID都塞到一个LOB字段中，最大的问题还是不便于检索和更新。比如，一个用户打开一条微博，会显示出他有没有点过赞，这就要扫描LOB字段的内容，而字段内容是无序的，远没有索引高效；点赞之后，如果取消或者重点，需要把整个字段读出来进行修改，这无形中读写了很多不相关的内容。当然，你可以在用户表中增加一个类似字段，包含用户点过赞的所有微博的ID，这个字段的长度会相对小得多，但对于长期使用的用户，依然存在上述问题。 我也跟他提了把数据加载到内存中操作的想法。他认为，这样的方式内存开销过大，即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存，如果业务量很大的话，会造成缓存的“赞”数据频繁换入换出，即turnover，性能根本无法保障。所以，是我有点想当然了。其实，问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。 按照他的说法，新浪采用的还是传统的关系表的方式。我也提了这样集中存储，是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading，有效地将数据分散在多个节点上。因为时间仓促，也没来得及详细问他们的数据库设计和架构方案。

很感谢你的认真回答。 将数据加载到内存中的方式确实有明显的缺点。 通过你的描述，我觉得可以增加一张“点赞表”，存储的是用户id和点赞过的主题id（还是一个字段拼接存储），这样扩展性比较好（现在暂时没有考虑现实用户点赞过的主题，但以后可能有）。但就如你所说，这样对于长期使用的用户还是会出现同样的问题。如果数据量大，肯定要分表处理。 不知道有没有更好的方案？

[唐诗三百首]

建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞

[云中客]

同意楼上所说，要依你的实际情况来定，别人的方法不一定适合你的

[卖水果的net]

其实这个，就是一个大量数据的效率问题。 如果你的用户数，并不多的话， 可以采用“记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。 建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。

[凌小星]

你好世界

[harryliuy]

学习了。 学习了。新浪微博这么做肯定有他的道理。

[jinxZz0]

请问hibernate怎么设计

[letianjvshi]

用位图怎么样

[石头wang]

其实这个，就是一个大量数据的效率问题。 如果你的用户数，并不多的话， 可以采用“记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。 建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。 其实这个不好,真的很差劲的设计.字段311000|3110001|3110002是保存在同一条记录里的,在点赞的时候需要锁着这条记录(数据库行锁),根本不可能并发很多人一起点赞.

[石头wang]

我想可能用mongodb来做会不会好点?

[MJClown]

对于表结构，我多加了一个点赞表，不知道对不对 但是对于持久化我有个疑问，就是对于每个用户对于每个文章的点赞操作，我们应该按照以下哪种方式呢？ 1. 对于每个操作（点赞、取消赞），立即执行数据库操作持久化数据，这样一来会不会增加数据库负担？ 2. 对于每个操作，在服务器端开辟一篇内存，先将点赞、取消赞操作更新到内存中，然后采用定时任务更新到数据库中，但是这样一来会不会造成浪费内存空间的问题？ 借楼问一下各位大神应该如何权衡，实际情况下怎么应用的，刚才看到上面大神提到了第二种方法，然后在楼下的回复中说到新浪DBA提到了内存空间过大反而导致效率降低的问题，所以现在有点纠结额

[qq_25146679]

5656565565555555699999

[zxyabsent]

帖子的数量一般比用户数量多吧？ 建立点赞表的时候，如果以帖子id为主键，后面会有一大串用户id，查起来又慢而且如楼上所说不支持并发 一般来说单个用户点赞的帖子数量不会太多吧？ 以用户id为主键，记录点赞过的帖子，这种设计是不是好一些？ 只有用户发生了点赞行为才会进入这个表，并且以一个用户的视角来看， 我登录进去，我点过赞的帖子渲染一下，而不是关心我在不在某一个帖子的点赞用户名单里 不知道楼上新浪微博是为什么要设计成帖子id为主键，后面跟用户id呢？ 我也是菜鸟，所以想知道为什么哈！ ：）

[guojh1111]

[天问]

引用 19 楼 zxyabsent 的回复:

帖子的数量一般比用户数量多吧？
建立点赞表的时候，如果以帖子id为主键，后面会有一大串用户id，查起来又慢而且如楼上所说不支持并发
一般来说单个用户点赞的帖子数量不会太多吧？
以用户id为主键，记录点赞过的帖子，这种设计是不是好一些？
只有用户发生了点赞行为才会进入这个表，并且以一个用户的视角来看，
我登录进去，我点过赞的帖子渲染一下，而不是关心我在不在某一个帖子的点赞用户名单里
不知道楼上新浪微博是为什么要设计成帖子id为主键，后面跟用户id呢？
我也是菜鸟，所以想知道为什么哈！ ：）

这样是不好统计一个帖子有多少赞的吧。或许在帖子中增加一个点赞计数，这样点赞需要更新两个地方，一个用户的，一个帖子的。

[罔殆]

楼主要看看数据量来定，如果数据量不是很大的话，楼主的设计时没有问题的。考虑到客户的频繁点赞与取消，从系统性能的角度来考虑，可以考虑使用redis。