令和3年度 秋期 データベーススペシャリスト試験 午後Ⅰ 問2 カード決済システムの性能見積りとテーブル区分化による改善

【問題の本文・図表】〔参照処理の性能見積り〕および表1「主なテーブルの将来の容量見積り」に基づいて計算します。

「オーソリ履歴」テーブルのアクセス経路は表探索です。表探索では、索引を使わずに先頭ページから順に全行を探索するため、全ページを読み込むことになります。
表1より、「オーソリ履歴」テーブルのページ数は 24億（2,400,000,000） ページです。
したがって、2,400,000,000ページを非同期に読み込むことになります。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (2) および〔参照処理の性能見積り〕の条件に基づいて計算します。

データ入出力は4,000バイトのページ単位で行われます。a（2,400,000,000ページ）を非同期に読み込む場合の総データ量は以下の通りです。
$2,400,000,000 \times 4,000 = 9,600,000,000,000$ バイト

これをM（メガ）バイトに換算します。（$1\text{Mバイト} = 10^6\text{バイト}$）
$9,600,000,000,000 \div 1,000,000 = 9,600,000$ Mバイト

ディスク転送速度は100Mバイト／秒と仮定されているため、データ入出力処理時間は以下のようになります。
$9,600,000 \div 100 = 96,000$ 秒

したがって、データ入出力処理時間は 96,000 秒です。

【問題の本文・図表】〔参照処理の性能見積り〕の条件3と図2のSQL文に基づいて計算します。

図2のSQL文のWHERE句には A.審査結果 = 'Y' と A.利用日 BETWEEN :hv1 AND :hv2（1か月間）が指定されており、これにより抽出される行数が「結果行数」となります。
仮定として、カード数を1,000万枚、カード・月当たり平均オーソリ回数を80回、審査結果が全て可（'Y'）であるとしています。
したがって、1か月間の「オーソリ履歴」テーブルの抽出結果行数は以下のようになります。
$10,000,000 \times 80 = 800,000,000$ 行

したがって、結果行数は 800,000,000 行です。

【問題の本文・図表】〔参照処理の性能見積り〕の条件4に基づいて計算します。

このSQL文は「オーソリ履歴」テーブルを外側、「加盟店」テーブルを内側とする入れ子ループ法で結合されます。
入れ子ループ法では、外側の表の結果行1行ごとに、内側の表を1回探索して読み込みます。
外側の表（オーソリ履歴）の結果行数は、c で求めた 800,000,000 行です。
したがって、内側の「加盟店」テーブルをランダムに合計 800,000,000 回読み込むことになります。

【問題の本文・図表】〔参照処理の性能見積り〕の条件4と5に基づいて計算します。

「加盟店」テーブルへの読み込み回数は合計 800,000,000 回（dの答え）です。
条件5において、「索引はバッファヒット率100%、テーブルはバッファヒット率0%」と仮定されています。これは、索引探索による物理的なI/Oは発生しないが、テーブル行の実データを読み込む際には毎回物理的なI/O（同期読込み）が発生することを意味します。
1回の読み込みにつき「加盟店」テーブルのページを1ページ同期的に読み込むことになるため、読み込み回数と等しい 800,000,000 ページを同期的に読み込むことになります。

【問題の本文・図表】〔参照処理の性能見積り〕の条件5に基づいて計算します。

「加盟店」テーブルの同期読込みページ数は 800,000,000 ページ（eの答え）です。
同期読込みには1ページ当たり1ミリ秒（$0.001$ 秒）掛かると仮定されています。
したがって、同期データ入出力処理時間は以下のようになります。
$800,000,000 \times 0.001 = 800,000$ 秒

したがって、同期データ入出力処理時間は 800,000 秒です。

【問題の本文・図表】〔参照処理の性能見積り〕の条件6に基づいて計算します。

内側の表（加盟店テーブル）の索引探索と結合は、外側の表の結果行1行ごとに実行されるため、合計実行回数は結果行数と同じ 800,000,000 回（cの答え）です。
1結果行当たり0.01ミリ秒（$0.00001$ 秒）のCPU時間が掛かると仮定されています。
したがって、内側の表のCPU時間は以下のようになります。
$800,000,000 \times 0.00001 = 8,000$ 秒

したがって、CPU時間は 8,000 秒です。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (4)(5) および〔参照処理の性能見積り〕の条件7に基づいてSQL全体の処理時間を計算します。

• 外側の表（オーソリ履歴）の処理時間:
  表探索による順次アクセス（非同期データ入出力処理）です。
  SQL処理時間 $＝ \max(CPU時間，非同期データ入出力処理時間)$
  $CPU時間 ＝ 96,000$ 秒、非同期データ入出力処理時間 $＝ 96,000$ 秒（bの答え）より、
  $\max(96,000, 96,000) = 96,000$ 秒となります。

