数据库表的拆分

标签: 数据库表 | 发表时间:2014-06-24 14:37 | 作者:mxdxm
出处:http://www.iteye.com

下面来分析一下:

  一、时间结构

  如果业务系统对时效性较高,比如新闻发布系统的文章表,可以把数据库设计成时间结构,按时间分有几种结构:

  1) 平板式

  表类似:

  article_200901

  article_200902

  article_200903

  用年来分还是用月可自定,但用日期的话表就太多了,也没这必要。一般建议是按月分就可以。

  这种分法,其难处在于,假设我要列20条数据,结果这三张表里都有2条,那么业务上很有可能要求读三次表。如果时间长了,有几十张表,而每张表是0条,那不就是要读完整个系统的表才行么?另外这个结构,要作分页是比较难实现的。

  主键:在这个系统中,主键是13位带毫秒的时间戳,不要用自动编号,否则难以通过主键定位到表,也可以在查询时带上时间,但比较烦琐。

  2) 归档式

  表类似:

  article_old

  article_new

  为了解决平板式的缺点,可以采用时间归档式设计,可以看到这个系统只有两张表。一张是旧文章表,一张是新文章表,新文章表放2个月的信息,每天定期把2个月中的最早一天的文章归入旧表中。这样一方面可以解决性能问题,因为一般新闻发布系统读取的都是新的内容,旧的内容读取少;第二可以委婉地解决功能问题,比如平板式所说的问题,在归档式中最多也只需要读2张表就完成了。

  归档式的缺点在于旧表容量还是相对比较大,如果业务允许,可对旧表中的超旧内容进行再归档或直接清理掉。

  二、版块结构

  如果按照文章的所属版块进行拆表,比如新闻、体育版块拆表,一方面可以使每个表数据量分离,另一方面是各版块之间相互影响可降到最低。假如新闻版块的数据表损坏或需要维护,并不会影响到体育版块的正常工作,从而降低了风险。版块结构同时常用于bbs这样的系统。

  板块结构也有几种分法:

  1) 对应式

  对于版块数量不多,而且较为固定的形式,就直接对应就好。比如新闻版块,可以分出新闻的目录表,新闻的文章表等。

  news_category

  news_article

  sports_category

  sports_article

  可看到每一个版块都对应着一组相同的表结构,好处就是一目了然。在功能上,因为版块之间还是有一些隔阂,所以需要联合查询的需求不多,开发上比时间结构的方式要轻松。

  主键:依旧要考虑的,在这个系统中,主键是版块+时间戳,单纯的时间戳或自动编号也能用,查询时要记得带上版块用于定位表。

  2) 冷热式

  对应式的缺点是,如果版块数量很大而且不确定,那要分出的表数量就太多了。举个例子:百度贴吧,如果按一个词条一个表设计,那得有多少张表呢?

  用这样的方式吧。

  tieba_汽车

  tieba_飞机

  tieba_火箭

  tieba__unite

  这个表汽车、火箭表是属于热门表,定义为新建的版块放在unite表里面,待到其超过一万张主贴的时候才开对应表结构。因为在贴吧这种系统中,冷门版块肯定比热门版块多得多,这些冷门版块通常只有几张帖子,为它们开表也太浪费了;同时热门版块数量和访问量等,又比冷门版块多得多,非常有特点。

  unite表还可以扩展成哈希表,利用词条的md5编码,可以分成n张表,我算了一下,md5前一位可分36张表,两位即是1296张表,足够了。

  tieba_unite_ab

  tieba_unite_ac

  …

  三、哈希结构

  哈希结构通常用于博客之类的基于用户的场合,在博客这样的系统里有几个特点,1是用户数量非常多,2是每个用户发的文章数量都较少,3是用户发文章不定期,4是每个用户发得不多,但总量仍非常之大。基于这些特点,用以上所说的任何一种分表方式都不合适,一没有固定的时效不宜用时间拆,二用户很多,而且还偏偏都是冷门,所以也不宜用版块(用户)拆。

  哈希结构在上面有所提及,既然按每个用户不好直接拆,那就把一群用户归进一个表好了。

  blog_aa

  blog_ab

  blog_ac

  …

  如上所说,md5取前两位哈希可以达到1296张表,如果觉得不够,那就再加一位,总数可达46656张表,还不够?

  表的数量太多,要创建这些表也是挺麻烦的,可以考虑在程序里往数据库insert之前,多执行一句判断表存在与否并创建表的语句,很实用,消耗也并不很大。

  主键:依旧要考虑的,在这个系统中,主键是用户ID+时间戳,单纯的时间戳或自动编号也能用,但查询时要记得带上用户名用于定位表。

  四、总分结构

  以上的这些结构,根据每个业务系统,能想出的估计还有很多。不过现在互联网业务越来越复杂了,有些时候,单一的拆分法还不能实现需求,需要几种拆分方案一起实施,多管齐下,这时候其中的逻辑会让人绕晕。我就开发过一个系统,仅仅是将哈希结构和时间结构混着一用,觉得逻辑就相当复杂。

  所以,除了拆表之外,按最原始的单库单表,再建一个总表,是非常有利的架构。在这个架构中,每次往数据库会写入两倍数据,读取主要依赖拆表提升性能,总表用于实现拆表后难以实现的功能并且用于每天的定时备份;另外总表和分表还相互是一个完整的备份,任何一个分表损坏或数据不正常,都可以从总表中读到正确的数据并恢复,反之亦然。

  在总分结构中,让人感到质疑的是总表的性能和可维护性。我的方案是总表可采用相对能保证稳定的一些服务软件和架构,例如oracle,或lvs+ pgpool+PostgreSQL,重点保证数据稳定;相对的,分表就用轻量级的mysql,重点在于速度。能够对总分表各采用不同的软件和方案,也是总分结构的一大特点。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [数据库表] 推荐:

