1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

[turanukimaru]

何よりもまず、手元のマシンで簡単なCRUDでもいいから一千万件試してみる事だね。だんだん遅くなって2時間後にはほぼ停止したりJavaがパーマネント領域使い切って死んだりする。そんな仕事から半年前に逃げ出しました！

[magnoliak]

案外、この辺ってきちんと古代のバッチおじさん達の知見が上手く現代にマッチさせる形で整理されて継承されていない領域なのかなーってふと思った

[yuzutas0]

Q. BigQueryを使えば？ → A. BigQueryにデータを入れる箇所でこの設計が必要になります…。

[kuzumimizuku]

「カジュアルに扱う方法！？あるの！？」と思って見たけど、全然カジュアルじゃなかった(；´Д｀)やっぱり丁寧かつ入念な準備とトラブルに対応できる経験が必要ということですね……。

[robo_pitcher]

1000万件の処理で990万件でエラーで止まるケース、想像してゾッとした。特に情報系じゃなく基幹系だったら

[programmablekinoko]

めちゃくちゃ示唆に富む / 昔のバッチは汎用機の閉じた環境(COBOL+JCL)で固定長レコードを扱う処理が主だったから流用できるのかな...

[nmcli]

AWSならではのコスト意識とも捉えられるし、AWS依存ゆえのバッドノウハウとも感じるし

[t_motooka]

昔は失敗することくらいでしか学ぶことの出来なかった事柄たちが、こんなにまとまっていて感激

[mohno]

「これらはそもそもRDBの話ではありません」「数億件の中から1000万件を取得して数分以内に処理を終わらせるとかそういう処理を頻繁に(カジュアルに)実装しなければならない弊社の話」←おっ、おぅ……

[sds-page]

誰が書いたコードでも一年以上安定稼働してないと信用できない派。月一のバッチが2,3回連続で成功してても油断はできない

[el-condor]

途中からリトライ可能にするのは案外難しい。でも0.1Mレコードまでなら全部リトライすりゃええやんが最適だけど10Mレコードとなるとそういうわけにもいかないからね。

[rochefort]

大変そう

[tri-star]

大量データを扱う処理で気を付けたいことが色々まとまっている

[NetPenguin]

「カジュアルに扱うための心構え」 カジュアルな手段では無く、カジュアルに扱えるように研鑽しとけって話か……

[irof]

わかる人は思いっきりうなづいて読みそうな一言一言。現場で読み合わせ／認識合わせとかすると良さそう。現場でね。コンテキスト合ってないと多分すれ違う。

[impreza98]

Redshiftは良いぞ

[teckl]

リトライ機構、冪等性の維持、工程ごとのログなど他の分野でもめっちゃ同意できる知見だ…　古のバッチの知恵が現代にも生きているなぁ…

[issyurn]

“1000万オーバーの件数から数件取るとかそういう話ではなく数億件の中から1000万件を取得して数分以内に処理を終わらせるとかそういう処理を頻繁に(カジュアルに)実装しなければならない弊社の話でした。”

[sucelie]

これでカジュアルなんだから胃腸がやられそうだ

[snowcrush]

"手癖で書くな" は重要やね。問題を変形せずに頭の中のワークフローをそのまま書き下してしまうと大体きつくなってくる

[rawwell]

"at least onceはexactly onceより圧倒的に処理負荷が軽い、羃等であるならat least onceで安全に処理できる "

[y_maeyama]

"手癖で書かない"がピンとこないなぁ。経験しないとわからないことなのかしら。

[natu3kan]

通信の過信と通信がオーバーヘッドになるのあるある。ってのと工程ごとにログを吐いてくれないと躓きが見えないから辛いのある。

[akahigeg]

“ちょっとでも関係しそうなサービスを見かけたらとりあえずドキュメントを読む癖を付けておかないと、いざという時に思い付かなくなる。” つらみ

[iga_k]

大量レコードじゃなくても使える知見だ！

[t-wada]

joker さんの知見が詰まっていてすばらしいエントリ。「手癖で書くな」はよくわかる……

[innocencecrash]

カジュアルに扱うためには正統な手続きが色々必要ってわけですね。

[azmin]

バッチ処理やってると案件固有で潰しがきかないアイデアなんじゃないかと思うことばっかりだけどこれだけエッセンスを抽出できているのは尊敬する

[kappaseijin]

バッドノウハウな知見集。AWS、TD、その他のサービスも落とし穴沢山なので入口より出口を知るの重要

[kotaponx]

ミッションクリティカルでなくて、割とどうでもいいrerun OKなログ系のデータしか扱ってないけど、それでもそれなりに工夫はいるという感覚はある。

[okami-no-sacchan]

レコードの話かと思ったのに

[teto2645]

後で読ませる。

[cloverstudioceo]

インデックスを貼れとかそういうレベルの話じゃなかった。。。

[rjge]

“適宜ログを吐かないと、どこまで進んでいるか分からない” “一方で一件単位で詳細なログを吐くとログのデータサイズやログ出力の負荷が馬鹿にならない” 悩ましい。手癖は耳が痛い…

[shikiarai]

多分必要ないノウハウ（願望

[kagehiens]

これは有り難い知見だ。社内環境で完結しているのはきょうび恵まれている内に入るのだなぁ。

[masalib]

「既存のコードを信用するな」・・・痛いほど分かります

[pitti2210]

なんとなく一瞬かわんごのブログかと思ったら違った

[rryu]

大量データのバッチ処理の話だった。この辺はいつでも変わりなく、処理時間を含むリソース消費量、エラーハンドリング、リトライの設計をちゃんとしないと死ぬぞという話になる。

[kako-jun]

1000万パワーすごい。人口の多いアジアならではの知見ですね。1つ心構えを足すとすれば、自室に同じ規模のDBを構築して日々夜間バッチの実験をすることで経験値の取得ペースが倍になります