• 内側の表（加盟店）の処理時間:
  索引探索によるランダムアクセス（同期データ入出力処理）です。
  SQL処理時間 $＝ CPU時間 ＋ 同期データ入出力処理時間$
  $CPU時間 ＝ 8,000$ 秒（gの答え）、同期データ入出力処理時間 $＝ 800,000$ 秒（fの答え）より、
  $8,000 + 800,000 = 808,000$ 秒となります。

SQL文全体の処理時間は、これらを合計したものになります。
$96,000 + 808,000 = 904,000$ 秒

したがって、処理時間は 904,000 秒です。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (4) および〔参照処理の性能見積り〕に基づいて説明します。

「加盟店」テーブルは、入れ子ループ法における内側の表であり、主キー索引を用いた索引探索によってランダムアクセスされています。〔RDBMSの主な仕様〕2 (4) にある通り、ランダムアクセスは同期データ入出力処理となります。
同期データ入出力処理では、データI/OとCPU処理が並行して行われないため、物理ディスクへのI/O処理時間がそのまま全体の処理時間の増大に直結します。
データバッファを増やしてヒット率を上げる（案1）ことで、この同期データ入出力（ランダムアクセス）の物理的なI/O回数が削減され、処理時間を短縮することができます。

高得点のポイント

• 「加盟店」テーブルへのアクセス経路が ランダムアクセス（または同期アクセス）であることを明記する。
• データバッファの増加がその処理時間の短縮につながるという論理展開を含める。
• 指定された25字以内の文字数制限を守る。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (5) および〔参照処理の性能見積り〕に基づいて説明します。

「オーソリ履歴」テーブルは表探索による順次アクセスを行っています。表探索では全ページを先頭から1回ずつ読むので、データバッファを増やしてもバッファヒット率は上がらず、順次（非同期）読込みの処理時間は変わりません。
補足として、〔RDBMSの主な仕様〕2 (5) にある通り、順次アクセスは非同期データ入出力処理であり、SQL処理時間は $\max(CPU時間，非同期データ入出力処理時間)$ となります。本見積りにおいて、外側表のCPU時間は96,000秒、非同期データ入出力処理時間も96,000秒です。CPU時間（96,000秒）が律速となるため、全体のSQL処理時間は短縮されません。
そのため、バッファを増やす効果（順次アクセスの処理時間への影響）がないと判断できます。

高得点のポイント

• 「オーソリ履歴」テーブルへのアクセス経路が 順次アクセス（または非同期アクセス）であることを明記する。
• 順次アクセスの特性により、データバッファ増加が全体の処理時間に影響しない（短縮に寄与しない）という論理展開を含める。
• 指定された25字以内の文字数制限を守る。

【問題の本文・図表】〔カード決済システムの概要〕2. オーソリ処理（オンライン処理）の内容に基づいて説明します。

オーソリ処理では、審査結果を判定した後に「“オーソリ履歴”テーブルに挿入する」処理（INSERT）が行われます。
案2では、「利用日列をキーとする副次索引を追加」します。リレーショナルデータベースにおいてテーブルに新しい索引を追加すると、テーブルへ行をINSERTする際に、テーブル本体や主キー索引だけでなく、追加した副次索引に対する更新処理も同時に発生します。
そのため、オーソリ処理（INSERT）時に更新すべき索引データが増加し、書き込みのオーバーヘッドによって処理時間が長くなります。

高得点のポイント

• 副次索引の追加によって、行の挿入時（INSERT時）に更新しなければならない 索引が増える ことを明記する。
• 索引の更新負荷の増加が性能低下の原因であるという因果関係を含める。
• 指定された25字以内の文字数制限を守る。

【問題の本文・図表】〔“オーソリ履歴”テーブルの区分化〕と表2の内容に基づいて説明します。

課題1は「月末近くに起きるオーソリ処理のINSERT文の性能低下を改善すること」です。
案Cは「利用日」を区分キーとするレンジ区分です。月末などの同日に発生する大量のオーソリ処理（INSERT）は、同じ利用日を持つため、特定の1つの区分（当月分の領域）に集中して物理的な書き込みアクセスが競合します。
一方、案A（ハッシュ）や案B（レンジ）の区分キーは「カード番号」です。同じ日に発生するトランザクションであっても、カード番号はランダムにバラバラであるため、INSERTされる行は複数の区分に分散して格納されます。結果として書き込みの局所化（競合）が防がれ、性能が良くなります。

高得点のポイント

• カード番号による区分化（案A、案B）の特性として、挿入される行が 複数の区分に分散する ことを明記する。
• データの分散がアクセスの集中（競合）を防ぎ、性能向上につながるという因果関係を含める。
• 指定された25字以内の文字数制限を守る。

【問題の本文・図表】表2「課題ごとに各案を評価した結果」および図3「区分化に対応したSQL文のWHERE句」に基づいて算出します。

案Cは「利用日」を区分キーとし、「1か月を1区分」とするレンジ区分です。
利用明細抽出処理（課題2）のSQL文（図3）では、A.利用日 BETWEEN :hv1 AND :hv2 と指定されており、ホスト変数 hv1, hv2 は「請求対象月の初日と末日」を表します。
つまり、1回のジョブで探索すべき期間は「特定の1か月間」のみとなります。案Cでは1か月が1区分に割り当てられているため、1ジョブが探索する必要がある区分数は、対象となる該当月の 1 区分のみとなります。

