履歴が膨大なら、どう保存する？ 〜Kaigi on Rails登壇後に深まったデータ設計の話〜

Kaigi on Rails 2026事後勉強会 登壇資料
https://smarthr.connpass.com/event/407402/

1. 履歴が膨大なら、どう保存する？ 〜Kaigi on Rails登壇後に深まったデータ設計の話〜 越智 翔一（occhi） Kaigi on Rails 2026事後勉強会 2026-11-06
2. 自己紹介 おち しょういち 越智 翔一（occhi） SmartBank, Inc. Software Engineer 経歴: イタンジ株式会社 → GMOビューティー株式会社 → 株式会社スマートバンク 趣味: 筋トレ @ochi11181101 @sho-work 2
3. Kaigi on Rails 2026では、 大量データの書き込みボトルネックに焦点を当てた話をし ました 3
4. Kaigi on Rails 2026 でこんな登壇をしました！ 4
5. データモデルを工夫して、DBに保存 5
6. 登壇後の議論から、次の問いが生まれた： 1電話番号の履歴が膨大で、 重い加工が要るなら？ 6
7. 思考実験：履歴 が膨大で（=n）、加工に O(n²) かかるとしたら 7
8. LLMに雑にO(n²)のロジックを書かせてみる ロジックの詳細までは見れておらずです・・・・ 8
9. 性能要件：読み取りは 50 ms 以内 9
10. 素直に、履歴を1件1行で保存して、毎回計算すると？ 10
11. Rubyのレイテンシーは n² に比例して伸び、7,305件で要件を満たせない 11
12. 時間のほとんどは、CPU の計算だった 12
13. 高速化していく 13
14. 手段1: 言語を変えてみる🤔 14
15. 手段1 言語を変える：Rustなら約50倍速いが、読むたびの O(n²) は残る 15
16. Rustにすると速い！（〜完〜） 16
17. 冗談です（水飲みます） 17
18. Rubyでも高速化できないかな？ 18
19. ところで 19
20. 先週末にあったイベント、覚えていますか 20
21. 10/31にISUCON2026がありましたね！ 21
22. 留意点：保存できるのは、決めた加工の結果だけ • 画像の署名がCPU boundかつ、とんでもなく時間がかかっていた • 多くの方は事前に計算し、ルックアップテーブルにしておくことで得 点を向上させていた 22
23. これ、今回も使えるじゃん！ 23
24. 手段2: 結果を事前計算して保存しておく 24
25. 手段2: 結果を事前計算して保存しておく 25
26. 高速化成功！🎉 26
27. オチ（occhiだけに！） 27
28. 今回のやり方が適さないケース • 更新のたびに再計算するコストを許容できない場合 • 計算結果を常に最新に保つ必要がある場合 28
29. ご清聴ありがとうございました 29
30. Appendix：ルックアップテーブル例 30
31. Appendix：周期の探索は、候補ごとに全履歴を比べるので O(n²) 31
32. 電話番号ごとの「契約の周期」が欲しいとする 32