Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
パフォーマンス改善
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
takakuda
October 31, 2019
0
160
パフォーマンス改善
takakuda
October 31, 2019
Tweet
Share
More Decks by takakuda
See All by takakuda
gem version up
takakuda
0
2.3k
リファクタリング
takakuda
0
46
ぼくらのかんがえたさいきょうのfactory_bot
takakuda
0
2.6k
LINE, Messenger比べてみました。
takakuda
0
1.4k
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.3k
The Invisible Side of Design
smashingmag
302
51k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
The untapped power of vector embeddings
frankvandijk
1
1.6k
Evolving SEO for Evolving Search Engines
ryanjones
0
130
Context Engineering - Making Every Token Count
addyosmani
9
660
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
100
The SEO Collaboration Effect
kristinabergwall1
0
350
Typedesign – Prime Four
hannesfritz
42
2.9k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
117
110k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
150
Transcript
テクノロジー開発部 takakuda
• 自己紹介 • 大きくなったDB負荷 • logテーブルの設計 • まとめ Agenda
自己紹介
- 前職 仙台で雛人形売り - 2017.08 ~ Zeals - Ruby -
Rails ZEALS Engineer Rails エンジニア :takakuda :@kutaike1504
パフォーマンス改善
サービスが大きく成長したことによって 発生した問題とどう対処していったのか
アーキテクチャの変更
https://tech.zeals.co.jp/entry/2019/09/24/105716
なぜアーキテクチャを変更したのか?
パフォーマンスが悪くなったから
アーキテクチャ変更によって今は対応 できているけども なぜ変更する必要があったのか? どうすれば変更なしで対応できたの か?
自分の失敗より 他者の失敗から学ぶ
大きくなったDB負荷
ユーザーの行動log
大量のSQL write によって Appサーバーが落ちる
logをDBに書き込むのではなく log dataとして外部出力する
非RDB化 詳しくは弊社 TECH BLOGへ! https://tech.zeals.co.jp/entry/2019/08/26/101131
大量のSQL writeがなくなった
どうすれば大きくなるDB負荷を避ける ことができたか?
logテーブルの設計
どういう設計をすればよかったのか?
パーティション…とか?
1つのテーブルを分割して管理する仕組み 巨大なデータを複数に分割するこができ、 分割したデータごとに削除や参照ができる
log系のテーブルであれば基本的に時系列的に増えて いくものだし、現在に近いレコードに対する参照がほとん どのはず。 古いレコードを参照する場合でも特定の期間を指定する パターンが多い。 であれば日付でパーティションを切るのは有効
ただし制約もある - クエリキャッシュをサポートしない - 外部キーをサポートしない など…
データサイズに注意する どこかでデータを切り捨てることを考 える必要がある
まとめ • データサイズに注意して予め設計する
LET'S START NEXT INDUSTRIAL REVOLUTION WITH OUR FLYING SHUTTLE
Thank you!!