2022/03/19 14:29
shallow1729
バッチ処理を書く時に気をつけてる事をまとめてみました。普段のウェブ開発とはちょっと毛色が違うタスクで実装に悩むこともあると思うのでそういう時に参考になれば嬉しいです。[バッチ処理][開発テクニック][MySQL]
2022/03/19 14:34
do_su_0805
最高な記事だ…そういう機会に当たるたびにちゃんと読み直したい…
2022/03/19 18:59
circled
関係ないけど、実行中にスクリプト書き換えたせいで、一気に全データ消去に動き出したみたいな話があったね。
2022/03/19 19:47
moromoro
何十行ものSQLも避けるようにしてくんろ…障害時に読み解くのでものすんごい時間かかる
2022/03/19 20:55
cocoasynn
良い
2022/03/19 22:09
northlight
こういうバッチノウハウ表に出ないからほんと良い。
2022/03/19 23:39
hdampty7
バッチ周りはビジネスロジック自体は結構単純なんだけど、データ量、トランザクション、制限時間等によって難易度が全然違う。
2022/03/20 00:39
magnoliak
良い言語化だ、バッチ、上手くいかない時のことをどれだけ考えられるかだけど、秘伝のタレになりがち
2022/03/20 00:42
chikurou
バッチのSQLといえば数千行がデフォでした（遠い目）
2022/03/20 01:28
roshi
システム日付を使わずパラメーターなどで渡して任意の時点で実行できるようにして欲しい。
2022/03/20 02:53
kagehiens
ActiveRecordでバッチ的処理が実行されるとかもあるのか、知らんかった。／わかりみが深いメッセージがチラホラ入っててすこしだけ涙が・・・。
2022/03/20 02:57
lbtmplz
冪等性〜
2022/03/20 05:13
dreamzico
とにかく最初に丸ごとコピーして、そのコピー相手に思う存分試行錯誤すれば良い。
2022/03/20 07:35
nilab
データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし
2022/03/20 07:43
quabbin
基本が書かれている。私はコレに加え、id:roshi さんの言うような「back fill」の事を考えて設計実装するようにしている。
2022/03/20 08:27
n_231
ユーザー影響を減らすためには、なるべく使われていない時間帯を狙いたい
2022/03/20 08:37
remonoil
バッチってむしろイレギュラーだらけで、業務的な判断で手動実行したり、リスク覚悟で尋常ではない量を実行したり、何の知識も無い人が実行したり、とかあるのでそれ考慮したい
2022/03/20 09:47
taruhachi
出来るだけ処理を分割してそれぞれは単機能のバッチにするようにしてる。更新対象のデータ抽出バッチと更新バッチを分けて対象のリストはファイルにして検証可能にしておくなど。
2022/03/20 09:53
hogetahogeko
冪等性(べきとうせい)大事。更にそのバッチに冪等性があるのかどうかきちんと引き継いでほしい。
2022/03/20 11:14
yarumato
“MySQL。冪等性を持つように（複数回実行しても同じ結果になる）：こけたらもう一回実行できるように作る。途中からの再実行をできるように：処理をこまめにセーブする、まだ処理がされていない箇所を把握できる。”
2022/03/20 11:16
rgfx
あるある
2022/03/20 11:17
forrest-gump
バッチ処理問わず重要な考え方。冪等性（べきとうせい）。数学かエンジニアやってないと使わない漢字。記事もあるけど、オートインクリメントとかあるから冪等にするには頭を使う。
2022/03/20 11:25
tkzwtks
良い。バッチサイズのコントロールは忘れがちだけど結構重要
2022/03/20 15:11
aike
現代的でもっともな主張ではあるけど、もともとバッチは巨大なデータを何時間もかけて処理するような分野で使われてきた経緯があって、冪等性があっても時間的に営業開始までに実行し直せないという状況が多かった。
2022/03/20 15:13
versatile
速度を調整できるようにしたいね。rsync みたいに
2022/03/20 19:40
yamadashy
大事