2021年(R3)秋 データベーススペシャリスト 感想戦② (午後Ⅰ 問2)
こんにちは。
第一弾
2021年(R3)秋 データベーススペシャリスト 感想戦① (午後Ⅱ 問1)｜もばた｜note
に続き、午後Ⅰもとき直し・感想戦を勝手に書きなぐっていこうと思います。
0．本文
某私立大学のキャンパスで華の大学院生気分を味わいつつ迎えた午後Ⅰ。いつも通り午後Ⅰを開いてみると、DBパフォーマンスか～ということでうまくいけばいいなあと読み始める。
１. 設問1
1.1 設問1(1)
過去問でもよく見る時間や容量の見積もり。実際の所、要件をうまくつかめず結構長考していた気がする。
a。出ました入れ子ループ法。てかオーソリ履歴TBLが表探索って端的に言って遅そう。24億ページ。多いい。
ミック先生も「「駆動表の小さなNested Loops」+「内部表の結合キーにインデックス」。この組み合わせは、SQlチューニングにおける基本中の基本です。麻雀の役で言うところの「ピンフ」+「タンヤオ」みたいなものです」(ミック著 「SQL実践入門」P182 技術評論社 2015)
と言っていた通り、ここの処理対象行をいかに少なくしていくのかな、という感じ。その理屈で言うとわたしはSQLチューニングにおいてはたぶん役牌くらいしかわかってないですね。
b。480億(行)×200(バイト)÷100M(バイト/秒)ということで、96000。
c。1000万×80=8億。個人利用者じゃなくて加盟店にとっての明細。
d。オーソリ履歴TBLの結果行(8億行)一つ一つに対し、加盟店TBLをインデックススキャンで照合。
e。結局索引には引っかかって場所が分かっても、TBLのデータはI/Oが発生するので、8億回I/Oが発生
f。8億行×1ミリ秒で、80万秒。
g。8億行×0.01ミリ秒で、8000秒。
h。80万+9万6000+8000=904000。たぶんあってた気がする。
1.2 設問1(2)
データバッファの話。
・加盟店TBL: 索引には引っかかるけど、テーブルデータ取得でI/Oが発生するのでその時間を短縮するため的なことを書いた。
・オーソリ履歴：あまりよく分かっていない。表探索で結局I/Oが発生するから的なことを言ってた気がする。
冷静に読み返すと、オーソリ履歴TBLは表探索で、非同期に入出力ということで順次読み込み。この場合は、CPU・I/O同時並行なのでどちらかの大きい方が処理時間。本文16Pにある通り、入出力時間が96000秒より短くなっても、結局CPU処理で96000秒かかると。はい。たぶん不正解だった。
1.3 設問1(3)
言われてみたら当然な感じがする。行の追加・更新・削除時にインデックスも更新走ってるということで。インデックス増やせばその分TBLデータ変更時にインデックスに走る処理も増えるよねと。書けたかはあまり自信がない。
２．設問2
2.1 設問2(1)
カード番号で区分するとオーソリ処理のINSERTが早い理由。なんとなくわかるけど言葉にしづらかった。対象が複数の区分に分かれてて並行して処理できるから的な事を書いた気がする。
2.2 設問2(2)
案Cの利用日で区分した時、1か月の利用明細抽出にかかるコストの理想値を試算。ジョブ当たり1区分の、24億÷60の4000万行。
2.3 設問2(3)
区分キーがハッシュ化されていて探索する区分を特定できないから的な事を書いた気がする。それはそう。よくわかってないけど、ハッシュを元値に戻せないなら、間の値どないして出す年という話?(応用情報なみの発想。)
2.4 設問2(4)
案Cは利用日で区分してるので、あるひと月にかかる追加も一つの区分に集中する。主キー索引(カード№・利用日・連番)がB木のイメージで連なってるとすると、お尻の方だけ更新すればいいのかな。あまり具体的にはわかっていない。
３．設問3
3.1 設問3(1)
本文P15(6)にログバッファは1つとありますね。並列してないと。なので、DBのコミットは結局1つしかないログバッファがボトルネックになって待ち時間が増えるよと。それっぽいことを書いた気がする。
3.2 設問3(2)
自信がない。たしか、ログ出力待ちを行う回数が増えた的な事を書いた気がする。1行ごとにコミット×1000回にかかる時間>1000行の更新を一回でコミットする時間という前提なのかな。たぶんそうなんだろうけど、よくわかっていないコンピューター弱者。
４．感想。
後出しだとこう薬のように理屈をいくらでもつけられるけど、実際の所あっぷあっぷだった。データベースもコンピューターである、という前提のもとに立ってFE・APの勉強をしっかりして基礎理論をある程度想像できるようになるなり、DBの物理構造の本読むなりなんなりしないと歯が立たないですね。