数据库大表设计方案总结.doc

Oracle 大数据量的处理 文：第三开发部（内部使用，请勿外传） 在我们的数据库应用中，。为了使大量的数据在读写操作和查询中速度更快，对表和索引进行分区的技术，以改善应用系统的性能。 slms_log_t和slms_cdr_t，但在各省的业务都没有用到slms_cdr_t，实际上只对slms_log_t进行操作。此表每天的入库数据量为1.7亿条(每天短信量大约6000条，日志是短信的2.5到2.8倍)以上（峰值入库每天10亿条，2007年春节数据）。河南短信集中日志建4个数据库，相互独立，用数据库链（DB_link）做连接，入库数据在应用程序处做负载均衡。表中为动态数据，均为插入操作。对于日志查询的业务处理都是操作这张表。业务需要对此表源号码，目的号码，时间进行查询，所以在其必需的主要查询条件上都设立了索引。按日志时间对此表进行了分区。 设计方案，包括表结构，索引，分区； 表结构与入库的日志结构对应，为分区表，根据入库日志的时间按天进行分区,并将到期的最早一天的分区删除。分区操作交由job执行，每天凌晨进行分区的添加与删除，默认创建此后5天的分区。根据查询用到的主要条件建立了分区索引。 关注要点分析，给出设计的原因分析和解决问题的关键点； 入库数据在应用程序处做负载均衡，4台数据库均担。Slms_log_t表中的数据由cms实时入库，后期的统计表是在每个数据库上分别出一套中间表，然后到一台机器上进行汇总。不管是从效率上说还是业务上说，按时间分区和在这些字段上建立分区索引是必需的。 总结， 将数据按时间进行分区，对关键字段做索引，对于提高效率还是有限的。在河南slms，尽管做了分区、索引，如果操作4个数据库联合查询，每个库数据量都大，查询速度并不算快。 案例二、梦网网关 需求描述，包括数据量，变动频率，在系统中主要的业务关联等； 梦网中的大表有两张，表中的数据量不同省份数据不同，但基本都在千万级以上。表的变动频率很大，数据为动态数据，千万数据/天，但都是插入的操作。在系统中主要是通过表中的某几个固定字段来与其它的表做业务关联。一般情况下，会将大表中常用的几个字段数据保留到中间表中，尽量避免对大表的查询，虽然大表中有分区，但每天的业务量还是比较大的，如果索引建的不太合适，查询起来还是相当耗时的，将表中的数据导到中间表会减少很多查询所需要的时间，有利于提高查询的性能。表结构是根据入库的话单格式来给出的。两个表都为分区表，对时间做的范围分区，使同一天的数据插入到一个分区中，这样对某些数据进行操作时，可以只在该分区中进行。数据库中的分区每天会通过JOB来自动创建，一般情况下会提交创建出10个分区。分区的创建及保留天数是可配的。可以通过调整对应参数来控制。索引为分区索引，当索引出现问题时，可以单独对某一分区索引进行重建。注：创建大表的索引需要在大的数据量上做测试，否则创建出来的索引可能会对提高性能没有太大的帮助。数据最好是能够模拟现网的情况。之前对梦网的索引做过测试，一个是联合索引，一个是单独的索引，在家里测试的时候没有太大区别，但对现网数据进行测试的时候，耗时相差将近3倍。 将表设计为分区表主要是从效率上来考虑的，如果是对全表进行操作在数据库中耗时会比较长，也会对数据库中的回滚段有较大的要求。所以梦网一般情况下会尽量避免对大表做直接操作。梦网当前的查询主要是对中间表进行的，除非是要统计一些话单的详细情况才会到大表中进行。设计方案：将数据按日期来进行分区存储，查询的时候尽量使用分区字段把范围缩小。但这种设计也有几个问题：(1)中间表的数据只能保留到前一天的数据，如果需要对表中的数据进行实时查询的，无法满足要求，还需要到大表中进行查询。因为为了提高利率的速度，中间表的数据都是在凌晨时通过JOB来大表中查出来的。(2)当入库出现问题时，有可能造成中间表数据与大表中的数据不一致的情况，这样所有从中间表中取数据得到的统计结果也是不准确的。JOB来自动创建及删除。分区的创建及保留天数是可配的。可以通过调整job内的参数来控制。 关注要点分析，给出设计的原因分析和解决问题的关键点； 将表设计为分区表主要是从查询效率上来考虑，全表扫描耗时很长，加索引也基本不可用。目前只能按一天查询话单，将查询范围限制在一个分区内，再通过索引查询。查询详单使用了oracle的rowid，管理界面直接通过rowid查询话单内容。索引的设计主要基于管理界面的查询条件，将界面上必填的字段如时间，目的号码和特服号码作为索引字段。 总结， 目前话单的查询都在大表中进行，每天00：00开始会有数据库job将大表数据汇总到几个不同级别的统计中间表，管理界面各统计模块只查询中间表不再关联大表。出现的问题与梦网也基本一样，没办法实时统计，只能统计前一天的内容。 总结： 使用分区的条