大量データ更新 バッチ設計について

Question

大量のデータ更新をバッチファイルで行おうと考えているのですが、
負荷を考慮した場合の設計、データの更新方法について悩んでおります。

【概要】
1テーブルの1カラムの値を更新する

・更新件数
約300万件
(更新対象となるレコードは日々増えていく)

更新対象のレコードを抽出するSQL自体が非常に重いため、
予め更新対象のレコードの主キーなどをExcelファイルに書き出しておき、
バッチからそのExcelファイルを参照させて、更新していく方向で考えているのですが、
日々更新対象のレコードが増えていくため、その都度手動でExcelファイルを生成するのも
非効率的な気がしています・・

定時起動でも行えるとは思うんですが、バッチファイル実行のたびに
コストの高い更新対象のレコードを抽出するSQLが流れる点が懸念です。

負荷面を考慮した場合どのような設計が良いのでしょうか。
なにかアドバイスいただけたら幸いです。

Comments

[hihijiji]

> 更新対象のレコードを抽出するSQL自体が非常に重い
まずこれを何とかするべきかと

[Orlofsky]

同じSQLでもデータベースやそのバージョンによって方言が大きいですから、どのデータベースを使うのかを質問のタグで示したり、バージョンも明記した方が適切なコメントが付き易いです。SQLの観点から Oracle Database, PostgreSQL, MySQL の特徴を整理しよう！ https://www.ashisuto.co.jp/corporate/column/technical-column/detail/1197236_2274.html

[Orlofsky]

>更新対象のレコードを抽出するSQL自体が非常に重いため、
ほとんどの場合、SQLのチューニング以外に解決方法はないでしょう。

差し支えない範囲で質問にCREATE TABLE, CREATE INDEX, SELECT, UPDATe, 実行計画(データベースにより取得方法が異なる) を https://teratail.com/help/question-tips#questionTips3-7 の [コード] で提示されては？

Answer 1

300万件のデータを日々すべて書き換えるイメージですかね？
ちょっとありえない運用だと思いますので、別の方法を検討されるとよいでしょう
具体的に何をどうしたいか提示したほうが良いと思います

Comments

[AT_WORK24]

>300万件のデータを日々すべて書き換えるイメージですかね？
毎日300万件の更新を行うわけではなくて、最終的に300万件を更新ができてればいいので、分割して日々対象レコードの更新を行っていくイメージです。
更新すべき対象レコードが増えていく件数については、日に数千件程度を想定しています。

[yambejp]

日に数千件であれば特に分割処理をしなくても
十分こなせる量ではないのでしょうか？

→少ない量なら少なりに処理する
→多い量ならその処理をやめてもっと効率的なデータ管理をする