关于论坛数据库的设计
文章分类:数据库
一个简单的论坛系统
1:包含下列信息:
2:每天论坛访问量300万左右,更新帖子10万左右。
请给出数据库表结构设计,并结合范式简要说明设计思路。
一. 发帖主题和回复信息存放在一张表,并在这个表中增加user_name字段
对数据库的操作而言,检索数据的性能基本不会对数据造成很大的影响(精确查找的情况下),而对表与表之间的连接却会产生巨大的影响, 特别在有巨量数据的表之间;因此对问题的定位基本可以确定:在显示和检索数据时,尽量减少数据库的连接以及表与表之间的连接;
引用
1: user:用户基本信息表
字段有:user_id,user_name,email,homepage,tel,add...
2: forum_item:主题和回复混合表
字段有:id,parent_id,user_id,user_name,title,content,....
parent_id=0或者null表示是主题,否则=n表示是id=n那条帖子的回复
UserName字段是冗余的,因此在用户修改UserName的时候就会产生同步数据的问题,这个需要程序来进行弥补
二. 主题表和主题回复分开保存
引用
1: user:用户基本信息表
字段有:user_id,user_name,email,homepage,tel,add...
2: forum_topic:主题表
字段有:id,user_id,title,content,....
3: forum_topic_back:主题回复表
字段有:id,topic_id,user_id,title,content,....
三. 主题表的内容单独设计成一个表
引用
1: user:用户基本信息表
字段有:user_id,user_name,email,homepage,tel,add...
2: forum_topic:主题表
字段有:id,user_id,title,....
3: forum_topic_content:主题内容表
字段有:id,topic_id,content
4: forum_topic_back:主题回复表
字段有:id,topic_id,user_id,title,content,....
四.用户信息分2个表保存,并对相关表进行分表处理
引用
1: 简单用户表 tb_user:
id , username
2: 用户详细信息表 tb_userinfo
id,userid , email , homepage , phone , address ...
3: 论坛主题表 tb_bbs
id , userid , title , ip , repleycount , replyuserid , createtime , lastreplytime
4: 论坛内容标 tb_bbs_content (此表可按照bbsid进行分表存储)
id,bbsid , content;
5: 论坛回复表 tb_bbs_reply (此表可按照bbsid进行分表存储)
id , bbsid , userid , content , replytime , ip
五.增加一个主题缓存表,取每个区的前面100条记录
引用
1: 简单用户表 tb_user:
字段有:id , username
2: 用户详细信息表 tb_userinfo
字段有:id,userid , email , homepage , phone , address ...
3: 论坛主题表 tb_bbs
字段有:id , userid , title , ip , repleycount , replyuserid , createtime , lastreplytime
4: 论坛内容标 tb_bbs_content (此表可按照bbsid进行分表存储)
字段有:id,bbsid , content;
5: 论坛回复表 tb_bbs_reply (此表可按照bbsid进行分表存储)
字段有:id , bbsid , userid , content , replytime , ip
6: 主题缓存表 tb_bbs_cache
字段有:id , userid , title , ip , repleycount , replyuserid , createtime , lastreplytime
------------------------------------------------------------------------------
下面是针对上面的方案展开的讨论:
1:方案一表面上看起来好像少查了一张表,但由于冗余,因为帖子数量极大,会占用大量的空间。这种数据量大,但是对实时和数据绝对安全性要求较低的应用,大量使用缓存的话可以极大提高处理能力。
2:方案一你这么设计的话,索引怎么建比较好呢,还有就是会不会造成这个表过热,还有…… 我觉得像论坛这样的系统,使用缓存可以大大降低数据库的负载
3:大家的意思是分成主题表、回复表等多个表? 还是合成一个表然后做物理分区? 哪种更好呢?
4:再这么高插入更新的频率下 索引就有些不实用了,创建索引会降低插入更新的速度而且访问量这么大的情况下,索引不建议采用
5:就这样的一个论坛,实时在更新、发帖、回帖。我觉得在数据库上建立索引不太好,但是如果不建立索引如何来提高查询等方面性能呢?
6:都是分布式数据库了。放在多个表中,直接关联一点都没问题。重要是横向切分
7:认同分表,分库,缓存的做法
引用
问题分析:
每天论坛访问量300万左右,更新帖子10万左右。
1. 读写比例在30:1左右, 应向读取效率方面倾斜. 索引建立需参考常用读取的主关键字.
2. 每月数据在10W*30=300W. 可按月分表
3. 每年帖子在300W*12=3600W, 推算数据不会小于30T. 可按年分库
结构:
用户信息:独立表,userid主键
发帖、回帖:按月表存储,帖子唯一ID主键,日期索引。
帖子内容明细:按月存储,帖子唯一ID主键
8:拿一张500万的表来说事
引用
更新的时候如果没有索引的话
更新时间大概需要30秒左右 指的是全表更新~~
而查询某单行记录 却需要10秒左右~~
而加入索引的话
更新时间差不多慢了一倍有余
而查询记录则缩减到毫秒级~~
快了百倍有余~~
孰重孰轻 自己选
9:自己的一点经验:
引用
1.分表存储;
2.建立索引;SQL按所以查询的速度还是很快的;
3.避免整表扫描;先读取主题,在按照主题ID读取回复;再按照用户ID读取用户;而不要使用关联;
4.使用缓存;
10:需要分3张表,且建立索引。。。
理由如下:
引用
1:建立3张表可以避免冗余数据,维护起来方便。。。
2:每天论坛访问量300万左右,可见主要的压力来自于查询,sql查询的效率在于避免全表扫描,可见建立索引是必须的。。。
3:关于创建索引会降低插入更新的速度这个问题是不存在的。。。 因为,索引之所以会降低更新的速度的速度,是因为在更新完对应字段后还需要更新对应字段的索引。
4:看到更新帖子10万左右,这句话是说,我们可能对发帖标题,发帖内容,回复标题,回复内容这4个字段做更新。。。需要注意的是,这四个字段并不是用来建立表连接的字段,为了优化查询速度我们不会在这四个字段上建立索引,所以从这道题目出发,我们建立的索引不会影响更新帖子的性能。。。
所以,我认为最后的答案是建立3张表,在连接用到的字段上建立索引。。。
11:
引用
兩個表然後建一個視圖是否可行呢?
视图也是很慢的。
12:每天就更新10万个帖子,每天访问那么多,肯定是不能把所有的主贴放在一个表里,大表分小表,建立常用字段的索引,然后配置缓存。级联关系最好不要配置,等需要的时候再查询。
13:虽然题目中没有说明,但实际应用中,查阅帖子通常只会分页显示,而一页最多也就显示几十个帖子,那么实际上只要SQL语句构造得好,T_USER表其实只是跟一个只有几十行结果集的的子查询进行连接,应该基本不用担心出现性能问题。
而且实际上,一个万行级的表简单关联百万行级的表(其实镇魂歌数量级在我看来其实也算不上很大的表),在数据库方面完全有很多优化方式,甚至可以通过提高硬件配置来改善性能,实在没有很大必要进行结构上的冗余。一旦结构有冗余,为了保证数据一致性,往往你还要消耗更多的资源,反而得不偿失。
14:分表有垂直和水平分表
引用
1:无论你拿多少记录(甚至是1条),如果两个大表关联都可能会产生非常大的中间值,如果你排序(排序字段没有用到索引),你都可能导致数据库采用各种各样的方式来计算。
2:索引会导致插入、更新记录很慢,大家都是知道的。
3:水平分表可以解决这个问题,只要你能保证每个表只存适合的记录数(例如100W一个表) (水平分区也可以解决IO的一些问题)
4:还有就读写分离,master是写,slave是读 (再加上cache,一般问题都还好了)
上面都是比较大的工作量,最好是保证你的数据库设计是合理的(范式是第一步,然后考虑反范式),基本上也能满足很多问题了。
15:方案四 把内容与其它信息分开的好处就是可以让每个表的文件最小化,对数据库操作压力会减小,操作速度会快,还可以搭配缓存,把内容根据情况进行缓存,可以尽量很少访问表数据。
引用
1:对于上述分表方式也可以适用于分库操作,这样就降低了数据库单库的压力,把压力分散到各个机器
2:我的做法就是尽量避免表关联
3:再就是对于sql语句尽量都保证索引有效,不能索引的sql,尽量采用能索引的高效方式解决
16:外围的方案:
引用
1 读方面,生成静态页,或者缓存最新最热的帖子。
2 写方面,估计主要是INSERT吧,这个可以异步操作的。所有的写贴操作放到一个队列然后批量执行插入数据库操作。
17:方案四比较靠谱,再加上定期转储,海量的cache,大型论坛就此搞定。
18:我觉得应该还是使用3张表比较合适。
引用
1:业务上说,很可能主贴跟回复贴拥有不同的扩展,比如附件什么的,都放在一张表里面,假如主贴跟回复存在个性需求,怎么办?无限加字段么?
2:主贴跟回复在同一张表里,会增大锁表的几率。
3:索引的确会降低表更新的速度,但是带来的查询效率提升也是很可观的,因此我觉得,索引不能不用,但是要少用。
4:建立表时,确实可以通过楼上某位仁兄回复所言,用水平分表的方式,其实原理就是用先算再查嘛。
5:在前端表现上,可以使用ajax等方式,分步骤取数据,比如主贴的内容先取出来,然后再逐步加载回复信息等。
19:提高速度的关键:
引用
1.建立索引并在查询时充分利用;
2.避免使用关联,这样避免整表扫描;使用关联不如多次使用主键查询来的快;
3.一些处理的功能尽可能放到内存中来做,比如组织主题和回复;
4.使用静态页面也是个不错的做法;
20:方案三是延续了hibernate二级缓存的思想, 对于经常更新的数据都设计成单独表,这样可以最大程度的利用hibernate缓存
21:没有fast=true的设置,有人说or比in 好,exists比in 好,索引比全表扫描好,分区能提高查询效率,但是分区要降低插入效率
我要说的是,没有fast=true的选项, 如果能找到一步,或者几步公式化的方法能提高效率,那么优化器自己就会做了,根本不用用户担心。
假设 or比in好,数据库优化器把in语法和or语法走的执行计划一样就可以了,何必折磨用户呢。
说点实际的,很多人张嘴就说,SQL优化就是避免全表扫描,不知道大家有没有了解过索引查找的原理.索引查找数据,有两步要做,第一步是索引中快速查询,索引里只存储了对应表数据的rowid, 所以还有第二步,根据rowid去得到全部的数据, 所以需要一次磁盘i/o, 不要小看磁盘I/O,通过索引查询出的结果比较多的时候,磁盘i/o的时间是非常大的,这个时候比全表扫描慢得多, 实际上,oracle 10g基于成本的优化器(CBO),选择性不高的索引,优化器根本不会使用,而自动采用全表扫描的方式来做.
22:这个量级的bbs我设计过,当时是这样做的(方案五):
引用
共四个表:
1. 用户表
2. 主题表(包含最后回复信息,最后回复人,最后回复id等)
3. 回复表
4. 主题缓存表(这个取每个区的前面100条记录),一般来说负载最大的就是主题的第一页,所以缓存表是个小表。
共3台app集群,1台web,2台oracle一主一备,运行下来速度还是可接受的。
23:不建议进行表的设计冗余,感觉就想重复代码一样,有坏味道
引用
1:缓存常用的页面和数据
2:读写表或库分开(基于垂直分隔)
3:数据库可以进行垂直分隔(字段分到多个表中),再进行水平分隔(数据分到多个表中)
4:论坛功能可以进行分隔,不同的服务器负责不同的功能,如图片服务器,web服务器,邮件服务器等
总之,就是要细化分工
24:支持方案三的设计
读取的操作:
引用
1:显示帖子列表界面,如果主贴内容放在forum_topic表,那么这就是冗余的,假设都要获取100个帖子,一行的数据长度越大,数据库需要扫描的数据块就越多,性能也越差。
2:在打开一个帖子时,读操作通过索引关联到两张表(forum_topic和forum_topic_content)性能消耗对整个数据库来说不多。
写帖子的操作:
引用
发表帖子,对标题表和内容表分别作一个插入
更新非索引列不会引起索引更新:
引用
只要被索引的列(例如回复表的标题ID)不被频繁更新,即使索引所在地行的其它列被频繁update,索引也不会被更新从而产生性能消耗,一张表一天30万次的索引更新,因它引起的性能消耗小到即使数据库安装在奔腾3单核CPU下都能轻松承担下来, 为什么会有人对索引有这么大的误解呢?。对一个论坛(或者绝大部分的系统)来说,检索(SELECT)数据耗费的系统资源远远高于更新数据(INSERT/UPDATE)本身,而索引是专门为检索数据服务的,难道就为了节省更新数据的小小的性能消耗,付出检索100条数据时需要数据库扫描几千万上亿条数据进行数据匹配的代价?如果是这样的话,即使是有32核*CPU的数据库作并行查询都未必顶得住。
做数据库设计,还是多了解数据库的原理才好。
25:数据库切分是必须的。
引用
1:垂直切分:用户表、用户信息表、主题表、主题内容表、回复表
2:水平切分:主题1、主题2、主题3、...、主题n
3:缓存:缓存路由表
4:再配合数据库读写分离和集群吧
另:其实论坛修改标题、内容的概率是很小的。大部分都是新增