大表设计思路

大数据量表的设计思路

Renhao 2011/4/7

大数据量表在系统中所占比例极小，但却会成为系统正常运行的性能瓶颈，根据自己对平台的业务了解，提出了个人对大数据量表的基本设计思路，对自己后续的工作也是一个说明参考。
1. 设计原则
大表的设计同系统其他设计一样，也需要遵从以下几个基本原则：  全面性：设计能够支撑与其相关的所有业务和数据承载，而非基于某一个功能点，更多需要从宏观上考虑关联业务和数据，从整体上来提高性能。若因为一个功能点的性能提升却造成了系统其他的瓶颈而使系统整体性能下降，就得不偿失了。
 前瞻性：设计能够适应未来的业务数据的变化，关键是满足后期数据量的扩展。
 继承性：在面向未来数据量增长的同时，所有的设计和变更也尽量遵守原数据结构，维护系统的稳定性，并保证新旧数据的平稳过渡。
 可维护性：部分数据存储和转移可能需要配合定时任务和人工来维护，可维护性高不仅能提高效率，更能保证数据功能正确和稳定。

2. 设计思路
平台的主要性能瓶颈主要是在大表查询这块，表写入目前还没有形成压力，以下主要阐述几种设计思路，有的只会在某种特定业务中会用到，需要通过具体业务来对表设计进行具体分析。
2.1. 垂直切分
垂直切分主要是针对数据库架构而非表的设计而言的，在这里提出来是因为它会影响到大表结构的设计。
系统的总体功能是由多个功能模块所组成，而每一个功能模块所需要的数据对应到数据库中就是一个或多个表。各个功能模块相互之间的接口越统一，越少，系统的耦合度就越低，实现数据的垂直切分就越容易。若某一个功能模块其整体数据量特别大或者因该功能并发读写特别频繁而形成瓶颈，且与系统的其他功能模块耦合度很低，则可以考虑将该功能模块整体垂直切分，将其部署在单独的主机上，分摊整体系统的压力。
2




 应用：与其他功能模块耦合度低且存在高并发或大数据量性能瓶
颈的功能模块。
 优势：拆分规则明确，可操作性强；
易于数据维护，容易定位。
 难点：原来的部分表关联无法在数据库内部完成，需应用程序完
成；
对于数据量特别大的表仍存在性能瓶颈。
2.2. 水平切分
水平切分是针对表按照数据行来切分，即将表中的某些行切分到
一个数据库，而另外的某些行又切分到其他的数据库中。切分必须按
照某种特定的规则来进行，这样才能够较容易地判定各行数据被切分
到那个数据库中了。可根据关键字段的取值（奇偶性，取模），时间
3

字段的范围等来进行水平切分，结合实际业务需要和数据量来定义切分的粒度。
如果某个功能存在一张大数据量表而影响性能，而整个功能模块的大部分核心表都可以通过某个字段（如：userid）来进行关联，那这个字段就是一个进行水平切分的关键字段，这样所有可以与该字段关联的表都可以按照特定规则被水平切分到同一个数据库中，既能有效分摊单一数据库的数据承载压力，又不影响原库表的关联操作。
如果只单独切分这一张大表，这样也能减轻该表的大数据量瓶颈，但原来的关联操作就需要跨库操作或是需借助应用程序来完成。




 应用：造成性能瓶颈的大数据量表具有与其他核心表关联的关键
字段，这样可以一并对所有与该业务相关的数据表依据该
4

关键字段进行水平切分。
 优势：表关联操作能够在数据库内部完成；
能有效解决因大数据量和高负载所遇到的瓶颈；
只要切分规则定义好，则可以很好的支持后期的数据量递
增。
 难点：切分规则相对复杂，很难抽象出一个能满足整个功能模块
