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

履歴が膨大なら、どう保存する？〜Kaigi on Rails登壇後に深まったデータ設計の話〜越智翔一（occhi） Kaigi on Rails 2026事後勉強会
2026-11-06

自己紹介おちしょういち越智翔一（occhi） SmartBank, Inc. Software Engineer 経歴:
イタンジ株式会社 → GMOビューティー株式会社 → 株式会社スマートバンク趣味: 筋トレ @ochi11181101 @sho-work 2

Kaigi on Rails 2026では、大量データの書き込みボトルネックに焦点を当てた話をしました 3

Kaigi on Rails 2026 でこんな登壇をしました！ 4

データモデルを工夫して、DBに保存 5

登壇後の議論から、次の問いが生まれた： 1電話番号の履歴が膨大で、重い加工が要るなら？ 6

思考実験：履歴が膨大で（=n）、加工に O(n²) かかるとしたら 7

LLMに雑にO(n²)のロジックを書かせてみるロジックの詳細までは見れておらずです・・・・ 8

性能要件：読み取りは 50 ms 以内 9

素直に、履歴を1件1行で保存して、毎回計算すると？ 10

Rubyのレイテンシーは n² に比例して伸び、7,305件で要件を満たせない 11

時間のほとんどは、CPU の計算だった 12

高速化していく 13

手段1: 言語を変えてみる🤔 14

手段1 言語を変える：Rustなら約50倍速いが、読むたびの O(n²) は残る 15

Rustにすると速い！（〜完〜） 16

冗談です（水飲みます） 17

Rubyでも高速化できないかな？ 18

ところで 19

先週末にあったイベント、覚えていますか 20

10/31にISUCON2026がありましたね！ 21

留意点：保存できるのは、決めた加工の結果だけ • 画像の署名がCPU boundかつ、とんでもなく時間がかかっていた • 多くの方は事前に計算し、ルックアップテーブルにしておくことで得点を向上させていた 22

これ、今回も使えるじゃん！ 23

手段2: 結果を事前計算して保存しておく 24

手段2: 結果を事前計算して保存しておく 25

高速化成功！🎉 26

オチ（occhiだけに！） 27

今回のやり方が適さないケース • 更新のたびに再計算するコストを許容できない場合 • 計算結果を常に最新に保つ必要がある場合 28

ご清聴ありがとうございました 29

Appendix：ルックアップテーブル例 30

Appendix：周期の探索は、候補ごとに全履歴を比べるので O(n²) 31

電話番号ごとの「契約の周期」が欲しいとする 32

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

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

Shoichi Ochi

More Decks by Shoichi Ochi

Other Decks in Technology

Featured

Transcript