1. Introduction（4）
Example 1.2.
Now we consider an index on the high insert volume History table, and demonstrate that such an index essentially doubles the disk cost for the TPC application.
现在，我们考虑一个高插入量History表上的索引，并演示这样的索引实际上使TPC应用程序的磁盘成本增加了一倍。（有道翻译）
An index on "Account-ID concatenated with Timestamp" (Acct-ID||Timestamp) for the History table is crucial to support efficient queries on recent account activity such as:
History表的“account - id连在一起的Timestamp”(Acct-ID||Timestamp)上的索引对于支持对最近帐户活动的有效查询至关重要，例如:（有道翻译）
(1.1) Select * from History
where History.Acct-ID = %custacctid
and History.Timestamp > %custdatetime;
If an Acct-ID||Timestamp index is not present, such a query requires a direct search of all rows of the History table, and thus becomes impractical. An index on Acct-ID alone provides most of the benefit, but cost considerations that follow don't change if the Timestamp is left out, so we assume here the more useful concatenated index. What resources are required to maintain such a secondary B-tree index in real time? We see that the entries in the B-tree are generated 1000 per second, and assuming a 20 day period of accumulation, with eight hour days and 16 byte index entries, this implies 576,000,000 entries on 9.2 GBytes of disk, or about 2.3 million pages needed on the index leaf level, even if there is no wasted space. Since transac- tional Acct-ID values are randomly chosen, each transaction will require at least one page read from this index, and in the steady state a page write as well. By the Five Minute Rule these index pages will not be buffer resident (disk page reads about 2300 seconds apart), so all I/Os are to disk. This addition of 2000 I/Os per second to the 2000 I/Os already needed for updating the Account table, requires a purchase of an additional 50 disk arms, doubling our disk require- ments. The figure optimistically assumes that deletes needed to keep the log file index only 20 days in length can be performed as a batch job during slack use times.
如果没有Acct-ID||Timestamp索引，这样的查询需要直接搜索History表的所有行，因此变得不切实际。单独在Acct-ID上的索引提供了大部分好处，但是如果忽略了Timestamp，随之而来的成本考虑不会改变，所以我们在这里假设更有用的连接索引。需要哪些资源来实时维护这样一个二级b -树索引?我们看到,b - tree中的条目生成1000每秒,假设一个20天内的积累,有八个小时和16字节索引条目,这意味着576000000条目9.2 gb的磁盘,或约230万页需要索引叶水平,即使没有浪费空间。由于事务性的Acct-ID值是随机选择的，因此每个事务至少需要从该索引读取一个页面，在稳定状态下还需要写入一个页面。根据五分钟规则，这些索引页不会驻留在缓冲区(磁盘页读取间隔约为2300秒)，因此所有I/ o都指向磁盘。在更新Account表已经需要的每秒2000 I/ o的基础上再增加2000 I/ o，需要额外购买50个磁盘臂，使磁盘需求增加一倍。该图乐观地假设，在空闲使用时间内，可以以批处理作业的形式执行保持日志文件索引长度仅为20天所需的删除操作。（有道翻译）
todo：自己翻译
