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

分布式应用是这样的：它分布在整个企业的一个或多个硬件平台，这些环境通常是与数据库服务器相分离的。而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人员必须与数据仓库人员进行协作以保证良好的性能。下面提到的一些点需要我们充分考虑：

·存储于非常大的DB2表中的大数据可能会有特殊的恢复需求。考虑一个要每天进行分析的事务数据的大型存储。业务管理者可能会认为此分析对日常生产至关重要，从而指定此数据为关键任务。如果发生故障，这些数据要怎样才能恢复呢？对于一个数据仓库最佳的做法就是指定数据在恢复上为低优先级的。

·存储在DB2表中的大数据可能需要DBA去降低或是最小化数据上索引的数量。虽然通常来说可以添加多个索引到一个表来改善查询性能，而对于非常大的表其索引也会很大。磁盘存储限制可能会阻止DBA创建某些索引。此外，更多的索引会减缓数据插入性能，同样还会让任何数据库恢复过程运行更长的时间。

·置于一个专门的软硬件一体化设备中的大数据必须经常由数据仓库表同时进行访问。这通常是利用SQL连接语句加以实现的。DBA必须协调大数据设备的加载和数据仓库的ETL流程以确保所有数据在查询阶段是可用的。