1、纵向分割(列分割)
现象:通常,随着开发过程的推进,系统中主表的字段数会越来越多。但是一个表的字段个数,是受数据库规范和性能限制的。例如,SQL Server数据库中一个表最多可以包含1024个字段,而实际应用中一般不能超过246个字段,每行数据可以存储8060字节,另外,对于大数据表来说,列的数量直接影响存取速度。数据的存储结构对行的存取更加优化,而不是列的存取。下面,提出几种分割存储列的情形。
案例1:
对于一个博客系统,文章标题,作者,分类,创建时间等,是变化频率慢,查询次数多,而且最好有很好的实时性的数据,我们把它叫做冷数据。而博客的浏览量,回复数等,类似的统计信息,或者别的变化频率比较高的数据,我们把它叫做活跃数据。所以,在进行数据库结构设计的时候,就应该考虑分表,首先是纵向分表的处理。
2、横向分割(行分割)
现象:对于记录行数巨大的表来说,最好的办法是按分类进行行分割,让数据存储在多个表内。自然界有一个放之四海皆准的“二八”定律,把它应用到数据上,就可以这样解释:在所有的数据中有20%的数据是可以满足我们80%的需求的。“
根据这个原理,通常有两种分类方法:
1) 按时间分类
如果数据的时效性很强,我们可以认为所有数据中,20%近期更新的数据能够满足业务80%的需求。例如,如果我们有5年的历史数据,那么就可以认为
其中在1年内(20%)更新过的数据(也可以是1年内创建的数据),能满足80%的业务需求;所以我们可以把这张表拆成两个表,分别存储20%和80%的
数据,以达到提高效率的目的。如果两张表仍然没有有效的提高性能,还可以利用“二八”定律再次分割。
2) 按索引分类
当数据的时效性不明显时,可以按索引分类数据。所谓索引可以是任何可以用于分类的字段,比如部门编号,员工编号,工艺编号等等。我们可以这样假设,
表中存储了所有零件的信息,但是在80%的情况下,1号生产车间只会存取自己部门用到的零件。于是,我们可以按照部门编号,把表分成多个。
案例2:同上面的例子,博客系统。当博客的量达到很大时候,就应该采取横向分割来降低每个单表的压力,来提升性能。例如博客的冷数据表,假如分为100个表,当同时有100万个用户在浏览时,如果是单表的话,会进行100万次请求,而现在分表后,就可能是每个表进行1万个数据的请求(因为,不可能绝对的平均,只是假设),这样压力就降低了很多很多。
3、数据库实例分割
一般情况下,开发人员习惯于给每个项目配置一个数据库。但是实际上我们可以给一个应用程序更多的数据库实例。比如,在一个网络游戏服务器中,经常会
有账户数据库(用于认证)、存储数据库(用于存储状态)、日志数据库(用于存储监控状态)、地图数据库(用于存储地图状态)等等。类比到ERP系统中,我们可以把许多项目共同的部分抽象出来,分别存储在不同的数据库实例中。例如,用户信息、部门信息、系统日志信息等可以定制成通用的数据库,每个软件项目都可以去使用。
4、数据库实例物理部署的分割
表分割、数据库实例的分割,为物理部署带来了灵活性。例如,我们对物料表按照不同的品目,进行了表分割;又对这些表部署在了不同的数据库实例中;这样我们就有条件把这些数据库实例分别部署在不同的物理数据库服务器上。这种部署给我们带来的好处是,物料计算时,我们可以指令所有的数据库服务器分布式计算,大大提高运算速度。