“点赞” 数据库表设计

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