Downloaded 76 times
Uploaded bysairoutine
PPTX, PDF34,831 views
ゲームエンジニアのためのデータベース設計
GameServerDevelopers Vol.1https://gsdevelopers.doorkeeper.jp/events/42497
Recommended
![スマホゲームのチート手法とその対策 [DeNA TechCon 2019]](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2ftechcon2019funakubo-190218065153-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Viewers also liked
Similar to ゲームエンジニアのためのデータベース設計
![[db tech showcase Tokyo 2015] D23:MySQLはドキュメントデータベースになり、HTTPもしゃべる - MySQL Lab...](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fdbts-tokyo-2015d23mysqloracle-mysqlgbu-150619101210-lva1-app6891-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More from sairoutine
ゲームエンジニアのためのデータベース設計
- 1.Copyright © DeNACo.,Ltd. All Rights Reserved.ゲームエンジニアのためのデータベース設計株式会社 DeNA Games Osaka技術編成部人西 聖樹 masaki.hitonishi@dena.com
- 2.Copyright © DeNACo.,Ltd. All Rights Reserved.自己紹介 人西聖樹 (ひとにし まさき) 株式会社 DeNA Games Osaka 2014年 入社 Webアプリケーションエンジニア シューティングゲーム好き。東方Project 大好き 某400万人ユーザー超えモバイルゲームの開発やってます
- 3.Copyright © DeNACo.,Ltd. All Rights Reserved.ゲームのサーバーサイド
- 4.Copyright © DeNACo.,Ltd. All Rights Reserved.データをどうやって保存しようか？
- 5.Copyright © DeNACo.,Ltd. All Rights Reserved.多様な選択肢 RDBMSMySQLOraclePostgreSQL KVSRedisRiak カラム指向型Apache CassandraHbase ドキュメント指向MongoDBApache CouchDBetc…
- 6.Copyright © DeNACo.,Ltd. All Rights Reserved.今日は MySQL の話をします！
- 7.Copyright © DeNACo.,Ltd. All Rights Reserved.突然ですがアンケート
- 8.Copyright © DeNACo.,Ltd. All Rights Reserved.MySQL使った事ある人！
- 9.Copyright © DeNACo.,Ltd. All Rights Reserved.explain コマンド使ったことある人！
- 10.Copyright © DeNACo.,Ltd. All Rights Reserved.InnoDB におけるギャップロック とネクストキーロックについて説明できる人！
- 11.Copyright © DeNACo.,Ltd. All Rights Reserved.本日のテーマ RDBMS (リレーショナルデータベース) とは データベース観点でのゲームのデータの特徴 データベース構築時に気をつけること アプリケーション開発時に気をつけること
- 12.Copyright © DeNACo.,Ltd. All Rights Reserved.リレーショナルデータベースとは データを行と列の組み合わせによる表で表す 複数の表と表を関係(リレーション)によって組み合わせられるID 名前 攻撃力 防御力1 Aさん 100 1002 Bさん 200 150ユーザーID アイテムID 所持数1 1 11 2 31 3 5ユーザーテーブルアイテム所持テーブルユーザーテーブルの情報からAさんがどのアイテムを何個所持しているか取得することができる。
- 13.Copyright © DeNACo.,Ltd. All Rights Reserved.ACID特性 Atomicity 原子性トランザクションの操作は全て実行されるかまったく実行されないかのどちらか Consistency 一貫性トランザクション開始時と終了時にデータの整合性が保たれる Isolation 独立性他のトランザクションによる操作の影響を受けない Durability 永続性コミットしたトランザクションのデータは保存される
- 14.Copyright © DeNACo.,Ltd. All Rights Reserved.ゲームデータの特徴 ユーザーを primary key としたレコードが多い 永続データと期間限定データ(イベントのデータ等)がある マスタデータ(read only)が多いアイテムマスタ、ボスマスタ、ボス出現マスタ etc… レコードの状態更新が多いボスのHP減少、HP回復、マップ移動 etc… 可用性・整合性は大切ゲームがプレイできない、アイテムを使用したのに回復していない等の不具合・障害に対して、課金しているユーザーの温度感は非常に高い
- 15.Copyright © DeNACo.,Ltd. All Rights Reserved.データベース構築時に考えること Master/Slave 構成 垂直分割 水平分割垂直／水平分割はアプリケーション側で対応しないといけない(MySQL 側に仕組みがない)が後から追加するのは大変なので最初から考慮して開発する
- 16.Copyright © DeNACo.,Ltd. All Rights Reserved.Master / Slave 構成MasterSlave Slave Slaveレプリケーション
- 17.Copyright © DeNACo.,Ltd. All Rights Reserved.ゲームは更新系クエリがめちゃ多い ボタンを押すだけでステータス更新 体力増減とか ボスへダメージとか アイテム獲得とか
- 18.Copyright © DeNACo.,Ltd. All Rights Reserved. 参照系クエリは Slave に逃せる。 Slave のスケールアウトは容易 更新系クエリは必ず Master にI/O負荷がかかる → Master はボトルネックになりがち
- 19.Copyright © DeNACo.,Ltd. All Rights Reserved.垂直分割AテーブルBテーブルCテーブルDテーブルEテーブルFテーブルGテーブルHテーブルIテーブル テーブルの種類によって DB を分割。 Join 句が使えなくなる。 テーブルへのアクセス数が均等になるように分割しないと負荷が偏る
- 20.Copyright © DeNACo.,Ltd. All Rights Reserved.水平分割 レコードのカラムの値でDBを分割 範囲取得や count, sum が面倒に auto_increment が使えなくなる→採番テーブルを別途用意するAテーブルBテーブルCテーブルAテーブルBテーブルCテーブルAテーブルBテーブルCテーブル↑ID: 1 のレコードはこっち↑ID: 2 のレコードはこっち↑ID: 3 のレコードはこっち
- 21.Copyright © DeNACo.,Ltd. All Rights Reserved.複数のトランザクションを扱う 複数DB へのトランザクションをどう扱うか？ InnoDB の REPEATABLE READ は最初のクエリ発行時に取得できるレコードの値が決定するので、各DBに対して最初のクエリをいつ投げるか意識する必要がある。 コミットタイミングは全て同一で行うのが楽 コミットタイミングが別々だとデータ不整合が起こりやすくなる(片方はコミット済みなのにもう片方はロールバックとか…
- 22.Copyright © DeNACo.,Ltd. All Rights Reserved.アプリケーション開発時に気をつけること 適切なindexとindexを使える適切なクエリ クエリ発行量を減らす 行ロック レプリ遅延対策 Repeatable read の特性
- 23.Copyright © DeNACo.,Ltd. All Rights Reserved.インデックスInnoDB のインデックスは B+ Tree常に一定の深度になるようにバランス化された木構造1レコードの取得に対して O(log N) で探索することができる
- 24.Copyright © DeNACo.,Ltd. All Rights Reserved.オプティマイザオプティマイザとは・・・SQLがどのインデックスを使用し、どの順序でアクセスするかという実行計画（EXPLAIN）を決定するEXPLAIN構文・・・「EXPLAIN SELECT～」とすることで、オプティマイザが選択した実行計画を表示できるUPDATEやDELETEの場合、SELECTに書き換える必要があるmysql> explain select * from test where id = 1;+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+| 1 | SIMPLE | test | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index |+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
- 25.Copyright © DeNACo.,Ltd. All Rights Reserved.オプティマイザMySQLはコストベース・オプティマイザコストベースのオプティマイザでは、統計情報だけなくCPUクロックメモリ容量DISK I/O速度DBMSでのパラメータで実行計画が決定される開発環境と同じ実行計画になるとは限らないデータ件数が違うデータの種類が違うCPUクロックが違うメモリ容量が違うなどMySQL のオプティマイザは実行計画を結構見誤る不安ならばFORCE INDEX で使用するインデックスを指定する
- 26.Copyright © DeNACo.,Ltd. All Rights Reserved.インデックスを使えないケース例ALTER TABLE テーブル名 ADD KEY (col1, col2, col3);・否定WHERE col1 <> 1・2つ目のキーから指定WHERE col2 = 1 AND col3 = 1・カラム側に計算式を使用WHERE col1 * 100 = 100・範囲指定WHERE col1 > 1 AND col2 = 2 （col2はインデックスを使えない）・昇順と降順の混在ORDER BY col1 ASC, col2 DESC（col2はインデックスを使えない）
- 27.Copyright © DeNACo.,Ltd. All Rights Reserved.クエリ発行量を減らす 綺麗に正規化しない(あえて冗長にデータを持つことで 1 query で必要なデータを取得する) あえてカラムを分割する更新が低いが参照の多いテーブルはmemcached にキャッシュする更新が多いテーブルはなるべくカラムを絞って InnoDB の bufferpool に乗るようにする 時限付きデータ(イベントデータ等)は別テーブルにすることでイベント終了後に drop table できるようにする IN句でSELECTSELECT * FROM user WHERE id IN(1, 2, 3, ...); Bulk insertINSERT INTO user values (1,'tanaka'),(2,'yamada'),(3,'hansen'); INSERT INTO … ON DUPLICATE KEY UPDATE …レコードが存在しなければ INSERT 、存在すれば UPDATE を 1query で実行できる。
- 28.Copyright © DeNACo.,Ltd. All Rights Reserved.行ロック 同時操作を常に意識するAさんとBさんが同時にボスを攻撃したら両方ともボスを撃破した扱いになったり…Aさんが2端末使って、同時にアイテムを受け取りを押すことでアイテム増殖できたり… 前者は攻撃時にまずボスレコードをロックして、AさんとBさんの処理を直列させることで防げる 後者はアイテム受け取り時にAさんのレコードをロックして処理を直列させることで防げる ロックの順番を統一しないと、デッドロックが発生する。 必ず存在するレコードに対してロックを取る 存在しないレコードをロックすると、InnoDBの Repeatable Read では gap lock が発生し、広範囲にロックを獲得する。→ lock wait timeout
- 29.Copyright © DeNACo.,Ltd. All Rights Reserved.レプリケーション遅延対策 大量クエリのコミット等でレプリ遅延(master DBへの変更が slaveDBへ反映が遅れること)が発生する 回復アイテムの使用(Masterを更新)→次ページで使用結果を見ると回復していない(Slave にまだ回復の反映が遅れてる)→更新処理後、更新したデータをcacheに詰めて、遷移先で使用する→更新処理後、更新処理から遷移されてきたかどうかを見て、masteror slave のどちらを参照するか決める 1リクエスト内で Slave のデータを元に Master を更新すると、レプリ遅延で古い Slave のデータを参照していてデータの不整合が起こる→更新系のリクエスト内で参照するDB は Master で統一する
- 30.Copyright © DeNACo.,Ltd. All Rights Reserved.KVSとの併用について ゲームデータのキャッシュは難しい 更新を頻繁に行うのでキャッシュクリア処理が面倒 忘れると気づきづらい障害に トランザクションとの整合性 Read Only のデータ(マスタ等)をキャッシュするのが一番楽
- 31.Copyright © DeNACo.,Ltd. All Rights Reserved. ゲームサーバーのデータベースは整合性／負荷との戦い ノウハウを知って急激なアクセス増加にも耐えられる構築／開発をしよう
- 32.Copyright © DeNACo.,Ltd. All Rights Reserved.おわり
Editor's Notes
- #27 インデックス効かない場合の解決策見出しは文字をでっかく