R3 午後1 問2 設問1
DB見習いさん
(No.1)
令和3年午後1問2の設問1について、2つ質問があります。
①
(2)のオーソリ履歴について、バッファの仕組みへの理解がまだ甘く、合点がいってないところがあります。この問はおそらく「表探索では、索引を使わずに先頭ページから順に全行を探索する」というところが解答の肝だと思うのですが、全行探索というのはバッファは一切見ずにディスクを見に行くというものなのでしょうか。順次アクセスだろうが索引探索でなかろうが、バッファにデータがありそれを見に行けばアクセスは速くなるので処理時間に影響はあるのではないか?と思いました。
②
(3)について、索引についての質問になるのですが、自分は解答を「行の挿入時に利用日列の副次索引が作られるから」としました。模範解答は「索引が更新されるから」となっていますが、新しい利用日の行ができた瞬間、索引は「作成」されるのではなく「更新」されるのでしょうか。それとも、特にどちらでも問題ないのでしょうか。
①
(2)のオーソリ履歴について、バッファの仕組みへの理解がまだ甘く、合点がいってないところがあります。この問はおそらく「表探索では、索引を使わずに先頭ページから順に全行を探索する」というところが解答の肝だと思うのですが、全行探索というのはバッファは一切見ずにディスクを見に行くというものなのでしょうか。順次アクセスだろうが索引探索でなかろうが、バッファにデータがありそれを見に行けばアクセスは速くなるので処理時間に影響はあるのではないか?と思いました。
②
(3)について、索引についての質問になるのですが、自分は解答を「行の挿入時に利用日列の副次索引が作られるから」としました。模範解答は「索引が更新されるから」となっていますが、新しい利用日の行ができた瞬間、索引は「作成」されるのではなく「更新」されるのでしょうか。それとも、特にどちらでも問題ないのでしょうか。
2023.09.10 19:39
logres_fanさん
★DB ブロンズマイスター
(No.2)
[RDBMSの主な仕様]
1.(1)アクセス経路は、…。表探索では、…順に…。…
2.(5ページを順次に…
SQL処理時間 = MAX(CPU時間、非同期データ入出力処理時間)
表1 オーソリ履歴 見積行数480億 ページ数24億 容量9,600Gバイト
Fさんは、利用明細抽出処理の処理時間を、次のように見積もった。
2.…2,400,000,000ページを非同期に読み込むデータ入出力処理時間は、96,000秒である。
3.…800,000,000行である。これに掛かるCPU時間は、96,000秒である。
見積ページ数2,400,000,000の非同期データ入出力処理時間96,000が見積上限値。利用明細抽出処理で800,000,000行抽出した場合、見積行数の60分の1なので、見積ページ数60分の1、非同期データ入出力処理時間60分の1。計算結果は、上限値96,000未満。これに掛かるCPU時間は、96,000秒。SQL処理時間は、MAX(96,000、96,000未満)なので96,000秒。> バッファは一切見ずにディスクを見に行くというものなのでしょうか。
いいえ。
> バッファにデータがありそれを見に行けばアクセスは速くなるので処理時間に影響はあるのではないか?
非同期データ入出力処理時間は、見積上限値96,000秒未満に短縮できます。一方、SQL処理時間は、MAX(見積CPU時間96,000秒、短縮された非同期データ入出力処理時間96,000秒未満)なので、96,000秒のまま変わりません。
案2 “オーソリ履歴”テーブルの利用日列をキーとする副次索引を追加する。
案2を適用した場合、オーソリ処理時間が長くなると考えられる。その理由…
行の挿入時に更新する索引が増えるから
> 「行の挿入時に利用日列の副次索引が作られるから」としました。その通りです。でも、解答にはどうかしら。
> 新しい利用日の行ができた瞬間、索引は「作成」されるのではなく「更新」されるのでしょうか。
所謂、CREATE、INSERT、UPDATEではなく、一般用語的な意味での、改める索引が増えるという事なのかしら。
2023.09.11 07:46
いっつさん
(No.3)
この投稿は投稿者により削除されました。(2023.09.11 21:41)
2023.09.11 21:41
DB見習いさん
(No.4)
ありがとうございます。
なるほど、データの入出力時間は確かに速くなるけども、順次アクセス(非同期)のため結局CPU時間がネックとなり、処理時間は変わらないということですね。理解できました。
②は索引の構造というものによるのかなと思ったのですが、あまり気にしなくてもよいのですかね・・
なるほど、データの入出力時間は確かに速くなるけども、順次アクセス(非同期)のため結局CPU時間がネックとなり、処理時間は変わらないということですね。理解できました。
②は索引の構造というものによるのかなと思ったのですが、あまり気にしなくてもよいのですかね・・
2023.09.11 21:41
gawaさん
(No.5)
>全行探索というのはバッファは一切見ずにディスクを見に行くというものなのでしょうか。
はい、そうです。1年前に全く同じことで悩んでましたが、この試験では「全行探索といったらディスクを見に行く」という前提と覚えておけばOKです。イメージですが、RAMは容量が限られているので、通常、全行のデータが入る保証は無いから、と考えてください。
>新しい利用日の行ができた瞬間、索引は「作成」されるのではなく「更新」されるのでしょうか。それとも、特にどちらでも問題ないのでしょうか。
正しくは「既に定義された索引が更新される」です。電話番号と掲載ページが書かれた電話帳を思い浮かべて下さい。この電話帳に、新しい電話番号が途中に挿入されたとしたら、既存の電話番号の中に、今まで存在していたページから追い出されるものがでてきますよね?つまり、全部の電話番号の掲載ページを、一から再編成することになります。これが、索引の「更新」です。「行の挿入によって索引の更新が発生し処理が遅くなる」は定番の話題なので、必ず押さえておきましょう。
2023.09.12 20:49
DB見習いさん
(No.6)
gawaさん
ありがとうございます。
そうなのですか・・どちらにしても、この問に関してはCPU時間がネックになるので結局の処理時間には影響しないという理解で大丈夫でしょうか。
なるほど、行が挿入されるごとに他のデータのアドレスがずれていくので、インデックスの更新が必要になるということでしょうか。
また、自分は日付で索引を作るのであれば、少なくともその日初めて行が作られた時はその日を指すインデックスが初めて作られるので、作成されると解答したのですが、この理解は問題ないでしょうか。もちろんそれよりも上記の理屈による更新の方がずっと契機が多く速度劣化に影響するので、更新とした方がより解答としては好ましいのかなと思いました。
ありがとうございます。
>はい、そうです。1年前に全く同じことで悩んでましたが、この試験では「全行探索といったらディスクを見に行く」という前提と覚えておけばOKです。
>イメージですが、RAMは容量が限られているので、通常、全行のデータが入る保証は無いから、と考えてください。
そうなのですか・・どちらにしても、この問に関してはCPU時間がネックになるので結局の処理時間には影響しないという理解で大丈夫でしょうか。
>既存の電話番号の中に、今まで存在していたページから追い出されるものがでてきますよね?つまり、全部の電話番号の掲載ページを、一から再編成することになります。
なるほど、行が挿入されるごとに他のデータのアドレスがずれていくので、インデックスの更新が必要になるということでしょうか。
また、自分は日付で索引を作るのであれば、少なくともその日初めて行が作られた時はその日を指すインデックスが初めて作られるので、作成されると解答したのですが、この理解は問題ないでしょうか。もちろんそれよりも上記の理屈による更新の方がずっと契機が多く速度劣化に影響するので、更新とした方がより解答としては好ましいのかなと思いました。
2023.09.13 21:32
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。