翰云数据库测试报告.DOC

电信OLAP业务平台应用报告 测试 测试数据主要由三张表组成：CDR_GGPRS_CMREADCDR_GPRSODS_DR_GGPRS_HZ记录数分别为106,68,800和156,606,600。V_CDR_GPRS_hz图把相关记录进行建组计算，然后把执行结果数据插入到DW_NEWBUSI_GPRS_hz中。由于提供的样本数据量比较小，我们对数据进行放大， 表CDR_GPRS大至688倍，表ODS_DR_GGPRS_HZ大至1，566，066倍，其中对ODS_DR_GGPRS_HZ的USER_ID列值的不同值个数生成为4,847,661个。测试数据的SCHEMA的结构，包括表和视图的结构见附件。我们实现了一个客户端程序实现模拟数据，数据的生成时间为15个小时左右。表ODS_DR_GGPRS_HZ义有复合主键（USER_ID, USER_NUMBER, START_TIME, CHARGING_ID, GGSN_ADDRESS, SERVICE_CODE, REC_SEQ_NO），它总共由152个列组成，见下图： 表ODS_DR_GGPRS_HZ系统按照复合主键值分成316个小表，每个小表的记录数位40万左右，均匀分配给各个小表服务器见下图： 引擎修改 由于测试使用了Oracle特有的函数，为了实现测试，我们在翰云数据库引擎中加入了以下函数：to_char，to_date，nvl，substr，instr，length，trim，ltrim，rtrim和round。其中length，substr，instr，trim，ltrim，rtrim，SQL标准有对应的定义，我们把引擎作了修改后也支持Oracle的语法格式。 测试环境 用于执行这次测试项目的数据库机器，是由个1U大小的戴尔机架式服务器搭建而成，服务器之间通过1台千兆的思科交换机互联。节点配置： 型号 DELL Power Edge R410 CPU Intel Xeon E5606 @ 2.13GHz (单路4核) 内存 DDR3 8G (4G * 2) 硬盘 SATA 7200转 8T (2T * 4) 操作系统 CentOS 64位 分布式文件系统 Hadoop 集群配置： 节点个数 网络交换机 思科交换机Catalyst3750 24口 1G 数据库节点编号及配置： 节点编号 Hadoop角色 /内存分配 Cloudwave角色/内存分配 cloudwave0 元数据节点/1000M 数据节点/1000M 主服务器节点/2000M 小表服务器节点/000M cloudwave1 从元数据节点/1000M 数据节点/1000M 小表服务器节点/5000M 数据库客户端 cloudwave2 数据节点/1000M 小表服务器节点/000M cloudwave3 数据节点/1000M 小表服务器节点/000M cloudwave4 数据节点/1000M 小表服务器节点/000M 测试结果 查询结果： 最终SQL执行结果V_CDR_GPRS_hz做建组查询，翰云数据库把SQL查询分解成了阶段性的查询作业（QueryJob），按序列执行，即下一个作业的执行必须是在是一个作业执行结束后开始，而每个查询作业是由一个或多个子任务组成，这些子任务是并行执行的，即系统在执行每个查询作业时，并行执行它的子任务。下图列出了SQL的阶段性查询作业信息，一共执行了117秒钟。如果把最终数据插入到DW_NEWBUSI_GPRS_hz，则需要再加上30秒左右的时间。整个查询的执行结果如下图： 从上图可以看出，整个SQL的执行被分解成15个QueryJob，其中执行时间最长的QueryJob是QueryJob[155:MAP(OUTPUT_GROUP_BY), tasks:318, time:107,714, gap:9]，执行时间为107秒，占据了所有执行时间的91.4%份额，这也确实是这个SQL的实际需求，它需要从390多个小表中执行建组统计工作，在这个执行过程中，我们对CPU进行了监控，基本处于峰值状态。 查询结果： CPU基本处于峰值运行状态： 内存使用的情况为：主服务器基本处于空闲状态，而各个小表服务器的内存都处于频繁波动状态，这是由于查询过程中产生了大量的可回收对象，JVM需要频繁对它们进行回收，另外，查询引擎也产生了一些中间结果数据，一开始也放在内存区域中，一旦内存压力加大，翰云数据库也要把这些中间结果写到