澳门美高梅手机网站单机大数量量表的查询和插入优化方案分享

5.1 人员分布测试方案描述 9

ab无法动态修改controller

当专业项目蒙假如是要由网中下载模型,存在这么的一个问题Animator中的Controller不能够修改,所以要是运用assetBundle动态加载,那么是非常的。

如若单机演示,那么尽管可运用这个新动画系统

3.2.2测试结果(所有测试结果单位吗秒)6

在的题目

作者:Dreamingodd

Unity版本

Unity 4.0

3.4结出分析 7

前言

此时此刻我还只是读到Mecanima的初级阶段,看了了阿赵的日记《Unity3D
4.0新职能:Mecanim动画系基础教程》,对Mecanima的打听再尖锐了有些,谢谢他的享用。

6.3 结果分析 12

6.2.1走最小离

移步超过多少像素算作是倒一不行,移动的数是要插入数据库的,这个离该是测试不会见并发穿墙等异常情况后的绝可怜距。

2.2.7员工分区和月分区

Engine:Archive,一张表,先以月分为12只分区,再比如员工ID号将每个月分区分为80独次分区,形成并960个分区。

 

4.1概述

本方案的插入是为1000张表中定时插入数据,而且是平条插一潮,并且不歇地换表,所以插入效率是颇没有的,以上任意方案(除分表+分区),效率都应该是如果高过本方案的。但异常数据量的表加索引时插入效率也深没有。所以要做了这个测试。

2.2.3时分区

Engine:Archive,一摆表,四单分区,按照时间。

2.2.1原方案5

5.3 查询速度测试 10

5.人口分布测试(Ed.2.1)

2.2两样方案的介绍

4.3测试结果(所有测试结果单位吗秒)
8

3.3职位查询 7

6.3 结果分析

 

 

一天的数据量

一天数据大小

一年数据大小

没有应用定位模糊的结果

8640万条

8G

3TB以上

应用了定位模糊的结果

350万条

388MB

292GB

 

数据量减少了24倍增,当然就是较可观的动静,1000总人口一如既往年之数据量292GB。

 

6.固定模糊对DB的熏陶(Ed.2.2)12

定位系统数据库设计方案

6.2.3 测试所选用的数码解析12

2.2不比方案的介绍 5

2.2.2一张表

Engine:Archive,用于测试时的比较。所有的数据以一如既往摆表中,没有其余处理。

4.1概述 7

5.人员分布测试(Ed.2.1)9

3.2.1测试方法描述

查询一定时间段外某称职工的track数据。

查询语句:

Select * from table_name where id = ?  and trackTime < ?  and
trackTime > ? ;

6.2 影响结果的参数描述 12

——历史轨迹表

3.4结出分析

由于方案3(季节分区)和方案4(月份分区)在历史轨迹的率先次等测试着虽过3分钟所以在连片下去的测试中叫放弃,方案6(员工分表+月份分区,1000*12=12000单分区)的方案于插入数据时于第500瓜分区地处倒,即使换成员工分表+季节划分区(1000*4=4000独分区)也当第1500区划区地处倒,所以是方案吗被放弃。方案7员工分区的显现还好,但几每个测试所用的年月还在原方案的5-10倍,所以同样放弃。

鉴于Archive引擎不支持索引,所以最终一个方案的发动机改用InnoDB——员工分区加索引,这个方案于测试着见好,在与原来方案的比较受到基本完胜。尤其是在富有人数的职查询中比较原方案快凑500倍增,但是加索引之后的插入效率会成为问题。所以接下去做了这方案的插入速度测试。

6.1 方案描述

永恒模糊时JAVA端对历史轨迹插入数据库的数量进行的淘工作,主要作用在于减少数据量、减少针对硬盘存储空间的渴求、减轻数据库查询的下压力。它可以界定一个口之走达成自然距离才算是做运动,而非算是做活动的数量大部分不栽数据库,但与此同时于JAVA业务超时的限制外,插入一不良停留的数码。具体见要下“参数描述”的逾期时间。

2.1表结构

本方案的申结构:

CREATE TABLE `track_1094` (

  `track_id` bigint(20) NOT NULL AUTO_INCREMENT,

  `trackTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

  `x` double NOT NULL,

  `y` double NOT NULL,

  `z` double NOT NULL,

  `area` double NOT NULL,

  PRIMARY KEY (`track_id`),

  KEY `trackTime` (`trackTime`)

) ENGINE=InnoDB AUTO_INCREMENT=549207 DEFAULT CHARSET=utf8;

 

新方案的表结构:

CREATE TABLE prison_all (

  track_id bigint(20) NOT NULL,

  trackTime timestamp NOT NULL default CURRENT_TIMESTAMP,

  id int NOT NULL,

  x double default NULL,

  y double default NULL,

  z double default NULL,

  area double default NULL

)engine=archive DEFAULT CHARSET=utf8;

 

 

由新方案要尝试用同一张表解决问题,所以加了职工的ID,相当给原方案受到之MAC地址(标签),engine一始选用的是archive,最后移回了InnoDB。

3.1数描述

    将一亿漫漫数分别插入8种植方案,以供查询。数据时限定1年、任意天数、任意小时数、20分钟、0秒。即并无完全是不管三七二十一时间。这样做是盼一亿长条数可知基本覆盖有可能出现的年月价值。每人1亿/1000=10万漫长,时间也许频:365*24*20=17万。这个方案并无成立,但绝初步的当儿去出的数只能沿用了。否则再插一全几亿之数目极其浪费时间。

3.3.1测试方法描述7

6.2.3 测试所选用的数额解析

过时间30秒,模拟移动的工具每次运动20px,以监狱版本业务的全天在线和良少运动为模型,设置极端小活动距离也100px。1000人口在线测试:

3.3位置查询

6.2.2 超时时间12

3.2.1测试方法描述6

3.3.2测试结果(所有测试结果单位吗秒)7

5.5 解决方案

当华为应先生之提议下,将人员分布与历史轨迹两只事情分别,人员分布的表定位每人一分钟一糟数据,这样平等龙的数据量为3000*24*60=432万。

 

5.3 查询速度测试

人员分布查询速度测试
(单位秒)

1分钟的60条数据筛选100人的100条数据

1分钟的60条数据筛选50人的50条数据

1分钟的60条数据筛选25人的25条数据

一小时的3600条数据筛选100人的100条数据

一小时的3600条数据筛选50人的50条数据

一小时的3600条数据筛选25人的25条数据

MyISAM引擎100分区

4.1

1.8

0.5

4.4

3.4

1.6

MyISAM引擎200分区

2.6

1.3

0.9

3.2

1.8

8.4

InnoDB100分区

4.8

1

0.5

5.4

3

1.1

 

Version:2.2.0

3.1数量描述 6

3.3.1测试方法描述

查询一定人群以一定时间点的位置。

查询语句:

Select  * from table_name where id < ? and trackTime = ? ;

6.2.1动最小去12

7.总结13

2.2.3季分区5

1.2范围

单独提到原系的史轨迹查询和职位查询两单职能,以及Track表。

6.定位模糊对DB的影响(Ed.2.2)

4.3测试结果(所有测试结果单位也秒)

员工分区加索引插入测试

1000

3000

5000

10000

批量插入

0.25

0.5

1

4

单独插入

1.9

5

9

16

5.7 结果分析2 11

1.引言

2.2.8员工分区加索引

Engine:InnoDB,一布置表,按照员工ID使用HASH分区法分为500独分区,为id和tracktime加上复合索引,因为,两种植查询都见面因此到当时点儿列值。

1.引言4

6.1 方案描述 12

7.总结

经测试和概括平定方案8——员工分区加索引的方案查询效率至上,但是插入数据极其好于缓存中存储list,拼接成sql语句后一次性插入多久数,才能够而插入效率达而接受之水平。

 

备注:可能查询时mac放在前方有助于提高查询效率。

 

5.2 插入速度测试

插入速度测试

5400万

1000计算

1亿计算

1亿大小

MyISAM引擎100分区

26分钟

0.029秒

48分钟

 

MyISAM引擎200分区

30分钟

0.033秒

55分钟

 

InnoDB100分区

79分钟

0.079秒

146分钟

 

 

2.2.6职工分表和月分区

Engine:Archive,先以职工反复分为1000张表,再比如月将每个表分为12单分区。1000*12=12000各分区。

5.6询问速度测试2

结果:16ms

2.2.4月份分区5

5.4 结果分析

插测试的结果证实MyISAM引擎的插速度要好给InnoDB,但InnoDB的效率为未是勿可知接受,因为在品种蒙一次性缓存插入数据库2000长达左右,1秒钟还过得去。

询问效率的问题几乎宣告了方案的败诉,查人员分布理应是浑1000丁的查询,由于效率太低才使用100总人口分批查找,但是100人数4秒的效率根本无法接受。

尚得还惦记方法。

2.2.7员工分区和月分区5

2012.9.5

2.1表结构 4

2.2.5员工分区

Engine:Archive,一摆设表,按照职工ID使用HASH分区法分为100单分区。

6.2 影响结果的参数描述

4.插入入速度测试

1.2范围 4

3.询问速度测试6

2.2.8员工分区加索引6

5.6询问速度测试2 10

2.方案描述

4.插入入速度测试7

6.2.2 超时时间

过期时间是停数插入间隔的极小范围,如超时时间也30秒,那么在逾期时间外没运动事件之话语,将当30秒内插入一不良停留的数据。

2.2.4月份分区

Engine:Archive,一摆放表,12只分区,按照时间。

2.方案描述4

4.2测试方法描述

前提:表中都发7500万长条数据,随机大成定量的Track对象,保存于List中,向方案8——员工分区加索引的表中插入数据。插入方法两种植:一种植是均等修一条地栽,另一样栽是拼接一千只Track对象的多寡变成同长达sql语句一次性插入表中。

3.2.2测试结果(所有测试结果单位吗秒)

亿级别历史轨迹查询(s)

1时

1天

5天

10天

1月

2月

1

员工分表(原方案)

0.4

0.4

0.5

0.6

0.7

2.9

2

纵然相同张表

280

没测

没测

没测

没测

没测

3

时分区

250

没测

没测

没测

没测

没测

4

月分区

225

没测

没测

没测

没测

没测

5

员工分区

2.1

2.3

2.4

2.4

2.5

2.7

6

员工分表+月份分区

Fail

Fail

Fail

Fail

Fail

Fail

7

职工+月份分区

530

没测

没测

没测

没测

没测

8

员工分区加索引

0.02

0.05

0.16

0.2

0.7

0.9

 

1.1目标

事先的系Track(轨迹)表的计划是由职工ID号生成,也就是说一千个人口,一千单数据表。这使查询职位的上,需要从一千独不等的表中插入和查询数据。故尝试重新设计。

5.2 插入速度测试 10

4.2测试方法描述 8

3.3.2测试结果(所有测试结果单位吗秒)

亿级别岗位查询

1个人

10人

100人

所有人

1

职工分表(原方案)

0.3

4

45

477

5

员工分区

3.3

291

291

295

7

职工+月份分区

0.5

38

没测

没测

8

职工分区加索引

0.02

9

9.5

9

4.4结实分析

合接sql语句之频率在频繁单独的十倍左右,而因3000总人口乎准绳的数额一次性插入的快在0.5秒左右,效率及吧足以领。

 

2.2.2一张表5

2.2.5职工分区5

立马是之前公司之一个政工的调研测试报告,测试数据量大约是一模一样龙8640万长长的数据。

5.7 结果分析2

确定性,可以接受之结果。

题目为解决。

 

5.4 结果分析 10

2.2.1原方案

Engine:Archive,简称:员工分表。设计了一千独职工,id范围(0-1000)。得到一千张表。

2.2.6员工分表和月分区5

 

4.4结实分析 8

3.询问速度测试

3.2历史轨迹查询

5.5 解决方案 10

3.2史轨迹查询 6

目录

5.1 人员分布测试方案描述

眼前数据库方案是比照天建表,原因是考虑到一个口皆天在线(如养老院),一秒钟一漫漫数据一致天不怕是86400修,1000独人口就算闹8千万,3000人口闹2亿5千万——这个数字就是不肯定罩得下马了。当然也来一定之使事件流和岗位模糊处理减少数据量,但是这些措施要无通过系统的测试,也未尝数支撑。

此次的测试模拟5千万之测试数据,1000丁15钟头吗5千4百万久之数据量,分几栽存储引擎,共三种植方案:InnoDB、MyISAM100分区和MyISAM200分区三栽。

 

表结构:

create table track_InnoDB(

tag_id bigint,

time timestamp,

x double,

y double,

z double,

area int,

status int(1),

alarm int(2),

index(tag_id,time)

)engine=InnoDB DEFAULT CHARSET=utf8

partition by hash(tag_id)

partitions 100;

 

测试目的吧:三种植方案的口分布查询速度。

查询语句:

一分钟:

select max(time),x,y,tag_id from track_2012_12_13  

where tag_id in (?,?,?…) and time>=’2013-01-01 11:00:00′

and time<‘2012-01-01 11:01:00’ group by tag_id

一小时:

select max(time),x,y,tag_id from track_2012_12_13  

where tag_id in (?,?,?…) and time>=’2013-01-01 11:00:00′

and time<‘2012-01-01 12:00:00’ group by tag_id

1.1目标 4

发表评论

电子邮件地址不会被公开。 必填项已用*标注