OLTP环境中,有使用mysql 分区表 坑性能有较大提升的吗

博客访问: 4320946
博文数量: 675
博客积分: 10821
博客等级: 上将
技术积分: 11391
注册时间:
认证徽章:
专注与操作系统相关的云计算,linux,openstack,spark, hadoop
IT168企业级官微
微信号:IT168qiye
系统架构师大会
微信号:SACC2013
分类: Oracle
OLTP&系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作;
OLAP&系统则强调数据分析,强调执行市场,强调磁盘,强调分区等。
之间的比较:
&&&&&&&&&&&&&&&&&&& &&&&&&
),表示事务性非常高的系统以及的数量。在这样的系统中,单个数据库每秒处理的往往超过几百个,或者是几千个,语句的执行量每秒几千甚至几万个。典型的系统有电子商务系统、银行、证券等,如美国的业务数据库,就是很典型的数据库。
与磁盘子系统。
(1)等的频繁使用,也会消耗大量的时间,造成系统的负载升高,正确的设计方法或者是优化方法,需要尽量避免计算过程,如保存计算结果到统计表就是一个好的方法。
(2)环境中,它的承载能力一般取决于它的处理能力.&环境中,磁盘物理读一般都是,也就是单块读,但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其的时候,就会出现大的性能问题。
技术与索引技术,决定了很多语句不需要从磁盘子系统获得数据,与对系统是很重要的。另外,在索引使用方面,语句越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少表关联,尽量减少分布式事务,基本不使用分区技术、技术、并行技术及位图索引。因为并发量很高,批量更新时要分批快速提交,以避免阻塞的发生。
OLTP&系统是一个数据块变化非常频繁,语句提交非常频繁的系统。&对于数据块来说,应尽可能让数据块保存在内存当中,对于来说,尽可能使用变量绑定技术来达到重用,减少物理和重复的解析,从而极大的改善数据库的性能。&
这里影响性能除了绑定变量,还有可能是热快()。&当一个块被多个用户同时读取时,为了维护数据的一致性,需要使用来串行化用户的操作。当一个用户获得了后,其他用户就只能等待,获取这个数据块的用户越多,等待就越明显。&这就是热快的问题。&这种热快可能是数据块,也可能是回滚端块。&对于数据块来讲,通常是数据库的数据分布不均匀导致,如果是索引的数据块,可以考虑创建反向所以来达到重新分布数据的目的,对于回滚段数据块,可以适当多增加几个回滚段来避免这种争用。&
)系统,有的时候也叫决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,的流量。
基本是没有效果的,数据库的读写类型基本上是与。应尽量采用个数比较多的磁盘以及比较大的带宽,如的光纤接口。
系统中,常使用分区技术、并行技术。
分区技术在OLAP系统中的重要性主要体现在数据库管理上,比如数据库加载,可以通过分区交换的方式实现,备份可以通过备份分区表空间实现,删除数据可以通过分区进行删除,至于分区在性能上的影响,它。总之,分区主要的功能是管理上的方便性,它并不能绝对保证查询性能的提高,有时候分区会带来性能上的提高,有时候会降低。
中,与结合实现多节点的同时扫描,效果也非常不错,可把一个任务,如的全表扫描,平均地分派到多个的节点上去。
系统中,不需要使用绑定()变量中可以大量使用位图索引,物化视图,对于大的事务,尽量寻求速度上的优化,没有必要像要求快速提交,甚至要刻意减慢执行的速度。
绑定变量真正的用途是在系统中,这个系统通常有这样的特点,用户并发数很大,用户的请求十分密集,并且这些请求的大多数是可以重复使用的。
对于系统来说,绝大多数时候数据库上运行着的是报表作业,执行基本上是聚合类的操作,比如,这时候,把优化器模式设置为是恰当的。&而对于一些分页操作比较多的网站类数据库,设置为会更好一些。&但有时候对于系统,我们又有分页的情况下,我们可以考虑在每条中用。&如:
Select&/*+first_rows(10)&*/&a.*&from&table&a;
环境中,不要盲目地把的技术拿过来用。
条件,那么,如果是本地索引,将不得不扫描多个索引,而性能变得更为低下。如果是全局索引,又失去分区的意义。
环境中,很容易造成阻塞与死锁。但是,在环境中,可能会因为其特有的特性,提高的查询速度。也是基本一样,包括触发器等,在频繁的系统上,很容易成为瓶颈,甚至是等待,而在环境上,则可能会因为使用恰当而提高查询速度。
对于系统,在内存上可优化的余地很小,增加处理速度和磁盘速度是最直接的提高数据库性能的方法,当然这也意味着系统成本的增加。
比如我们要对几亿条或者几十亿条数据进行聚合处理,这种海量的数据,全部放在内存中操作是很难的,同时也没有必要,因为这些数据快很少重用,缓存起来也没有实际意义,而且还会造成物理相当大。&所以这种系统的瓶颈往往是磁盘上面的。
对于系统,的优化非常重要,因为它的数据量很大,做全表扫描和索引对性能上来说差异是非常大的。
在Oracle数据库系统中,很多人没有弄清楚自己的业务类型到底是什么,就在开始盲目的寻求优化方法,而往往是把OLAP的方法使用在OLTP上,或者是OLTP的方法使用在OLAP上。这样的使用,有的时候,对性能没有任何的提高,甚至是大大的影响了性能,得到适得其反的效果。所以,在优化系统之前,弄清楚自己的业务类型。
1、什么是OLTP
OLTP,也叫联机事务处理(Online Transaction Processing),表示事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的transaction以及execute sql的数量。在这样的系统中,每秒处理的transaction往往超过几百个,或者是几千个,select 语句的执行量每秒几千甚至几万个。典型的OLTP系统如电子商务系统,银行,证卷等等,如美国ebay的业务数据库,就是很典型的OLTP数据库。
OLTP系统最容易出现的瓶颈就是CPU与磁盘子系统。cpu则取决于逻辑读以及内部调用,如函数等等。一个执行频繁的SQL语句,如果每个语句可以减少很少的逻辑读,也相当于优化了一些逻辑读很差的大型语句。很多人不感觉不到这里的作用,觉得一个语句几十个逻辑读,执行时间基本为0,就不需要优化了,其实,只要他的执行次数非常频繁,而且有优化的余地,就一定要优化,如减少一定的逻辑读或者降低执行次数,都是优化方法。
另外,一些计算性的函数,如sum,count,decode被非常频繁的使用,也是非常消耗cpu的,我遇到一个系统,因为一个sql语句,大量的使用了sum与decode进行行列转换,结果这一个语句就耗费了整个机器一半以上的CPU。
那么,在一般的OLTP系统中,如果不考虑我上面说的函数问题,那么,逻辑读乘以执行次数,决定了cpu的消耗程度,如一个语句,每秒执行次数为500次,每个逻辑读为15,但是,通过优化,能让每个语句的逻辑读从15降到10,那么,每秒的逻辑读就可以减少500*5=2500个,其实就是相当于优化了一个执行频率为每秒1次,每次逻辑读为2500个的语句(注意,2500个逻辑读,在oltp系统是非常差的语句)。再如,假定一个1GHZ的cpu每秒能正常处理的逻辑读是100,000个,如果是10个逻辑读一个的语句,每秒可以处理10,000个,而1000个逻辑读一个的语句,每秒则只能处理100个。
同以上道理,物理读乘以执行次数,则决定了存储子系统的处理能力,在一个OLTP环境中,物理读一般都是db file sequential read决定的,也就是单块读,一个典型的OLTP系统,db file sequential read应当基本等于磁盘子系统的读的IOPS。而磁盘子系统的IOPS处理能力,与cache命中率以及磁盘个数有很大的关系。我的一些文章中,也分析到了这些问题,如一个15K转速的磁盘,每秒最多能处理的iops达到150个,基本就是极限了,如果cache不命中,那么100个磁盘,最多能处理的IOPS仅仅是15000个(但是,实际上,还基本达不到这个值)。
OLTP最常用的技术就是cache技术与btree索引,cache决定了很多语句不需要从磁盘子系统获得数据,所以,web cache与oracle data buffer对OLTP系统是很重要的。另外,在索引使用方面,语句是越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少关联。其它方面,基本不使用分区技术,MV技术,并行技术以及位图索引,因为并发量很高,批量更新可能要尽量快速提交避免阻塞的发生。
在ebay的数据库设计中,有一个很重要的点就是,数据库只负责存放数据,业务逻辑尽量在业务层实现,因为数据库扩展是困难的,而应用服务器扩展是简单的。其实,也就是说,在高可用的OLTP环境中,数据库使用越简单的功能越好。
2、什么是OLAP
OLAP,也叫联机分析(Online Analytical Processing),有的时候也叫DSS决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一个语句的执行时间可能会非常长,读取的数据也非常多。所以,这样的系统中,考核的标准往往决定于磁盘子系统的吞吐量。
磁盘子系统的吞吐量则直接取决于磁盘的个数,这个时候,cache基本是没有效果的,这个时候数据库的读写基本上是db file scattered read与direct path read/write。在我前面的一些文章中描述过,如果一个15K的磁盘的IO量每秒13M,那么,100个磁盘,最多能提供的吞吐量则是1300M/s(实际上,也基本达不到这个值)。如果磁盘个数足够的话,还需要考虑采用比较大的带宽,如4GB的光纤接口。
在OLAP系统中,常使用的技术有分区技术,并行技术。如分区技术可以使得一些大表的扫描变得很快(只扫描单个分区),而且方便管理。另外,如果分区结合并行的话,也可以使得整个表的扫描也会变得很快。并行技术除了与分区技术结合外,在oracle 10g中,与rac结合实现多节点的同时扫描,效果也非常不错,把一个任务,如select的全表扫描,平均的分派到多个rac的节点上去。
在OLAP系统中,不需要使用绑定变量,因为整个系统的执行量很少,分析时间对于执行时间来说,可以忽略,而且避免出现错误的执行计划。但是OLAP中可以大量使用位图索引,物化视图,对于大的事务,尽量的寻求速度上的优化,没有必要象OLTP需要快速提交,甚至要刻意减慢执行的速度。
特别是在高可用的OLTP环境中,不要盲目的把OLAP的技术拿过来用,如分区技术,如果不是大范围的使用了分区关键字作为where条件,而采用其它的字段作为where条件,那么,如果是本地索引,你将不得不扫描多个索引,而性能变的更为低下。如果是全局索引,那分区的意义又何在,只是多出一份分区技术的license而已。
并行技术也是如此,一般是在大型任务的时候才使用,好比说,实际生活中,一个比较大型的工作,如翻译一本书,你可以先安排多个人,每个人翻译不同的章节,这样是可以提高翻译速度,但是,你现在只是翻译一页,你也去分配不同的人翻译不同的行,再组合起来,这个时间,你一个人或者早就翻译完了。
位图索引在我前几篇文章中有交代,如果用在oltp环境中,可能因为阻塞范围太大,很容易阻塞与死锁,但是,在olap环境中,可能会因为其特有的特性,提高olap的查询速度。mv也是基本一样,包括触发器等等,在dml频繁的oltp系统上,很容易成为瓶颈,而在olap环境上,则可能会因为使用恰当而提高查询速度。
更多的差别与技术,细说下来太多了,有些东西,是要靠大家慢慢去体会的,我这里也就不多说了,大家可以平常在自己的业务中多多体会。
阅读(9184) | 评论(1) | 转发(6) |
给主人留下些什么吧!~~
很好的文章,学习了!
请登录后评论。80被浏览6,568分享邀请回答0添加评论分享收藏感谢收起3添加评论分享收藏感谢收起MySQL数据库的性能的影响分析及其优化
1.网络和I/O资源 2.cpu的主频和核心的数量的选择 (对于密集型的应用应该优先考虑主频高的cpu) (对于并发量大的应用优先考虑的多核的cpu) 3.磁盘的配置和选择 (使用传统的机械硬盘: 特点:读写较慢、存储空间大、最常见、使用最多、价格低; 工作过程:移动磁头到磁盘表面上的正确位置; 等待磁盘的旋转,使得所得所需的数据在磁头之下; 等待磁盘旋转过去,所有所需的数据都被磁头读出 选择因素:存储容量、传输速度、访问时间、主轴转速、物理尺寸) (使用RAID增强传统的机器硬盘的性能: 特点:利用小的磁盘组成大的磁盘并提供数据的冗余保证数据的完整性的技术 数据库中所使用的RAID的级别: RAID0级别、RAID1级别、RAID5级别[分布式奇偶校验磁盘阵列]、RAID10[分片的镜像(数据库最好的方式)] RAID级别选择:如下图) (使用固态存储的SSD和PCI-E卡: 特点:相对于机械盘固态磁盘有更好的随机读写性能; 相对于机械固态磁盘能更好的支持并发; 相对于机械固态磁盘更容易损坏 SSD:使用SATA接口可以替换传统的磁盘而不需要任何的改变[受到接口的速度的限制]; SATA接口的SSD同样支持RAID技术 PCI-E卡(Fusion-IO卡):无法使用在SATA接口[需要使用独特的驱动和配置]; 价格贵,使用了cpu的资源和内存 使用的场景:适用于存在大量的随机I/O的场景; 适用于解决单线程负载的I/O瓶颈) (使用网络存储NAS和SAN: SAN[光纤接入服务器]:大量顺序读写操作、读写I/O、缓存、I/O合并、随机读写慢(不如本地的RAID) NAS设备使用网络连接,基于文件的协议如NFS或者SMB来访问 适合场景:数据库的备份、)
使用RAID增强传统的机器硬盘的性能-&RAID0级别
使用RAID增强传统的机器硬盘的性能-&RAID1级别
使用RAID增强传统的机器硬盘的性能-&RAID5级别
不同REAID级别的对比:
注意事项:
1.64位数据库的版本使用32位的服务器的版本 2.内存的主频的选择主板所能支持的最大内存的频率 总结: 对于cpu: 1.64位的cpu一定能够要工作在64位的系统下 2.对于并发比较高的场景cpu的数量比频率重要 3.对于cpu密集型的场景和复杂SQL则频率越高越好 对于内存: 1.选择主板所能使用的最高频率的内存 2.内存的大小对性能很重要,所以尽可能的大 I/O子系统: 1.PCIe -& SSD -& RAID10 -& 磁盘 -& SAN 2). 操作系统对性能的影响 Windows、FreeBSD、Solaris、Linuxcentos的参数优化的设置: (1)内核相关的参数(/etc/sysctl.conf) net.core.somaxconn = 65535 net.core.netdev_max_backlog = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.core.wmem_defaullt = 87380 net.core.wmem_max =
net.core.rmem_defaullt = 87380 net.core.rmem_max =
net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 3 kernel.shmmax =
vm.swappiness = 0 (2)增加资源限制(/etc/security/limit.conf) * soft nofile 65535 * hard nofile 65535 * 表示对所有的用户有效 soft 指的是当前系统的生效的设置 hard 表明系统中所能设定的最大值 nofile 表示所限制的资源是打开文件的最大数目 65535 就是限制的数量 (3).磁盘调度策略(/sys/block/devname/queue/scheduler) noop(电梯式调度策略)、deadline(截止时间调度策略)、anticipatory(预料I/O调度策略) cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] echo deadline & /sys/block/sda/queue/scheduler 3).MySQl的数据库的体系
MySQl的数据库的体系 4).MySQl的数据库的存储引擎 (1).Mysql之存储引擎MyISAM 组成的结构:表为MYD和MYI、frm的文件组成 特性:并发性和锁级别 MyISAM表支持索引类型 MyISAM表支持数据的压缩(命令行:myisampack) myisampack -b -f myIsam.MYI; 压缩后的表不能进行写操作,只能进行读操作 修复:对数据库中的表进行检查并修复:
myisamchk工具,修复时数据库服务必须停止 限制:使用MySQL5.0之前时默认表的大小4G(存储大表修改MAX_Rows和AVG_ROW_LENGTH) 使用MySQL5.0之后的版本默认支持256TB 适用的场景:非事务型的应用 只读类的应用 空间类的应用(GPS的数据)(2).Mysql之存储引擎InnoDB mysql5.5.8之后版本默认使用的存储引擎 组成结构:通过设置innodb_file_per_table参数存储的位置不同 ON:独立表空间:tablename.ibd OFF:系统表空间:ibdataX 建议:对于mysql中建议使用InnoDB的独立表空间 特性:事务性存储引擎 完全支持事务的存储引擎 Redo log(存储已经提交的事务)和Undo log(存储未提交的事务) InnoDB支持行级别锁 最大程序的支持并发 行级别的锁是由存储引擎层实现的 锁:共享锁(读锁)、独占锁(写锁) 表级锁、行级锁 阻塞:确保事务并发的正常的执行 死锁:两个或者两个以上的事务执行过程中相互等待对方的资源而产生的一种异常 InnoDB状态检查: show
适用场景:InooDB适用于大多数OLTP应用(3).Mysql之存储引擎CSV 特点:数据以文本的方式存储在文件中 .CSV文件存储表的内容 .CSM文件存储表的元数据如表的状态和数据量 .frm文件存储表的结构的信息 以CSV格式进行数据的存储 所有的列必须不能为NULL的 不支持索引(不适合大表,不适合在线处理) 可以对数据文件直接进行编辑 适用的场景:适合作为数据交换的中间表 mysql数据目录-&csv文件-&其他web程序 excel电子表格 -& csv文件 -& mysql数据目录(4).Mysql之存储引擎Archive 特点:以zlib对表数据进行压缩,磁盘I/O更少 数据存储在ARZ为后缀的文件中 只支持insert和select操作 只支持在自增的ID列上加索引 适用场景: 日志和数据采集类的应用(4).Mysql之存储引擎Memory 特点:数据只保存在内存中 Memory存储引擎的I/O效率特别高 支持HASH索引和BTree索引 所有的字段为固定长度 不支持BLOG和TEXT等大字段 Memory存储引擎使用表级锁 表中存储数据的最大值由max_heap_table_size参数决定 适用场景:用于查找或者映射表,例如邮编和地区 用于保存数据分析产生的中间表 用于缓存周期性聚合数据的结果表 5).MySQl的数据库的服务器参数 (1).Mysql配置参数作用域 全局参数 set global 参数名=参数值; set @@global.参数名:=参数值; 会话参数 set[session] 参数名=参数值; set @@session.参数名:=参数值;(2).内存配置相关的参数 确定可以使用的内存的上限 确定MySQL的每个连接使用的内存 sort_buffer_size join_buffer_size read_buffer_size read_rnd_buffer_size 确定需要为操作系统保留多少内存 如何为缓存池分配内存 Innodb_buffer_pool_size 总内存-(每个线程锁需要的内存*连接数)- 系统的保留内存 key_buffer_size(3).I/O相关配置参数 InnoDb存储引擎的I/O参数设置: Innodb_log_file_size Innodb_log_file_in_group Innodb_log_buffer_size Innodb_flush_log_at_trx_commit Innodb_flush_method = O_DIRECT Innodb_file_per_table = 1 Innodb_doublewrite = 1 MySIAM存储引擎的I/O参数设置: delay_key_write OFF:每次操作后刷新键缓冲中的脏块到磁盘 ON:只对在键表时指定了delay_key_write选项的表使用延迟刷新 ALL:对所有MYSIAM表都使用延迟键写入(4).安全相关配置参数 expire_logs_days 指定自动清理binlog的天数 max_allowed_packet 控制MySQL可以接受的包的大小(32M) skip_name_resolve 禁用DNS查找 sysdate_is_now 确保sysdate()返回确定性的日期 read_only 禁止非super权限的用户写权限 skip_slave_start 禁止Slave自动恢复 sql_mode 设置MySQL所使用的SQL模式 strict_trans_tables no_engine_subtitutoion no_zero_date no_zero_in_date only_full_group_by(5).其他相关配置参数 sync_binlog = 1控制MySQL如何向磁盘刷新binlog tmp_table_size和max_heap_table_size 控制内存临时表的大小(设置一致) max_connections = 2000 控制允许的最大连接数 5).MySQl的数据库的结构设计和SQL的优化 (1).过分的反范式化为表的建立太多的列(2).过分的范式化造成太多的表关联(3).在OLTP环境中使用不恰当的分区表(4).使用外键保证数据的完整性 性能优化的顺序
数据库结构设计和SQL语句优化
数据库的存储引擎的选择和参数的配置
系统的选择及其优化
责任编辑:
声明:本文由入驻搜狐号的作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。
今日搜狐热点Oracle数据库性能优化盖国强冯春培叶 - 爱问共享资料
OracleDatabasePerformanceTuning.pdf
OracleDatabasePerformanceTuning.pdf
OracleDatabasePerformanceTuning…
简介:本文档为《OracleDatabasePerformanceTuningpdf》,可适用于IT/计算机领域,主题内容包含Oracle数据库性能优化盖国强冯春培叶梁冯大辉编著人民邮电出版社图书在版编目(CIP)数据Oracle数据库性能优化/盖国强等编著.北京:人民邮电符等。
侵权或盗版
*若权利人发现爱问平台上用户上传内容侵犯了其作品的信息网络传播权等合法权益时,请按照平台要求书面通知爱问!
赌博犯罪类
在此可输入您对该资料的评论~
添加成功至
资料评价:

我要回帖

更多关于 hive 分区表 的文章

 

随机推荐