或是整个数据库的切分规则；
后期数据的维护难度增加，数据迁移更加困难。
2.3. 拆分表
水平切分是根据数据行来操作，拆分表是在保持原表的列属性不变的情况下将表拆分为二个表或多个表，是按照表列来操作。
当对一个大数据量表频按照某一维度频繁查询统计多项指标数据时，由于各个事务都会争用同一个大数据量表资源而使效率低下。例如一张同时记录发生额信息和余额信息的大数据量表，系统一个或多个功能点需要查询统计发生额的相关信息，另一个或多个功能点需要查询统计余额的相关信息，且发生额和余额之间没有数据关联操作，为了解决同时争用一个大表资源的问题，可以将该表一分为二，其中一个表只存储发生额的相关信息，另一个表只存储余额的相关信息，在查询统计这两项指标数据时，就可以分别从两张表来获取数据，从而解决大表资源争用的问题。可以认为拆分表即是针对表而言的垂直切分。
5
虽然列属性没有改变，但数据结构变更（表名和列数量），对于已有系统中耦合度高，功能关联性强的模块需要修改与之相关的程序，包括数据入库，读写表等操作。




 应用：功能较为独立，与其他功能耦合度低的模块，多个事务频
繁同时查询统计大数据量表中互不关联的指标数据，可将该表按照指标列进行拆分。
 优势：拆分规则确定后很容易操作实施；
避免不同事务同时争用同一个大表资源，分摊大表的查询统计压力。
 难点：表拆分必将修改与之相关的程序和设计；
若是在后期，数据结构的更改，会对系统功能的稳定性造成潜在威胁，增加风险。
6

2.4. 数据转移
数据转移是常用的将大数据量表瘦身为小数据量表的实施方式，在大多数既定业务规则下，系统中需使用的是时间较为靠近的业务数据（短时间的可能一年，长时间可能为三年五年），而由于时间范围大，会使得某些业务数据表数据量庞大，但有效使用数据却只占很小一部分，这种情况下可以将过期不用的数据转移到另外一张归档表中，该表只做数据存储，没有任何其他功能。




 应用：以时间为维度存储数据的大表，且功能使用中只会用到近
段时间的数据，过期数据可转移处理来为其瘦身。
 优势：规则简单明确，实施容易，操作性强；
维护简单，只需定期转移数据即可。
 难点：若业务变更规则需要用到过期数据，则实现会很困难，可
扩展性差。
2.5. 表分区
表分区可以通俗的认为是将一张大表，根据条件分割成若干“小表”，但不会改变任何表结构，而是将“小表”数据分别存储在独立
7

的分区内，分割后的分区仍然是一个整体，在进行分区设计时，不能够只对数据分区而不对索引分区，也不能够对索引分区而不对数据分区。Mysql5.5可支持多种分区类型（RANGE、LIST、HASH…）。
既然需要分区，则会有一个分区的规则，一般情况下是根据数据量的分布规则来制定，如表数据量是按照入库时间来递增存储的，则可按照入库时间进行分区，也可以按照区域来进行分区，分区的数据粒度具有一定规则，要避免个分区数据严重不均的情况，如一部分的分区数据量非常大，而另外一部分的分区数据量却又很小,分区的主要目的就是将大数据量均匀的分布存储到各个独立的分区内，这样获取数据时就可以避免全表扫描，而只需要在数据存储的指定分区内查找就可以了，不必去查询其他的分区，提高查询效率，必要时也可以对单个分区建立索引。如果多个分区可以存放在多快硬盘上，硬盘的吞吐量可以得到显著提高，也可以提高查询的效率。同时，也可以根据需要能够方便的删除分区或新增分区，对于海量的大数据表尽量避免这么做，这样做需要对数据进行重新组织，会大量的消耗服务器的资源，在前期，如果有必要采用分区管理的表，应提早去做。
8




 应用：可根据某一维度（如：时间、区域）来分区存储数据的大
表，该维度频繁地用作查询条件或与其他表关联。
 优势：分区易于管理和维护，不需要变更任何数据结构以及与之
相关的程序和设计；
可有效提高查询效率，减少大表查询的服务器消耗； 由于数据存储在不同分区，提高系统并发能力。
 难点：根据业务规则来制定合适的分区类型，一般情况下可用
