第9章数据库和应用服务器大小估计.PDFVIP

下载 第9章 数据库和应用服务器大小估计 任何系统开发中最为重要的阶段是预先配置规划。因为在开发时的大小估计阶段要么被 忽略，要么很随意，导致许多系统的维护变成很可怕的事情。假如硬件资源不足以完成任务 的话，那么任何调整都无济于事。本章讨论在调整系统大小时所要考虑的因素以便你能够避 免上述问题。 9.1 预先配置容量规划 被称为预先配置容量规划的这一领域包括很多方面。内存、磁盘和 C P U通常是此设计的 重点，但需要考虑的还有很多。如何在磁盘容错性方面对系统进行构造？此系统会有数据库 驻留在它上面吗？应用程序是驻留在主系统中，还是驻留在别的系统中？ 任何一个大小估计方案都必须提出这个基本问题：系统将被如何使用？有许多不同类型 的工作量。例如，许多信息系统检索数据，但是不允许将数据交互式地写回数据库，这些系 统以批处理方式更新数据库。另一方面，有些交互式的系统或许对数据库执行相同次数的读 写操作。系统完成不同的工作无疑会形成不同的系统配置。本节包含了在任何一个基本的预 先配置容量规划中需要考虑的因素。 9.1.1 事务处理类型 首先要做的一件事情是根据工作量的类型确定你所需要的系统的类型。通常通过确定处 理什么类型的事务来回答此问题。例如，考查一台仅执行数据库操作的服务器，根据它所完 成的工作，我们只需考虑读写操作。事实上，任何一个事务能够被分解为数据库读写或文件 读写。当执行一条 S E L E C T语句或者U P D AT E语句时，数据库服务器将该语句翻译为一连串的 读和写操作。当数据库服务器被分解到这种原子级别时，它主要处理输入 / 输出操作。因此， 你应该选择一个系统，它既能处理所预计的事务类型和容量，又能处理那些事务所产生的输 入/输出。比较起来，假如一个系统将要执行诸如应付帐款的应用操作，它更多地关心一旦获 得所要的数据之后，对这些数据做什么；而不再过多地关心检索出来的基本数据。 这两个系统在执行它们各自的任务时有不同的配置需求。数据库服务器将有一个大型数 据地段用于存储数据和执行输入 /输出操作；反之，应用服务器不需要此数据存储容量。 在任何一种情况下，需要解决的大小估计问题是，将要处理什么类型的事务。两种主要 的事务类型是联机事务处理和决策支持。 1. 联机事务处理( O L A P ) O LT P事务是一个工作单元，因为它实时地或在联机方式下处理数据库，所以它通常被要 求在很短的一段时间内运行。换句话说，许多这样的事务根据最新的可用信息不断地更新数 据库，所以后续的用户可以相信信息是最新的。例如，在一个订单登记系统中，关于存货清 单的所有信息被保存在表中，通过磁盘系统传播出去，数据库是联机的，任何用户可以存取 数据库信息。数据库表，例如 Item Ta b l e或S t o c k _ l e v e l _ Ta b l e，需要含有所卖物品的种类和数 第9章 数据库和应用服务器大小估计 1 1 5 下载 量的最新信息。当收到一张订购一定数量的指定物品的订单时，你可以使用数据库表以查找 该物品现在是否还有以及该物品的库存量，这样可以避免过量卖出物品。 2. 决策支持 第二种类型的事务是决策支持。这样的事务通常很复杂并且是读密集型的，很少发生写 入数据库的操作。一个决策支持系统 ( D S S )通常给管理人员提供信息以帮助他们做出商业决策 —例如，有关企业成长、现有商品库存量水平等的决策。美国空军使用决策支持系统通知 高级管理人员有关喷气式战斗机、轰炸机和人员的当前状态、位置以及武器装备情况。诸如 这样的系统需要一定的特性，例如大规模的处理器能力以及大型的数据库容量。 与O LT P系统不同，D S S 限制花费在处理请求上的时间，而不限制处理器的利用率。的确， 多数D S S 查询需要 1 0 0 ％地利用处理器，直到查询结束。在 O LT P系统中，事务的吞吐量通常 用每秒钟的事务数 ( T P S )或者每分钟的事务数 ( T P M )来衡量，然而在D S S 处理中，事务的吞吐 量通常用每小时的查询量 ( Q P H )来衡量。决策支持强调完成尽可能多的完整查询，而 O LT P系 统强调完成尽可能多的事务—不考虑实际完成了多少查询。