TPC-C

TPC-C は、 Transaction Processing Performance Council Benchmark Cの略で、オンライン トランザクション処理(OLTP) システムのパフォーマンスを比較するために使用されるベンチマークです。この業界標準は 1992 年 8 月に公開され、最終的には 1995 年に廃止が宣言された以前の TPC-A に取って代わりました。コンピューターのパフォーマンスが数桁向上するにつれて、関連性を保つために多くの変更が行われ、 2021 年現在の最新バージョンは2010 年にリリースされた 5.11 です。2006 年には、より新しい OLTP ベンチマークである TPC-E がスイートに追加されましたが、TPC-C は依然として広く使用されています。 ^{[アップデート]}

TPC-C システムは、単に「会社」と呼ばれる複数の倉庫を持つ卸売業務をモデル化します。最小限のテストでは、会社には 10 の倉庫があり、それぞれに 10 のユーザー ターミナルがあります。各倉庫は 10 の定義された販売地区にサービスを提供しており、各地区には 100,000 アイテムの製品カタログに対して注文する 3,000 人の顧客がいます。最も頻繁に行われるトランザクションは、顧客からの注文 (平均で 10 アイテム) と顧客からの支払いです。頻度の低いリクエストは、注文と倉庫の在庫のステータスの照会、注文の出荷、不足している在庫の補充です。特定のシステムのパフォーマンスをテストするには、目標のパフォーマンス レベルを測定するために必要な最小数を満たすように倉庫の数を増やします。^[1]

ベンチマークの結果は、1 分あたりのトランザクション数(tpmC)で測定されます。最初の tpmC の結果は、1992 年 9 月にIBM AS/400で公開され、54 tpmC という結果が返されました。2000 年代までに、ハイエンド マシンの平均結果は 240 万 tpmC となり、企業は記録を狙って非常に大規模なシステムを構築していました。現在の記録は、2020 年にクラウド コンピューティングを使用して達成されたもので、7 億 730 万 tpmC を達成しました。小規模なオンプレミス システムの最近の結果では、tpmC あたりのコストを引き下げることに重点が置かれています。

IBM はTPC-C を改変し、社内使用のためにCommercial Processing Workloadと呼ばれる簡略化されたバージョンを作成しました。同様の変換は一般的ですが、各社以外ではあまり知られていません。

Oracleのようなリレーショナル データベースのリリースにより、業界内でリレーショナル モデルと古いCODASYLコンセプトの間で議論が起こりました。これらの議論から、現実的なパフォーマンスの見積もりを提供したいという要望が生まれました。1985 年、Tandem ComputersのJim Gray が、現在「Anon et.al.」として知られる論文を共同執筆し、DebitCredit という潜在的な標準の概要を示しました。^[2]

これにより、多くの変更や比較が行われ、その結果、1988 年 6 月に Tom Sawyer と Omri Serlin がシステムを標準化し、新しいバージョンを公開する取り組みが行われました。^[3]このバージョンの公開とその使用に関する継続的な論争により、1988 年 8 月に Transaction Processing Performance Council (TPC) という業界コンソーシアムが設立され、この作業を引き継いで正式な業界標準を作成することになりました。^[4]

TPC は DebitCredit をベースに完全なACIDプロパティを追加した最初の業界標準ベンチマーク TPC-A を作成しました。その他の要件は主に組織に関するもので、結果を提出するにはシステムとテストの完全な詳細を提供する必要があり、サードパーティの監査が推奨され、価格情報には 5 年間の保守契約を含める必要がありました。その後すぐに、関連するベンチマーク TPC-B がリリースされましたが、これは主に端末入力をエミュレートするのではなくバッチ入力を使用するという点で異なっていました。^[5]

TPC-A が完成に近かった頃、Digital Equipment Corporation (DEC) は新しい分散データベースシステム RdbStar の開発に取り組んでいました。このため、新しいデータベース システムのパフォーマンスを測定するための新しいベンチマークが開発されました。RdbStar パフォーマンス チームは、Wisconsin ベンチマーク、AS3AP、Set Query Benchmark など、TPC 以前の既存のベンチマークを多数調査しました。また、DEC のヨーロッパ部門の顧客を調査して、実際のデータベース使用例も調べました。最終的に、オースティンを拠点とするMicroelectronics and Computer Consortiumの未公開のワークロードのコンポーネントを選択しました。このワークロードは、倉庫業務をシミュレートするものでした。チームはこのワークロードを、Order-Entry と呼ばれる独自のベンチマークの基礎として使用しました。^[6]

TPC-B が 1990 年 8 月に公開された時点で、すでに Debit/Credit は単純すぎて、典型的なワークロードをモデル化していないという懸念がありました。11 月には、業界に新しいベンチマークを提供するよう呼びかける新しい取り組みが始まりました。IBMはRAMP-C で応え、DEC は Order-Entry を提案しました。DEC の提案が採用され、その主著者である Francois Raab が標準化の取り組みの技術リーダーに選ばれました。^[6]この取り組みは 18 か月続き、1992 年 8 月 13 日に TPC-C バージョン 1.0 がリリースされました。^[7]

