“点赞” 数据库表设计
目前的设计是有一个字段(varchar(max))，记录所有点过的用户id，类似于：311000|3110001|3110002
这样每次用户点赞就要根据这个字段判断是否已经赞过。
感觉这样设计不是很好，请问这样的表怎么设计比较好？
谢谢。
20 个解决方案
#1
如果按照传统数据库设计的理念，微博和用户是多对多关系，应该单立出一个关系表，包含微博表和用户表的主键，另外还可以包含“点赞”这个关系特有的属性，比如状态（避免反复取消和重点造成频繁删除和插入）、时间之类的。但是，如果真的像微博那么大量的话，这种方式恐怕无法满足性能的要求。
其实，我觉得你用的方法是可以的，只不过不能每次点赞和取消都用数据库的方式来操作。应该把“赞”这个字段的数据加载到内存中，点赞和取消都在内存中完成，然后定期把内存中的数据按照你的格式写入数据库。当然，这会造成内存和数据库中的数据不一致，如果真出现宕机，可能会丢失一部分“赞”，但我觉得“赞”这个数据其实并不关键，多一点少一点不是什么致命的问题。可以根据点赞和取消的次数来设定写库的频率，以避免内存和数据库中的数据差异过大。另外，可能还需要一个类似LRU的算法管理内存中缓存的“赞”数据。
其实，我觉得你用的方法是可以的，只不过不能每次点赞和取消都用数据库的方式来操作。应该把“赞”这个字段的数据加载到内存中，点赞和取消都在内存中完成，然后定期把内存中的数据按照你的格式写入数据库。当然，这会造成内存和数据库中的数据不一致，如果真出现宕机，可能会丢失一部分“赞”，但我觉得“赞”这个数据其实并不关键，多一点少一点不是什么致命的问题。可以根据点赞和取消的次数来设定写库的频率，以避免内存和数据库中的数据差异过大。另外，可能还需要一个类似LRU的算法管理内存中缓存的“赞”数据。
#2
今天刚好碰到了新浪微博的DBA，向他请教了这个问题。把点赞用户的ID都塞到一个LOB字段中，最大的问题还是不便于检索和更新。比如，一个用户打开一条微博，会显示出他有没有点过赞，这就要扫描LOB字段的内容，而字段内容是无序的，远没有索引高效；点赞之后，如果取消或者重点，需要把整个字段读出来进行修改，这无形中读写了很多不相关的内容。当然，你可以在用户表中增加一个类似字段，包含用户点过赞的所有微博的ID，这个字段的长度会相对小得多，但对于长期使用的用户，依然存在上述问题。
我也跟他提了把数据加载到内存中操作的想法。他认为，这样的方式内存开销过大，即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存，如果业务量很大的话，会造成缓存的“赞”数据频繁换入换出，即turnover，性能根本无法保障。所以，是我有点想当然了。其实，问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。
按照他的说法，新浪采用的还是传统的关系表的方式。我也提了这样集中存储，是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading，有效地将数据分散在多个节点上。因为时间仓促，也没来得及详细问他们的数据库设计和架构方案。
我也跟他提了把数据加载到内存中操作的想法。他认为，这样的方式内存开销过大，即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存，如果业务量很大的话，会造成缓存的“赞”数据频繁换入换出，即turnover，性能根本无法保障。所以，是我有点想当然了。其实，问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。
按照他的说法，新浪采用的还是传统的关系表的方式。我也提了这样集中存储，是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading，有效地将数据分散在多个节点上。因为时间仓促，也没来得及详细问他们的数据库设计和架构方案。
#3
很感谢你的认真回答。
将数据加载到内存中的方式确实有明显的缺点。
通过你的描述，我觉得可以增加一张“点赞表”，存储的是用户id和点赞过的主题id（还是一个字段拼接存储），这样扩展性比较好（现在暂时没有考虑现实用户点赞过的主题，但以后可能有）。但就如你所说，这样对于长期使用的用户还是会出现同样的问题。如果数据量大，肯定要分表处理。
不知道有没有更好的方案？
#4
建议增加点赞表, 字段列表:
用户id,
主题id,
点赞时间,
状态. 0-已取消赞 1-有效赞
用户id,
主题id,
点赞时间,
状态. 0-已取消赞 1-有效赞
#5
就像楼上所说的这样，这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多，每一个用户赞过的每一条微博都会有一条记录，如果真的像新博微博业务量那么大的话，就要考虑做分库分表（即sharding）了。这种方案就复杂多了，我也没做过。你再根据你的业务情况考虑一下吧。
#6
嗯。这是一种方案。
#7
好的。感谢你的回答。
#8
其实这个，就是一个大量数据的效率问题。
如果你的用户数，并不多的话， 可以采用“ 记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。
建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。
如果你的用户数，并不多的话， 可以采用“ 记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。
建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。
#9
同意楼上所说，要依你的实际情况来定，别人的方法不一定适合你的
#10
你好世界
#11
学习了。 学习了。新浪微博这么做肯定有他的道理。
#12
请问hibernate怎么设计
#13
用位图怎么样
#14
其实这个，就是一个大量数据的效率问题。
如果你的用户数，并不多的话， 可以采用“记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。
建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。
其实这个不好,真的很差劲的设计.字段311000|3110001|3110002是保存在同一条记录里的,在点赞的时候需要锁着这条记录(数据库行锁),根本不可能并发很多人一起点赞.
如果你的用户数，并不多的话， 可以采用“记录所有点过的用户id，类似于：311000|3110001|3110002 ” 这个方式 ，用着很方便，但是用户量一上来，就慢的要命。
建议使用，单独的点赞表机制，每天的微博有单独的分区，点赞表也按这个分区，每次查询时，就可以知道从哪个分区表去查，速度能快不少。
其实这个不好,真的很差劲的设计.字段311000|3110001|3110002是保存在同一条记录里的,在点赞的时候需要锁着这条记录(数据库行锁),根本不可能并发很多人一起点赞.
#15
我想可能用mongodb来做会不会好点?
#16
对于表结构，我多加了一个点赞表，不知道对不对
但是对于持久化我有个疑问，就是对于每个用户对于每个文章的点赞操作，我们应该按照以下哪种方式呢？
1. 对于每个操作（点赞、取消赞），立即执行数据库操作持久化数据，这样一来会不会增加数据库负担？
2. 对于每个操作，在服务器端开辟一篇内存，先将点赞、取消赞操作更新到内存中，然后采用定时任务更新到数据库中，但是这样一来会不会造成浪费内存空间的问题？
借楼问一下各位大神应该如何权衡，实际情况下怎么应用的，刚才看到上面大神提到了第二种方法，然后在楼下的回复中说到新浪DBA提到了内存空间过大反而导致效率降低的问题，所以现在有点纠结额
但是对于持久化我有个疑问，就是对于每个用户对于每个文章的点赞操作，我们应该按照以下哪种方式呢？
1. 对于每个操作（点赞、取消赞），立即执行数据库操作持久化数据，这样一来会不会增加数据库负担？
2. 对于每个操作，在服务器端开辟一篇内存，先将点赞、取消赞操作更新到内存中，然后采用定时任务更新到数据库中，但是这样一来会不会造成浪费内存空间的问题？
借楼问一下各位大神应该如何权衡，实际情况下怎么应用的，刚才看到上面大神提到了第二种方法，然后在楼下的回复中说到新浪DBA提到了内存空间过大反而导致效率降低的问题，所以现在有点纠结额
#17
5656565
565555555699999
#18
#19
帖子的数量一般比用户数量多吧？
建立点赞表的时候，如果以帖子id为主键，后面会有一大串用户id，查起来又慢而且如楼上所说不支持并发
一般来说单个用户点赞的帖子数量不会太多吧？
以用户id为主键，记录点赞过的帖子，这种设计是不是好一些？
只有用户发生了点赞行为才会进入这个表，并且以一个用户的视角来看，
我登录进去，我点过赞的帖子渲染一下，而不是关心我在不在某一个帖子的点赞用户名单里
不知道楼上新浪微博是为什么要设计成帖子id为主键，后面跟用户id呢？
我也是菜鸟，所以想知道为什么哈！ ：）
建立点赞表的时候，如果以帖子id为主键，后面会有一大串用户id，查起来又慢而且如楼上所说不支持并发
一般来说单个用户点赞的帖子数量不会太多吧？
以用户id为主键，记录点赞过的帖子，这种设计是不是好一些？
只有用户发生了点赞行为才会进入这个表，并且以一个用户的视角来看，
我登录进去，我点过赞的帖子渲染一下，而不是关心我在不在某一个帖子的点赞用户名单里
不知道楼上新浪微博是为什么要设计成帖子id为主键，后面跟用户id呢？
我也是菜鸟，所以想知道为什么哈！ ：）
#20
#21
智能推荐
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。