Range分区。
2.6. 利用宽表
宽表，是通过增加表的列属性来解决复杂查询的一种表结构设计，有时也会通过增加冗余字段来减少关联查询，更多情况是在第一种应用中会用到宽表结构，宽表以空间来换取时间，在特定需求下可
9

能会达到上百列之多，尽管带来维护成本，但是可以有效的提高查询效率。例如有这么一张大数据量表，其数据是按天来存储每天的交易额（日期+交易额），现有这么一个需求：查询某一个月份中每天的交易额较之昨日的环比增幅，按照现有的表结构需要逐行去计算，要用较为复杂的数据转存来获取结果，效率必定不会高；倘若将该表的表结构按照月份来设定为宽表，即每一条记录存储的是某一个月份中每一天的交易额（月份+1号交易额+2号交易额+„„+31号交易额），通过宽表只需用一个查询语句查询表中的一条记录就可以完成上述需求，简单快速。原来窄表存储一年的数据需要365条记录，利用宽表后存储一年的数据只需要12条记录，当然代价是表结构变得庞大，在并发较高的情况下也会增加表锁资源的争用，同时在数据入库到该表时也需要根据宽表的设计做相应的修改。
将数据由基于行的窄表转存为基于列的宽表中，也可以认为是一个行转列的变换过程，可以由具体程序来实现。
10




 应用：数据规则明确，且需要复杂的关联查询或逐行计算来获取
结果的大数据量表。
 优势：将复杂的查询变得简单，数据维护更容易定位。 单表查询并缩小查询范围，能大幅提高查询效率。  难点：表结构变得庞大，增加表的维护成本；
数据入库需根据宽表结构做相应调整，必要时也需要通过
人工或定时任务将数据转存到宽表。
2.7. 区分标识
在大数据量表中，使用标识主要目的是为了区分新旧数据（有效数据和过期数据），实际业务会需要对某段时间（当日或当月）的业务数据进行统计汇总，为了提高统计的效率，可以用标识来区分已统计过的数据和未统计的数据，尤其是在以时间来递增入库的大数据量表，新增的数据只占整个表数据量的很小比例，通过该标识可以有效
11

的缩小查询范围，来提高查询统计的效率。




 应用：需要对最新数据进行查询统计的大表，同时为保证系统稳
定和最小风险不愿进行其他的表结构修改和改进措施。
 优势：规则简单，实施容易，不会对其他功能造成影响；
可快速解决眼前查询统计效率低下的问题。
 难点：若新增的实时数据量猛增，则不能保证高效，可扩展性较
差。
3. 小结
很多情况下，可以通过正确的索引、修改程序、调整性能参数或在前期进行结构微调来达到效果，所有的设计和结构调整都是为了提高系统的查询、统计效率以及并发性能，在具体到某个功能模块中的某张大表时，应考虑对象的逻辑属性、关联业务、并发控制等方面，另外需要慎重考虑的一点是”以终为始”，即以最终功能性来判断设计结构是否合理，可以根据报表功能、关键功能流程来反复评判需要用
12
到的大表结构是否合理，是否能保证大数据量报表的查询效率，关键数据的转换和存储效率。
在索引和程序都不能很好解决效率问题后可以考虑这几种设计思路，某些情况下会是几种相结合的方式。就本系统而言，功能点很多，耦合度也比较高，更多的会用到表分区、数据转移、水平切分，某些特定的查询统计可能会借助宽表来实现。设计过程中会有一个反复判断的过程，有时主观的判断很难得到清晰准确的结果，最直接的方式就是验证比较，根据表的读写状况和数据递增情况，权衡实施难易和实际效果，综合考虑后来确定使用哪种方式，并在使用大表时尽量避免多表的关联查询，在系统设计和开发阶段就尽可能减少因大数据量表而带来的性能问题，这些都需要在大量的实践工作中不断地积累经验。

13