TPC-C ベンチマーク仕様は、その後数年間に数回のマイナー リビジョンを経ました。1993 年 6 月のリビジョン 1.1 では、一部の文言が明確化され、テスト対象システムの顧客側での価格設定が必要になりました。1993 年 10 月のリビジョン 2.0 では、さまざまなレポート要件が変更され、ベンチマーク固有の機能強化を除外する文言が追加されました。1996 年 2 月のリビジョン 3.0 では、トランザクション トラッキング、画像を追加するための新しいフィールド (結局は使用されませんでした)、およびシステム全体の価格から端末が削除されました。この時点で、サーバーのコストが十分に低下し、端末のコストが全体の価格に占める割合が大きくなりすぎていたためです。^[7]

ベンチマークは、クライアントサーバーモデルのような新しいコンピューティングアーキテクチャの出現に対応し、テスト手順の適切な実行と必要なレポートを管理するルールを明確にするために進化し続けました。最も重要な変更は2000年に行われ、メンテナンス価格が5年から3年に、8時間労働5日間（5x8）から24時間労働7日間（7x24）に変更され、測定期間が8時間から2時間に短縮され、アーカイブスペース要件が3分の1に削減されました。これら3つの主要な変更は、2001年2月26日にバージョン5.0としてリリースされました。その後、ベンチマーク仕様で明記されているさまざまな要件の明確化を含むマイナーな変更が行われました。2021年現在^{[アップデート]}、最新の改訂版は2010年2月11日に公開された5.11です。^[8]

新しいベンチマークからの最初の公表結果は、1992年9月に54 tpmCでした。 ^[9]それ以来、TPC-Cの記録は、ムーアの法則にほぼ正確に従って、時間の経過とともに増加しました。最初の結果は数十でしたが、1年後には数百になり、1998年1月には記録は52,871になりました。^[9] 2010年までに、これは百万の範囲に達しました。2000年代には、記録を破るためのコストが大幅に増加したため、記録の数は減少しました。この期間中、Microsoftは新しいTPC-Eベンチマークに目を向け、Oracleに巨大なシステムを構築させ、他の人が追いつけない記録を繰り返し樹立させました。^[10]

この時点以降の記録挑戦は、2010年代後半にクラウドコンピューティングが台頭するまでは比較的少なかった。現在の記録保持者は、アリババを支えるOceanBaseを擁するAnt Financialである。2019年8月、同社は6000万をわずかに上回る記録を樹立したが、これは2013年のOracleの800万という結果以来の試みだった。Oracleの記録は単一のワークステーション上でのものであり、Antの記録には完全なコンピューティングファームが必要だったことを他の人たちはすぐに指摘した。そのような不満を払拭するために、2020年5月にAntは7億700万という新記録を発表した。この記録は今日まで破られていない。^[11]

TPC-C は、DEC が TPC に提示した注文入力ワークロードに基づいています。以前の TPC-A ベンチマークは、単純な借方/貸方簿記システムの操作に一致するデータベース更新に主に焦点を当てていましたが、これは実際の使用パターンには一致しませんでした。実稼働ワークロードのサンプルでは、​​実際のパターンをより適切に表現するには、更新と読み取り専用操作を散りばめたより複雑な挿入の組み合わせが必要であることが示されました。さらに、TPC-A データベースはそれほど複雑ではありませんでした。実際のシステムでは、データがより多くのテーブルに分散され、サイズや複雑さもさまざまでした。^[12]

TPC-C は、合計 9 つのテーブルを持つデータベース スキーマを使用します。構造は主に Warehouse テーブルによって決まります。このテーブルには、W で示される倉庫エントリが多数含まれています。W の最小値は 10 で、W をスケール ファクタとして使用して、テスト対象システムの飽和レベルに合わせて増やす必要があります。報告されるパフォーマンス メトリックは、12.86 x W を超えることはできません。^[1]すべての倉庫は、同じカタログのアイテムの在庫を維持します。Item テーブルには 100,000 行があり、Stock テーブルには W x 100,000 行があります。スキーマの 2 番目のブランチは Districts で、Warehouse ごとに 10 個のエントリがあります。Districts には、District ごとに 3000 人の顧客がいます。顧客は、注文ごとに 5 ～ 15 の注文明細を持つ注文を生成します。つまり、Order-Line は最大のテーブルであり、約 W(倉庫) x 3000 (顧客) x 10 (最初の注文) x 10 (注文明細) = W x 300,000 エントリになります。注文を処理するプロセスは、1 つ以上の倉庫に関連付けられた Stock エントリとやり取りします。^[13]