【問題の本文・図表】表1「主なテーブルの将来の容量見積り」と表2の条件に基づいて算出します。

表1より、「オーソリ履歴」テーブル全体のページ数は 24億ページ（2,400,000,000 ページ）です。
〔“オーソリ履歴”テーブルの区分化〕の記載より、「いずれの案も 60 区分に行を均等に分配する前提」となっています。したがって、1区分当たりのページ数は以下の通り均等に計算できます。
$2,400,000,000 \div 60 = 40,000,000$ ページ

ロの欄は、1ジョブが探索する区分数（イの答え＝1）に対応する探索ページ数です。
1区分を探索するため、探索するページ数の最小値は 40,000,000 ページとなります。

【問題の本文・図表】〔RDBMSの主な仕様〕1 (3) の区分方法の説明に基づいて説明します。

案Aは「カード番号」を区分キーとした ハッシュ 区分です。
ハッシュ区分は、RDBMSが区分キーの値からハッシュ関数を用いてハッシュ値を生成し、その値によって格納先の区分を決定します。この方式において、SQL文のWHERE句で カード番号 BETWEEN :hv3 AND :hv4 のように範囲（レンジ）条件を指定した場合、指定された範囲内に存在する個々のキー値がどのハッシュ値になるかを一括して特定することはできません。
そのため、RDBMSは探索する区分を特定の区分に限定（プルーニング）できず、結果的にすべての区分を探索しなければならないため、改善効果が得られません。

高得点のポイント

• ハッシュ区分においては、BETWEEN述語のような範囲指定では 探索する区分を限定できない（全区分を探索する必要がある）ことを明記する。
• ハッシュ区分の特性（ハッシュ値による分散）と範囲検索の不適合性についての因果関係を含める。
• 指定された30字以内の文字数制限を守る。

【問題の本文・図表】〔RDBMSの主な仕様〕1 (4) および課題3の内容に基づいて説明します。

課題3は「月初に行う“オーソリ履歴”テーブル再編成の処理時間を短縮すること」です。
テーブル再編成は、行を主キー順に並び替えたり空き領域を確保したりする重い処理です。案Cでは、「利用日」をキーとしたレンジ区分を採用し、「1か月を1区分」としています。この設計により、前月分の追加・更新データは、直近の1か月分に該当する特定の「1区分」に集中して格納されています。
したがって、月初のメンテナンス時には、データが散らばっている全区分を処理する必要はなく、更新対象となった 1区分だけを再編成すれば良い ため、案Aや案B（カード番号による全区分への分散）に比べて処理時間が大幅に短縮され、効率が良くなります。

高得点のポイント

• 案Cの設計（1か月を1区分）により、再編成の対象が特定の 1区分だけ に限定されることを明記する。
• 再編成対象の範囲が狭まることが、処理時間短縮・効率化につながるという因果関係を含める。
• 指定された20字以内の文字数制限を守る。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (6) および (7) に基づいて説明します。

ジョブを多重化しても更新処理がスケールしない（限界がある）理由は、RDBMSのログバッファおよびログ出力処理の仕組みにあります。
仕様2 (7) には「トランザクションのコミットはログ出力処理の完了まで待たされる」と記載されています。また、仕様2 (6) にあるように、ログバッファはRDBMS内に「一つ」しか存在しません。複数の更新ジョブが同時にコミットを発行しても、最終的に単一のログバッファからディスクへの物理的なログ出力処理が完了するまで各ジョブは待機しなければなりません。このログ出力処理が直列化（逐次化）のボトルネックとなるため、多重度をいくら上げても全体の処理時間を短くできなくなります。

高得点のポイント

• トランザクションのコミット時に ログ出力処理の完了まで待たされる（またはログ出力が逐次化される）というRDBMSの仕様を明記する。
• 単一のログファイル・ログバッファに対するディスクI/Oがボトルネックとなる因果関係を明確にする。
• 指定された30字以内の文字数制限を守る。

【問題の本文・図表】〔RDBMSの主な仕様〕2 (7) に基づいて説明します。

「1,000行更新するごとにコミット」していた処理を、「1行更新するごとにコミット」に変更すると、コミットの発行回数が1,000倍に激増します。
仕様2 (7) に記載されている通り、「トランザクションのコミットはログ出力処理の完了まで待たされる」仕様です。
そのため、コミット回数が増加すると、それに比例してログ出力処理（ディスクI/O）が発生し、その都度発生する 待ち時間の合計が長くなる ため、全体の処理時間が大幅に悪化します。

高得点のポイント

• コミット回数が増えることで、ログ出力処理（または コミット時）の待ち時間が増加することを明記する。
• 本文中の用語（「ログ出力処理」など）を適切に使用している。
• 指定された25字以内の文字数制限を守る。