IBM决策支持系统(DSS)应用程序处理.doc

IBM决策支持系统（DSS）应用程序处理Jack ParkerArten Technology Group2002 年 4 月 随着相对较新的决策支持系统（DSS）在 UNIX?/RDBMS 领域中的出现，数据库专业人士面临着数十年来大型机编程员一直在解决的问题。我们编写 OLTP 应用程序已经有很长时间了，以致于我们在进入 DSS 领域时头脑里还保留着 OLTP 的那种思维方式和方法。这对于硬件和数据库“不公平”，因为它们有能力把事情做得好得多。 在 OLTP 领域中，我们可能会关心单个用户输入客户订单。我们想确保产品表、订单表以及可能的库存和客户表都被一致更新。如果产品表更新失败，那么只更新订单表以反映产品价格对我们没有任何好处。我们能够知道客户订购了 5.00 美元的商品，但我们不知道是什么货。为了保证正确处理这些更新，我们使用事务来确保一致地执行（或不执行）所有操作。因此我们要特别在意事务日志，以便我们可以重做或撤销工作。我们的数据库软件有专用于支持这种处理方法的完整开销层。我们的思考模式也局限于“事务性方法”。 在 DSS 领域中，我们需要对大量数据执行操作。我们不需要个别用户针对单独行或行集合发出更新操作，而是执行数百万次的插入或更新，或者是甚至几百万次的删除。 如果我们在 DSS 领域中使用事务性方法，那么我们就会作茧自缚。 本文中介绍的技术的最初测试是在带有 16 个处理器、RAM 为 16GB 以及磁盘为 1.2TB 的 Sun 6500 上完成的。最后测试是在 RAM 为 500MB 和磁盘为 40GB 的 Sony 133Mhz PentiumII 上完成的。有趣的是，在排除规模因素后，这两台机器的运行情况类似。读者将在本文中找到有关对记时采用外推法的相应参考资料。可以用算术方法得出这些值，这些值反映了这两台机器的性能。 示例 1：DSS 插入 在最近的一个案例中，我处理了一个用新数据装入 10 亿行表的过程：插入。由于不希望有重复数据，开发人员对该表附上了一个唯一性索引，并以高级方式（在这种方式中，装入的行遵守所有验证标准）使用 IBM Informix(R) Extended Parallel Server(TM)（XPS）并行装入器来拒绝重复。装入过程大约以每小时装入 1 百万行的速度运行。当过程在每个月要插入 1 千多万行时，逻辑日志将溢出并且引擎开始回滚所有插入操作。因为回滚花费在撤销操作上的时间远比原始操作多，所以这意味着回滚要花费另外的 20 至 30 小时。换言之，如果该过程失败，将有 30 到 40 个小时专门花费在这上面。 为什么该方法无效 为了理解为什么该方法很糟，让我们仔细研究一下引擎做些什么： 装入器从输入文件（或多个文件）读取记录。 记录被转换成内部格式（现在我们称之为行）。 执行索引查找操作，以查看该行的索引是否已经存在。因为这是一个大型表而且索引的深度为 6 级，所以这可能意味着每个索引查找操作要读 6 次。 如果未找到索引，则该行被附加到一个有空间的页面上；因此该页面被读取（或者仍可以驻留在上一次插入的缓冲区中）。 这也许意味着对该表分配更多的数据块。 该页面“以前的”映象保留在物理日志中（在任何更改之前） 插入被记录在事务日志中。 通过检查点或者通过前台写操作，定期将这些数据页面存储到磁盘上。 在数据极少的开发环境中，该过程决不会使日志溢出，索引查找操作将快很多而且要插入的行数会比较少。整个过程可能运行 20 到 30 分钟，这是完全可以接受的。直到我们碰到大型表时，才会开始有麻烦。 在事务性方法中，我们想将最新读写的数据保留在缓冲区中，这样不仅可以把写操作组合在一起，从而使写操作更有效，而且被请求的数据通常在该缓冲区中。至此，我们将大量内存分配给这些缓冲区，我们担心最近最少使用（LRU）队列来管理它们。我们正在探索使缓冲区读命中率大于 90%，使高速缓存写比率高于 80%。当我们处理一个很小的行集合时，这很有效；然而，这产生了一层开销，当处理大量行时，开销会使速度慢下来。这层开销有时被称为“缓冲区墙”。 避免“缓冲区墙”：轻型扫描和轻型添加 插入的选通因素是： 我们正设法通过该缓冲区墙插入数据。 我们正在为打算插入的每一行进行索引查找操作。 如果我们能够以某种方式使这些操作加速或者避免这些操作，则可以更快地移动数据。 幸运的是，有轻型扫描和轻型添加特性。在轻型扫描中，从表读取的数据存储在其自己的专用缓冲池中，根据这个条件，将不需要为进一步的操作保留该数据。有一个内在含意：将读取整个表或者至少表的一整段。使用轻型扫描，引擎不会使缓冲池中填满大型表内容，避免了缓冲区管理的开销。轻型扫描的速度明显快于传统扫描。 轻型添加以相似的方式起作用，