コンテンツにスキップ

ラジオの話題12:日付で分けたデータを、ユーザーで探す

← ラジオの話題一覧 · 元の教材・詳しい解説

今日の話題:①捨てやすい分け方と、探しやすい分け方 → ②一つのSQLで、いくつも探す → ③少数返すだけでも、子は多い。

気になったところから自由に。順番や時間は決めず、話しやすい話題だけ拾って構いません。

1. 捨てやすい分け方と、探しやすい分け方

Section titled “1. 捨てやすい分け方と、探しやすい分け方”

話を広げるメモ

  • 日付で分割すれば古い範囲を扱いやすい。
  • 全期間のuser検索には日付条件がない。

小ネタ:partition pruning

不要なpartitionを除外するには、分割境界と検索条件の関係が重要。日付で分けただけではuser検索で過去の月を飛ばせるとは限らない。

話の芯:保持の軸と、検索の軸は一致する?

話を広げるメモ

  • 各月のindexを調べる計画。
  • SQL一つだからscanも一回、ではない。

小ネタ:AppendとMerge Append

Appendは子の結果を連結し、全体の順序は保証しない。Merge Appendは順序付きの子の候補を比較して次の行を選ぶ。全件を集めて再sortする処理とは違う。

話の芯:DBの中で増える仕事を想像する。

3. 少数返すだけでも、子は多い

Section titled “3. 少数返すだけでも、子は多い”

話を広げるメモ

  • 最初の1行を選ぶために各月の先頭候補を見る。
  • 月単位と日単位の管理対象数の違い。

小ネタ:最初の行までの費用

Merge Appendは複数の子の先頭候補を必要とし得る。LIMITが小さくても、多数partitionの計画・探索の負担が消えるわけではない。小さな実験の時間を個数だけで比例拡大しない。

話の芯:結果の小ささだけで、探索の軽さを決めない。

「この話を、次に調査や設計をするときどう思い出したいか?」

既存の学習振り返り教材から話題を選び、AIが小ネタとして再構成しました。説明・設計例と、本人の回答・実測の記録は別です。数値例は記載した仮定に基づくもので、本人の本番実績ではありません。

定義の詳細・前提・一次資料・対象版・確認日は元の教材を参照してください。今回の作成では新しい実験・学習評価は行っていません。