数据库表的拆分

- - 数据库 - ITeye博客
  如果业务系统对时效性较高,比如新闻发布系统的文章表,可以把数据库设计成时间结构,按时间分有几种结构:.   用年来分还是用月可自定,但用日期的话表就太多了,也没这必要.   这种分法,其难处在于,假设我要列20条数据,结果这三张表里都有2条,那么业务上很有可能要求读三次表. 如果时间长了,有几十张表,而每张表是0条,那不就是要读完整个系统的表才行么?另外这个结构,要作分页是比较难实现的.

数据库、表切分

- - 数据库 - ITeye博客
SQL Server数据库大型应用解决方案总结. 数据库的垂直划分和水平划分(注意评论). 通过某种特定的条件, 将存放在同一个数据库中的数据分散存放到多个数据库上,实现分布存储,通过路由规则路由访问特定的数据库, 这样一来每次访问面对的就不是单台服务器了,而是N台服务器,这样就可以 降低单台机器的负载压力.

进销存数据库表设计

- - 数据库 - ITeye博客
CREATE TABLE user /*用户表*/ (. CREATE TABLE Supplier /*供应商表*/ (. NOT NULL, /* 供应商编号 ,主键 */. NOT NULL, /* 供应商名称 */. NOT NULL, /* 地址 */. CREATE TABLE Customer /* 客户表*/ (.

开源网站分析软件Piwik的数据库表结构

- sun - 标点符
Piwik是一套基于Php+MySQL技术构建,能够与Google Analytics相媲美的开源网站访问统计系统,前身是phpMyVisites. Piwik可以给你详细的统计信息,比如网页浏览人数, 访问最多的页面, 搜索引擎关键词等等,并且采用了大量的AJAX/Flash技术,使得在操作上更加便易.

PostgreSQL数据库、表空间、角色及用户

- - 数据库 - ITeye博客
转自:http://blog.chinaunix.net/uid-354915-id-3499975.html. 1、通过pgAdmin创建数据库TestDb1:. 打开数据库TestDb1看到建库脚本:. 在目录——PostgreSQL(pg_catalog)——数据表——pg_database中可以查看多了一个数据库TestDb1:.

java调用kettle api 操作日志写入到数据库表

- - 开源软件 - ITeye博客
//将step日志数据库配置名加入到变量集中. //StepLogTable使用的数据库连接名(上面配置的变量名). //设置Step日志的表名. //设置TransMeta的StepLogTable. 已有 0 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

常见电商项目的数据库表设计(MySQL版) - 简书

- -
电商常用功能模块的数据库设计. 改进1:第三范式:将依赖传递的列分离出来. 比如:登录名<-用户级别<-级别积分上限,级别积分下限. 改进2:尽量做到冷热数据的分离,减小表的宽度. 用户登录表(customer_login). 用户信息表(customer_inf). 用户级别表(customer_level_inf).

数据库表为什么不可以只设置一个主键,一个text类型,序列化存储对象,这难道不跟nosql差不多了?

- - 知乎热榜
啊……这个……看着一群人见山不是山的一阵胡扯,不由得有些尴尬……. 首先,明确回答题主的问题:在你面对的工程问题面前,你的想法完全可行. 但是,这个世界上,是有很多完全不同的问题的……. 想说清楚这个,我就得从头开始科普了. 关系型数据库背后是所谓的“关系代数”. 这个东西意思嘛……大致来说是这样的:对于一组二维表格格式的数据,在上面可以做的基本操作只有四种,也就是并、交、差、笛卡尔积,其它运算都可以通过基本运算的组合得到.