このアクティビティは、半ランダムな方式に従ってトランザクションを入力する一連の W x 10 仮想端末から構成されます。主要なトランザクションは、1 つの注文を作成する新規注文です。各注文は、1 つの支払いトランザクションと 1 つの配送トランザクションになります。10 個の新規注文トランザクションごとに、1 つの注文ステータス トランザクションと 1 つの在庫レベル トランザクションが生成されます。「リモート ターミナル エミュレーター」(RTE) は、ユーザーのデータ入力、入力の遅延、フィールド間およびトランザクション間の遅延をシミュレートするようにプログラムされています。RTE は、各トランザクションのユーザー要求から完了までの時間(応答時間) も追跡します。1 分間に実行される新規注文トランザクションのレートは、tpmC 値 (1 分あたりのトランザクション数 C) として報告され、ベンチマークの主要なパフォーマンス メトリックを表します。^[12]

初期の結果では、TPC-A と比較して、TPC-C のワークロードはおよそ 10 倍複雑であることが示されました。5 つのトランザクション タイプのうち 1 つ、つまり全体の 44% のみが、1 分あたりのトランザクション数 TPC-C の結果に含まれていますが、TPC-A は 1 秒あたりのトランザクション数で測定され、すべてのトランザクションが含まれています。つまり、秒から分への変換には 60 を掛け、含まれるトランザクションのサブセットには 2.3 を掛けるなど、何らかの変換を行わない限り、2 つの数値を直接比較することはできません。IBM RS/6000モデル 570 という単一のマシンについて考えると、TPC-A は 129 tpsA という値を返しますが、TPC-C は 365.45 tpmC を返します。tpmC に 2.3 を掛け、60 で割って tpsA に変換すると、結果は 13.5 となり、パフォーマンスの差は約 9.5 倍になります。^[14]

TPC-C の結果を提出するには、テストされた構成の詳細な価格の開示も必要であり、これには 3 年間の 24 時間 365 日のハードウェアおよびソフトウェアの保守が含まれます。価格設定されたシステムには、システム自体だけでなく、60 日間にわたって見積もられた tpmC レートでシステムを実行して生成されたデータを保持するための十分なストレージも含まれている必要があります。理論上、tpmC が 1 の場合、履歴に 252 kB、注文に 133 kB、注文明細に 1325 kB のエントリが生成されます。^[15]システムの総価格と測定された tpmC を組み合わせると、価格/パフォーマンス メトリックが生成されます。公開された結果の中には、可能な限り最高の tpmC を生成することを目指したものもありましたが、より多くの公開された結果は、競争力のある価格/パフォーマンス カテゴリでトップの座を目標としており、時には比較的低い tpmC でもありました。^[14]

ベンチマークは通常、主要コンポーネント（データベースシステム、バックエンドサーバーなど）のベンダーによって実行され、システム構成、セットアップ、テストの条件、収集されたすべての結果に関する完全な詳細を含む開示レポートを提出する必要があります。^[16]ベンチマークの実装全体、すべてのテスト手順、測定結果、システムの価格設定、開示レポートは、TPCによって認定された独立監査人によって検証される必要があります。^[17]

• Serlin, Omri ( 1991)。「Debitcredit と TPC の歴史」。データベースおよびトランザクション処理システムのベンチマーク ハンドブック。M . Kaufmann Publishers。pp. 19–38。CiteSeerX 10.1.1.90.6123。ISBN  9781558601598。
• Chen, Yanpei; Raab, Francois; Katz, Randy. TPC-C からビッグ データ ベンチマークへ: 機能的ワークロード モデル。ビッグ データ ベンチマークに関するワークショップ。pp. 28–43。doi : 10.1007 /978-3-642-53974-9_4。
• Nambiar, Raghunath; Poess, Meikel (2011)。「トランザクション パフォーマンスとムーアの法則: 傾向分析」。Lecture Notes in Computer Science。Lecture Notes in Computer Science。Vol. 6417。Springer-Verlag。pp. 110–120。Bibcode : 2011LNCS.6417..110N。doi : 10.1007 /978-3-642-18206-8_9。ISBN 978-3-642-18205-1。
• TPC ベンチマーク C リビジョン 5.11 (PDF) (技術レポート)。トランザクション処理パフォーマンス カウンシル。2010 年 2 月。
• Shanley, Kim (1998 年 2 月)。「TPC の起源と最初の 10 年間」。トランザクション処理パフォーマンス カウンシル。
• Raab, Francois、Kohler, Walt、Shah, Amitabh。「TPC-C ベンチマークの概要、注文入力ベンチマーク」。トランザクション処理パフォーマンス評議会。
• Raab, Francois (1998). Gray, Jim (編). ベンチマーク ハンドブック(PDF) .
• Morgan, Timothy Prickett (2009 年 9 月 29 日)。「TPC がベンチマークの主張に関して Oracle を非難」The Register。
• 「TPC-C」。コックローチラボ。
• Wevers, Lesley; Hofstra, Matthijs; Tammens, Menno; Van Keulen, Maurice (2015 年 1 月)。オンライン非ブロッキング スキーマ変換のベンチマーク。第 4 回データ管理技術およびアプリケーションに関する国際会議。doi :10.5220/0005500202880298 。
• 「OceanBaseがTPC-Cの記録を更新：Ant Financialの専門家との対話」。Alibaba Cloud。2020年6月5日。