R2 午後2 問1 設問3(2)差異1について
DB見習いさん
(No.1)
R2 午後2問1設問3(2)差異1の解答について、自分がまだバッファやインデックスについての理解が甘く、質問させてほしいです。
模範解答の「クラスタ率が高くなった」ということは、索引探索したデータがバッファ上にあれば、他の取得したいデータも同じページ内(つまりバッファ上)にある確率が高いので、おのずとバッファヒット率も高くなるということだと理解しています。
①
ただ、もし索引探索したデータがバッファにない場合は、次に取得したいデータも高確率で同じページ内にあるため同様にバッファに存在せず、バッファヒット率は低くなる気がします。クラスタ率が高い→バッファヒット率が高い、のつながりがよく分からないのですが、どなたか教えていただいてもよろしいでしょうか。
②
①が解決したとして、機器ログテーブルは主キーが住居番号、年月日という順で定義されていますが、クラスタ率の向上を考えると年月日、住居番号という順で定義した方がよいということでしょうか。あるいはインデックスを年月日、住居番号という順で定義すればよいかと思ったのですが、DBスペシャリストでは基本的にテーブル内の列の定義順にインデックスも定義している気がします(単にインデックスの定義順をいちいち記載するのが手間なので関係スキーマと統一しているのでしょうか)。他のインデックスと同様に先頭列を住居番号にしないと何か弊害があるのでしょうか。
模範解答の「クラスタ率が高くなった」ということは、索引探索したデータがバッファ上にあれば、他の取得したいデータも同じページ内(つまりバッファ上)にある確率が高いので、おのずとバッファヒット率も高くなるということだと理解しています。
①
ただ、もし索引探索したデータがバッファにない場合は、次に取得したいデータも高確率で同じページ内にあるため同様にバッファに存在せず、バッファヒット率は低くなる気がします。クラスタ率が高い→バッファヒット率が高い、のつながりがよく分からないのですが、どなたか教えていただいてもよろしいでしょうか。
②
①が解決したとして、機器ログテーブルは主キーが住居番号、年月日という順で定義されていますが、クラスタ率の向上を考えると年月日、住居番号という順で定義した方がよいということでしょうか。あるいはインデックスを年月日、住居番号という順で定義すればよいかと思ったのですが、DBスペシャリストでは基本的にテーブル内の列の定義順にインデックスも定義している気がします(単にインデックスの定義順をいちいち記載するのが手間なので関係スキーマと統一しているのでしょうか)。他のインデックスと同様に先頭列を住居番号にしないと何か弊害があるのでしょうか。
2023.08.03 22:56
来年受験さん
(No.2)
クラスタ率
ヒットするデータが近くにある割合では
ヒットするデータが近くにある割合では
2023.08.04 07:50
logres_fanさん
★DB ブロンズマイスター
(No.3)
R2午後II採点講評とH30午後Ⅰ設問1(3)②が参考になります。
まずはページを検索してバッファに読み込む、そこから始めない限り、性能テストが始まらないのではないかしら。
> もし索引探索したデータがバッファにない場合は、次に取得したいデータも高確率で同じページ内にあるため同様にバッファに存在せず、
まずはページを検索してバッファに読み込む、そこから始めない限り、性能テストが始まらないのではないかしら。
2023.08.05 02:08
DB見習いさん
(No.4)
お二方とも回答ありがとうございます。
クラスタ率=データの物理的配置がテーブルの並びと近いことであることは理解しているつもりですが、そのデータがバッファにあるかないかはまた別なのでは?と思った次第です。
データの投入順序によってはクラスタ率が高くなるのは理解できるのですが、その結果設問文にあるようにバッファヒット率(=欲しいデータがバッファ上にあるかどうか?)も向上する理由がいまいち分からないです。
バッファヒット率という指標がある以上、検索を繰り返すことでデータがバッファから追い出されために索引探索しても探索対象のデータがバッファにない、ということはあり得るかなと思っています。
クラスタ率=データの物理的配置がテーブルの並びと近いことであることは理解しているつもりですが、そのデータがバッファにあるかないかはまた別なのでは?と思った次第です。
データの投入順序によってはクラスタ率が高くなるのは理解できるのですが、その結果設問文にあるようにバッファヒット率(=欲しいデータがバッファ上にあるかどうか?)も向上する理由がいまいち分からないです。
バッファヒット率という指標がある以上、検索を繰り返すことでデータがバッファから追い出されために索引探索しても探索対象のデータがバッファにない、ということはあり得るかなと思っています。
2023.08.08 17:49
logres_fanさん
★DB ブロンズマイスター
(No.5)
ざっくりとしたものですが、間違えがあれば誰か訂正して下さい。
高クラスタに限らず、追い出されたり、空から始めたりする場合、分母が大きくなります。
Notディスクから読み込む回数÷(Notディスクから読み込む回数+ディスクから読み込む回数)
高クラスタの場合、分子が大きくなる。> 探索対象のデータがバッファにない
高クラスタに限らず、追い出されたり、空から始めたりする場合、分母が大きくなります。
2023.08.09 01:41
DCLさん
(No.6)
この投稿は投稿者により削除されました。(2023.08.09 10:51)
2023.08.09 10:51
DCLさん
(No.7)
この投稿は投稿者により削除されました。(2023.08.09 10:53)
2023.08.09 10:53
DCLさん
(No.8)
①クラスタ率が高い。とは
索引キーの順番で、データページにデータが登録されている可能性が高いことです。
簡単な例で言うと…
------------------------------------------------------------------------------
索引キー"住居番号"が定義されたテーブル[住居番号,年月…]に
下記2つの方法、データを登録する。
1."住居番号"の順にデータを登録する。
→同一のデータページに同じ住居番号が集中する(高クラスタ)
2."年月 "の順にデータを登録する。
→同一のデータページに同じ年月が集中する(低クラスタ)
索引キーは"住居番号"で定義されているので
索引ページの並びは1,2も違いはありません。当然、住居番号順です。
この場合、データページのアドレスを示す行ロケータに相違が出ます。
1.索引ページ
住居番号、行ロケータ
0001、*A (0001,1月のデータ)
0001、*A (0001,2月のデータ)
0002、*B (0002,1月のデータ)
0002、*B (0002,2月のデータ)
2.索引ページ
住居番号、行ロケータ
0001、*A (0001,1月のデータ)
0001、*B (0001,2月のデータ)
0002、*A (0002,1月のデータ)
0002、*B (0002,2月のデータ)
この状態で住居番号"0001"を使って検索すると…
1.はクラスタ率が高いのでデータページAにアクセスするだけで済む
(探索行数2、探索ページ数1、バッファA、データページAにバッファヒット)
2.はクラスタ率が低いのでデータページA、Bにアクセスする必要がある
(探索行数2、探索ページ数2、バッファA→B、バッファヒットなし)
------------------------------------------------------------------------------
といった感じです。
1は順次アクセス、2はランダムアクセスとして。DB試験では表現されています。
②の回答は①の考えと問題文の状況を鑑みて、少し考えてみてください。
確か高クラスタ性を示す「~順でデータを追加する」等の記述があったはずです。
(…というか私の文章力で簡潔にまとめる自信がないです。ごめんなさい。)
索引キーの順番で、データページにデータが登録されている可能性が高いことです。
簡単な例で言うと…
------------------------------------------------------------------------------
索引キー"住居番号"が定義されたテーブル[住居番号,年月…]に
下記2つの方法、データを登録する。
1."住居番号"の順にデータを登録する。
→同一のデータページに同じ住居番号が集中する(高クラスタ)
2."年月 "の順にデータを登録する。
→同一のデータページに同じ年月が集中する(低クラスタ)
索引キーは"住居番号"で定義されているので
索引ページの並びは1,2も違いはありません。当然、住居番号順です。
この場合、データページのアドレスを示す行ロケータに相違が出ます。
1.索引ページ
住居番号、行ロケータ
0001、*A (0001,1月のデータ)
0001、*A (0001,2月のデータ)
0002、*B (0002,1月のデータ)
0002、*B (0002,2月のデータ)
2.索引ページ
住居番号、行ロケータ
0001、*A (0001,1月のデータ)
0001、*B (0001,2月のデータ)
0002、*A (0002,1月のデータ)
0002、*B (0002,2月のデータ)
この状態で住居番号"0001"を使って検索すると…
1.はクラスタ率が高いのでデータページAにアクセスするだけで済む
(探索行数2、探索ページ数1、バッファA、データページAにバッファヒット)
2.はクラスタ率が低いのでデータページA、Bにアクセスする必要がある
(探索行数2、探索ページ数2、バッファA→B、バッファヒットなし)
------------------------------------------------------------------------------
といった感じです。
1は順次アクセス、2はランダムアクセスとして。DB試験では表現されています。
②の回答は①の考えと問題文の状況を鑑みて、少し考えてみてください。
確か高クラスタ性を示す「~順でデータを追加する」等の記述があったはずです。
(…というか私の文章力で簡潔にまとめる自信がないです。ごめんなさい。)
2023.08.09 10:54
DB見習いさん
(No.9)
この投稿は投稿者により削除されました。(2023.08.15 00:59)
2023.08.15 00:59
DB見習いさん
(No.10)
ご丁寧に回答していただきありがとうございます。
すみません、ここの【】の部分がいまいちわからなかったのですが、A・Bというのはデータページのことで、AはバッファにあったけどBはなくて、ゆえに2つ目の方はバッファヒット率が下がるということでしょうか。
また、色々考えて思ったのは、クラスタ率が高いということは、(今回の問題に関しては)同じページ上に探索対象のデータ群が集まっている確率が高く、ページへの最初のアクセス時はバッファになかったとしても、それ以降はバッファに乗るので、そのページへアクセスし続ける(クラスタ率が高いため)と自然とバッファヒット率も高くなる、ということでしょうか。
逆にクラスタ率が低いと様々なページへアクセスしなければならず、そうこうしている内にバッファからページが追い出されるのでバッファヒット率が下がる、という理屈です。
②については、自分はインデックスを「年月、住居番号」の順に設定した方がよいと思っていますが、それがあっているか、また何か弊害があるのかを確認したいです。
>(探索行数2、探索ページ数1、【バッファA、データページAにバッファヒット)】
>(探索行数2、探索ページ数2、【バッファA→B、バッファヒットなし)】
すみません、ここの【】の部分がいまいちわからなかったのですが、A・Bというのはデータページのことで、AはバッファにあったけどBはなくて、ゆえに2つ目の方はバッファヒット率が下がるということでしょうか。
また、色々考えて思ったのは、クラスタ率が高いということは、(今回の問題に関しては)同じページ上に探索対象のデータ群が集まっている確率が高く、ページへの最初のアクセス時はバッファになかったとしても、それ以降はバッファに乗るので、そのページへアクセスし続ける(クラスタ率が高いため)と自然とバッファヒット率も高くなる、ということでしょうか。
逆にクラスタ率が低いと様々なページへアクセスしなければならず、そうこうしている内にバッファからページが追い出されるのでバッファヒット率が下がる、という理屈です。
②については、自分はインデックスを「年月、住居番号」の順に設定した方がよいと思っていますが、それがあっているか、また何か弊害があるのかを確認したいです。
2023.08.15 01:00
DCLさん
(No.11)
>すみません、ここの【】の部分がいまいちわからなかったのですが
>A・Bというのはデータページのことで、AはバッファにあったけどBはなくて
>ゆえに2つ目の方はバッファヒット率が下がるということでしょうか。
そうですね。上記の理解で問題ありません。
1つ目の方はデータ1行目でデータページAにアクセス後、データ2行目はデータページAに
アクセスする必要があるのでバッファ利用可。
2つ目の方はデータ1行目でデータページAにアクセス後、データ2行目はデータページBに
アクセスする必要があるのでバッファ利用不可。
たとえバッファサイズを大きくして、複数のデータページを記憶できるようにしても
検索対象になるデータページ数が多い(クラスタ率が低い)ほど
バッファからページが追い出される可能性が高くなり、バッファヒット率が下がります。
説明が下手で本当に申し訳ないです><
②について弊害があるかないかはシステムの状況によります。
例えば本番稼働後に、"機器ログ"テーブルに年月、住居番号順によるデータ登録が多発。
クラスタ率が高くなった「年月、住居番号」順の副次索引を定義して運用するケースも十分考えられるでしょう。
(ログデータという登録頻度高テーブルである以上、オーバーヘッドによるデメリットは考慮する必要があります)
あくまで設問3(2)の差異1の原因を回答するにおいては考える必要がない。
ということになります。
2023.08.15 13:33
DCLさん
(No.12)
②については利用しているRDBMSにも大きく依存します。
一概に「これが正しい」と断言することができません。
もし利用しているRDBMSがSQLServerでデフォルト設定でテーブルを作成していた場合
上記の流れで副次索引を作成すると…恐ろしいことになる可能性もあります。
これは試験に合格して、少し浮かれていた私が
高度情報試験で勉強したことが、どんなケースでも必ず正しいと
完全に自惚れていた中で、大失敗した実例です…。
つまるところ、DB試験で得た基本知識をもとに
実業務のシステム状況、RDBMSを考慮して
現場で最適解を導き出していくことが一番重要です。
一概に「これが正しい」と断言することができません。
もし利用しているRDBMSがSQLServerでデフォルト設定でテーブルを作成していた場合
上記の流れで副次索引を作成すると…恐ろしいことになる可能性もあります。
これは試験に合格して、少し浮かれていた私が
高度情報試験で勉強したことが、どんなケースでも必ず正しいと
完全に自惚れていた中で、大失敗した実例です…。
つまるところ、DB試験で得た基本知識をもとに
実業務のシステム状況、RDBMSを考慮して
現場で最適解を導き出していくことが一番重要です。
2023.08.15 14:18
DB見習いさん
(No.13)
①については、クラスタ率が高いと同じページに何度もアクセスするため、そのページがバッファに乗る⇒バッファアクセスの回数が増えるということで理解できました。ありがとうございます。
②について、確かに「住居番号、年月」と「年月、住居番号」それぞれのインデックスを作成するという手もありますね。経験が浅いので具体的な好ましいケースとそうでないケースがぱっと思いつきませんが、
ということで承知しました。
本当にありがとうございました。
②について、確かに「住居番号、年月」と「年月、住居番号」それぞれのインデックスを作成するという手もありますね。経験が浅いので具体的な好ましいケースとそうでないケースがぱっと思いつきませんが、
>あくまで設問3(2)の差異1の原因を回答するにおいては考える必要がない。
ということで承知しました。
本当にありがとうございました。
2023.08.15 16:54
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。