ゲームエンジニアのためのデータベース設計

12. Copyright © DeNA Co.,Ltd. All Rights Reserved. リレーショナルデータベースとは  データを行と列の組み合わせによる表で表す  複数の表と表を関係(リレーション)によって組み合わせられる ID 名前攻撃力防御力 1 Aさん 100 100 2 Bさん 200 150 ユーザーID アイテムID 所持数 1 1 1 1 2 3 1 3 5 ユーザーテーブルアイテム所持テーブルユーザーテーブルの情報から Aさんがどのアイテムを何個所持しているか取得することができる。

13. Copyright © DeNA Co.,Ltd. All Rights Reserved. ACID特性  Atomicity 原子性トランザクションの操作は全て実行されるかまったく実行されないかのどちらか  Consistency 一貫性トランザクション開始時と終了時にデータの整合性が保たれる  Isolation 独立性他のトランザクションによる操作の影響を受けない  Durability 永続性コミットしたトランザクションのデータは保存される

14. Copyright © DeNA Co.,Ltd. All Rights Reserved. ゲームデータの特徴  ユーザーを primary key としたレコードが多い  永続データと期間限定データ(イベントのデータ等)がある  マスタデータ(read only)が多いアイテムマスタ、ボスマスタ、ボス出現マスタ etc…  レコードの状態更新が多いボスのHP減少、HP回復、マップ移動 etc…  可用性・整合性は大切ゲームがプレイできない、アイテムを使用したのに回復していない等の不具合・障害に対して、課金しているユーザーの温度感は非常に高い

20. Copyright © DeNA Co.,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 © DeNA Co.,Ltd. All Rights Reserved. 複数のトランザクションを扱う  複数DB へのトランザクションをどう扱うか？  InnoDB の REPEATABLE READ は最初のクエリ発行時に取得できるレコードの値が決定するので、各DBに対して最初のクエリをいつ投げるか意識する必要がある。  コミットタイミングは全て同一で行うのが楽  コミットタイミングが別々だとデータ不整合が起こりやすくなる(片方はコミット済みなのにもう片方はロールバックとか…

25. Copyright © DeNA Co.,Ltd. All Rights Reserved. オプティマイザ MySQLはコストベース・オプティマイザコストベースのオプティマイザでは、統計情報だけなく CPUクロックメモリ容量 DISK I/O速度 DBMSでのパラメータで実行計画が決定される開発環境と同じ実行計画になるとは限らないデータ件数が違うデータの種類が違う CPUクロックが違うメモリ容量が違うなど MySQL のオプティマイザは実行計画を結構見誤る不安ならばFORCE INDEX で使用するインデックスを指定する

26. Copyright © DeNA Co.,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 © DeNA Co.,Ltd. All Rights Reserved. クエリ発行量を減らす  綺麗に正規化しない(あえて冗長にデータを持つことで 1 query で必要なデータを取得する)  あえてカラムを分割する更新が低いが参照の多いテーブルはmemcached にキャッシュする更新が多いテーブルはなるべくカラムを絞って InnoDB の buffer pool に乗るようにする  時限付きデータ(イベントデータ等)は別テーブルにすることでイベント終了後に drop table できるようにする  IN句でSELECT SELECT * FROM user WHERE id IN(1, 2, 3, ...);  Bulk insert INSERT INTO user values (1,'tanaka'),(2,'yamada'),(3,'hansen');  INSERT INTO … ON DUPLICATE KEY UPDATE … レコードが存在しなければ INSERT 、存在すれば UPDATE を 1 query で実行できる。

28. Copyright © DeNA Co.,Ltd. All Rights Reserved. 行ロック  同時操作を常に意識する AさんとBさんが同時にボスを攻撃したら両方ともボスを撃破した扱いになったり… Aさんが2端末使って、同時にアイテムを受け取りを押すことでアイテム増殖できたり…  前者は攻撃時にまずボスレコードをロックして、AさんとBさんの処理を直列させることで防げる  後者はアイテム受け取り時にAさんのレコードをロックして処理を直列させることで防げる  ロックの順番を統一しないと、デッドロックが発生する。  必ず存在するレコードに対してロックを取る  存在しないレコードをロックすると、InnoDBの Repeatable Read では gap lock が発生し、広範囲にロックを獲得する。 → lock wait timeout

29. Copyright © DeNA Co.,Ltd. All Rights Reserved. レプリケーション遅延対策  大量クエリのコミット等でレプリ遅延(master DBへの変更が slave DBへ反映が遅れること)が発生する  回復アイテムの使用(Masterを更新)→次ページで使用結果を見ると回復していない(Slave にまだ回復の反映が遅れてる) →更新処理後、更新したデータをcacheに詰めて、遷移先で使用する →更新処理後、更新処理から遷移されてきたかどうかを見て、master or slave のどちらを参照するか決める  1リクエスト内で Slave のデータを元に Master を更新すると、レプリ遅延で古い Slave のデータを参照していてデータの不整合が起こる →更新系のリクエスト内で参照するDB は Master で統一する

ゲームエンジニアのためのデータベース設計

sairoutine

ゲームエンジニアのためのデータベース設計