どんな場面で検討するか
複数システムの履歴/ログを集め、SQLで売上・業務KPI・傾向を分析したい場合。大量データの分析用で、日々の個別画面の更新DBとは用途を分ける。
組織で使う条件
ジョブ失敗と遅延、取込件数、クエリの走査量、データ品質、権限を監視する。加工したKPIの根拠列/期間を記録し、再計算手順を持つ。
採用前に試すこと
- 売上1000件を用意し、正解の月別件数/合計とパーティション設計を定めて投入する。
- dry runで走査量を調べ、期間指定/列指定のクエリと全走査を比較し、課金上限を設定する。
- 読取/編集権限を分けて実行し、欠損/重複入力を検出する品質検査と再取込を試す。
合格と判断する条件
- 月別件数/合計が期待値に一致し、欠損と重複が検出される。
- 権限分離とクエリ上限が確認でき、採用するon-demand/slot方式を説明できる。
見落としたくない点
- 低遅延の行単位更新を多発するOLTPアプリならCloud SQL等と比較する。SELECT *の全量走査を無制限に繰り返す用途は費用管理を先に設計する。
- 低遅延の行単位更新を多発するOLTPアプリならCloud SQL等と比較する。SELECT *の全量走査を無制限に繰り返す用途は費用管理を先に設計する。