Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
cocone Teck Talk Vol.4 - 膨大になったDBを何とかする /dealin...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
cocone
October 14, 2021
Programming
770
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
cocone Teck Talk Vol.4 - 膨大になったDBを何とかする /dealing_huge_db
長年運営をしてきた「ポケコロ」のDBに関して、現在の課題とその対応策についてお話します。
cocone
October 14, 2021
More Decks by cocone
See All by cocone
Cocone_Research_Center_2025.pdf
cocone
0
370
20240301_cocone_EMゆるミートアップvol6_LT資料
cocone
0
950
2024_cocone-wellbeing
cocone
0
5.2k
2023夏季合同企業説明会ココネ
cocone
0
420
cocone TECH TALK Vol.6 - リアルタイム対戦xバックエンドアーキテクチャ
cocone
0
730
cocone TECH TALK Vol.6 - ココネグループのブロックチェーン MOOI Network とのバックエンド連携
cocone
0
670
cocone TECH TALK Vol.6 - Kotlin バックエンドアーキテクチャ of アバターサービス
cocone
0
660
cocone corporation(JPN)/Handbook2022
cocone
1
31k
cocone Tech Talk vol.5 - Unity Dotsを使ってみた
cocone
0
2.6k
Other Decks in Programming
See All in Programming
「AI時代、配布するPythonコードをどう守るか: 難読化の実験と判断軸」 #PyconJP2026
pkshadeck
PRO
2
190
業務時間外もAIに働いてもらう話
colorful12
3
10k
数年滞っていたダークモード対応をおよそ2週間で完了させる
chigichan24
0
700
LoopHub - ローカルで動く GitHub で、AI と共同開発
jugyo
1
490
LLMは4年分のCompose移行を再現できるのか?実プロダクト279件のXMLで探る自動化の境界線
makun
0
520
Swift愛好会100回記念 第1回を振り返る
jollyjoester
0
120
DynamoDBの基礎を振り返りながらベクトル検索機能を理解する
musan
3
280
Go × SIMDで高速化するベクトル検索 ~ルーフラインモデルでSIMDが効く境界を探れ! ~
po3rin
1
210
高専キャリア LT 発表内容
crysta1221
6
5.6k
Security issues being discussed on Web Platforms
petamoriken
0
600
Webの地図
yosuke_furukawa
PRO
6
4k
thread_parallel_with_free-threaded_Python_and_NumPy.pdf
riku_sakamoto
0
270
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
6.2k
The World Runs on Bad Software
bkeepers
PRO
72
12k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
290
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
How to make the Groovebox
asonas
2
2.4k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
320
Leo the Paperboy
mayatellez
9
2.3k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
840
Building Applications with DynamoDB
mza
96
7.2k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
460
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
540
Transcript
膨大になったDBを何とかする ポケコロサーバー開発 忻 楽鳴
¿名前 忻 楽鳴 ¿社歴 2017年入社して、ポケコロサーバー開発 を担当しております。 その前職はSIerとして、5,6年ぐらい調査 会社のシステム開発をやっていました。大 量データの取り扱いがそこからです。 ¿趣味 ゲーム、寝る
¿出身 上海@中国
まず、現状どうなっている?? mariaDB、mongoDB、redisDBなど、機能によって使い 分けています。問題になっているのは mariaDBです。 左のようにmaster-slave構成となっています。 masterのdisk使用量が92%まで上昇されています。(月 3~4%ぐらい増え続ける) 簡単計算すると何もしないと余命2ヶ月です(笑) 大量データがあって slow
queryも出やすい状態です。 slave遅延がひどくなるとサービスに影響も出てます。
なにが入ってる?? 所持してるアイテム(約50%) アイテムの獲得履歴、異動履歴 (約15%) 保存してるコーディネート (約15%) 所持数制限がない 何と履歴は削除しない!
・サーバースペックを上げても限界が あります ・仮に容量を拡張できたとしても、逆 にslowqueryがもっと酷くなります
まず、データを減らして、容量 を確保しなきゃ!!!! 1. 必要のないデータを消す 2. 保存期間を設ける 3. 格納するデータを軽量化する 4. 似てようなデータを1つに
通帳など履歴データは基本 3ヶ月しか見せなかった!!
1. しょっちゅう問合せがあって、以前の データを調べたりする必要がある 2. 警察に情報の提供を協力する場合も ある 3. 履歴データは分析する材料でもある 簡単に消すには行かなかった んです。。。
1年以上のデータのことな ら問合せがほぼ来ないの で、削除OKです CXチーム どうしても必要の場合、 BigQueryに移します。 BIチーム 利用契約に追記してもらい ます 運営チーム、法務
バッチ実装して、一定期間 過ぎたデータを継続的に削 除しますように サーバーチーム メンテで過去のデータを削 除します サーバーチーム CMSなど参照先を変更な ど対応します。 サーバーチーム
不要なデータや期間のある履歴を 消したけど、そこまで減っていなかっ たんです
データを移動させ、容量を確保 できるじゃん!!!! 1. 同じDBの別インスタンスに移す 2. 違うDBに移す 3. 非アクティブユーザーデータのアーカ イブ
同じDBの別インスタンスに移すのは簡 単そうに見えるんです。 が、 オンプレミスなので、DBサーバーを用意 するのは結構時間が必要です。 そして、RDBなので、別インスタンスにな ると、分散トランザクションに変えなけれ ば行けないんです。
MariaDBからMongoDBに移します。 ・可能の限り1User 1Docment ・予めshardingに 非アクティブユーザーのデータをアーカイブ 用DB移して削除します ・復帰した場合、自動的にデータを戻せる 仕組みも用意
92% 80% 60% 今ここ disk使用率
None
将来のために何かを準備しな いといけないんだ!! 容量の危機が一旦回避しただけで す。いくつのテーブルが大きいすぎ、 slow queryなどはまだ解消されていま せん 倍以上のDAU、MAUになった時でも 耐えられるようにアーキテクチャにシフト しないといけません。
None
None