如何进行分布式大数据应用调优

日期:2014-1-27作者:张亮亮

【TechTarget中国原创】

分布式应用是这样的:它分布在整个企业的一个或多个硬件平台,这些环境通常是与数据库服务器相分离的。而DBA的工作就是监视这些环境并配置和优化数据库服务器以满足多种需求。大数据的出现加剧了DBA的问题,因为现在多个分布式应用需要访问一个非常庞大的数据存储。那么在DB2的环境下,有哪些可用调优的方法呢?我们将在本文中进行详细介绍。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者>更多

张亮亮
张亮亮

TechTarget特邀编辑。毕业于北京邮电大学网络技术研究院。熟悉软件开发测试的各个环节和流程,对操作系统,数据库,计算机网络等有较为深入的理解。现就职于中国电子科技集团公司下属研究所,从事软件研发工作。热衷于英文的学习交流,平时喜欢户外运动,音乐,电影。

DB2数据库性能诊断与调优>更多

相关推荐

技术手册>更多

  • 数据库管理系统选型指南

    理解不同类型的DBMS有哪些特点,以及再何时、何处(场景)使用它们是十分必要的。在这本电子书中,我们就将进行一个详细的介绍,希望能够为您的数据库选型起到帮助、指导作用。

  • SAP HANA实用手册

    在选择SAP HANA的时候,CIO需要关注哪些问题?在产品的选型、实施与上线阶段,都有哪些经验可以借鉴?在本次的TechTarget电子书中,我们将为您一一解读。它也将成为企业选择HANA时,最有实用价值的参考资料。

  • 电子书:如何选择NoSQL数据库

    很多企业关系自己是否应该从传统数据库转到NoSQL数据库,应该选择什么样的数据库?本书详列了相应的技巧和案例,供您参考。

  • 2013数据库工程师薪酬调查报告

    TechTarget数据库网站每两年就会进行一次“数据库工程师薪酬调查”,对不同行业、不同层次的数据库技术从业者的薪酬待遇情况进行一次摸底。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • SOA
  • 虚拟化
  • 服务器
【TechTarget中国原创】

分布式应用是这样的:它分布在整个企业的一个或多个硬件平台,这些环境通常是与数据库服务器相分离的。而DBA的工作就是监视这些环境并配置和优化数据库服务器以满足多种需求。大数据的出现加剧了DBA的问题,因为现在多个分布式应用需要访问一个非常庞大的数据存储。那么在DB2的环境下,有哪些可用调优的方法呢?我们将在本文中进行详细介绍。

DBA必须首先解决常见的应用性能瓶颈。如果数据可用性或性能已经很差,那么面向高性能访问大数据就会出现问题。这里是一份常见的调优问题列表,DBA要确保数据库存在这些流程以减轻这些潜在的问题。

过度加锁

在DB2环境中有两个流程级别可以“存储”数据:SQL流程和数据库工具。SQL流程包括应用程序发布静态SQL语句和动态发布的SQL语句。SQL会发布针对数据的锁,并且这些锁通常会避免数据正在被读取的时候并发更新。此外,加锁会避免诸如Load之类的工具加载数据,这会导致取代或是覆盖正在被读取的数据。

工具会发布针对数据的声明。一条声明类似于数据库锁,是因为它可以通过实体来保留数据以供访问并避免某些并发的SQL访问。一般来说,加锁会强制声明去等待,而声明会强制SQL操作去等待。这就允许数据库管理系统可以管理多个诸如Load或是Image Copy之类的并发工具,而不用受到SQL语句的干扰。

最常见的加锁问题是SQL语句锁定太多的数据。一条SQL语句读取一条记录通常会在此SQL语句执行期间锁定多条记录为只读。这种行为在多个地方是受控的,包括语法,数据库定义,以及通过应用程序提交语句的用法。

DBA应该审查SQL语句加锁行为来确保锁定最小量的数据。了解锁定对象的大小和应用是如何访问数据的。长期运行的应用程序可能会长时间锁定数据,从而降低了数据可用性。考虑记录级别的锁定来最小化SQL的影响,尽管这可能会导致用于管理加锁的CPU时间有所上升。

应用程序提交逻辑同样应该加以审查,提交会释放锁定并允许数据访问。

此外,DBA应该审查应用程序和工具的调度。例如,验证诸如Image Copy这类工具在应用程序做数据库更新的时候没有在并发运行。

数据访问模式的糟糕设计

如果表中某个记录集访问频繁,那么它们便可成为一个“热点”。比如一个按订单号排序的订单表。最近的订单会在它们处理的时候更加活跃。由于多个应用程序和工具访问少量记录,那么数据访问的影响就会集中在数据库中的一个小范围内。当某些事务锁定或声明数据时,而其他应用程序或工具试图对它们进行访问,这通常就会导致性能问题。

这样的热点可以在数据库设计阶段加以预测。DBA可以在数据库中嵌入空白空间来分散数据,这样就降低了在一个物理点活动的集中程度。其他选项包括分配记录到整个数据库的方法。在我们以上的订单表例子中,DBA可能会实现以地理位置进行排序而非按订单号排序的表。这样,新订单就不会彼此相邻,而是分布于整个物理表。

大数据应用调优

大数据通常意味着一个需要高速数据分析软件的大型数据存储。很多时候这些大数据部署与企业数据仓库共存。这意味着DBA人员必须与数据仓库人员进行协作以保证良好的性能。下面提到的一些点需要我们充分考虑:

数据仓库访问优化

最后一点也是最重要的。数据仓库的ETL流程有其自身独特的性能问题。数据提取流程通常会作为多个并行数据查询流程加以执行。数据仓库团队可能会使用高速网络来加速这一流程。由于可操作数据可能不是以易于分析的形式呈现的,因此数据转换需要编程技能。常见问题有空值,缺失或未知数据,甚至是诸如日期值为“99/99/9999”的无效数据。

最后,加载流程通常包括多个针对仓库表并发加载的工具。加载通常是长期运行和资源密集型的。

由于分布式应用试图访问大数据,它们也不可避免的会访问数据仓库数据。再次,DBA必须将此过程与数据仓库ETL过程加以协调。

常见的方法是架设有两个分区的表,活动和非活动分区。目标表物理上被分为数据集和分区。一个分区被指定为活动分区,而一个控制表或参数被设置用来指示哪个分区是活动的。分布式查询现在可能访问活动的数据,允许加载流程把数据加载到非活动分区。一旦加载完毕,活动和非活动标记就会切换。

分布式处理和大数据

优化分布式访问性能的一个最佳实践是使用资源约束分析。DBA会在收集性能数据的时候监视诸如磁盘子系统和CPU之类的资源。甚至查询和工作运行时间也可以被当做是资源。当DBA发现某项资源受限时,他们会平衡其他资源以进行弥补。

例如,考虑一个被多个分布式应用经常查询的大数据存储。DBA可能会确定运行时间(资源#1)太长。一项资源均衡操作可能会添加更多的索引到表中。这样便在加速了查询时间的同时使用了磁盘存储空间(资源#2)。

其他均衡操作包括删除索引,为DB2分配额外内存,增加DB2的排序工作区,查询调优,等等。这些以及其他方法都是记录在DB2性能手册中的。

总结

大数据可能意味着大的性能问题,并且通过分布式应用程序进行访问会将这些问题进一步复杂化。DBA可以通过考虑以下方面来主动了解这些问题:

分布式应用程序对于DBA来说可能会是个挑战。通过解决当前以及潜在的数据可用性问题作为开始,尤其是那些企业数据仓库中的问题。一旦这些担忧得以缓解,那么DBA就可以开始管理对大数据的分布式数据访问。