Downloaded 184 times
![水平分割
分割ルール
・範囲による振り分け
ある程度意図を持ってバランシングできる
既存データに手をいれずサーバ追加が可能
ただし小回りは効かない
foreach ($range_arr as $range) {
if ($range['min'] <= $id and $id <= $range_info['max']) {
$server_id = $range['server_id'];
break;
}
}](https://image.slidesharecdn.com/socialgamedbslice-130715205921-phpapp01/85/DB-PHP-32-320.jpg)
![水平分割された DB への問い合わせ
__call と call_user_func_array によって実装
DatabaseAccessNode クラスに単一 DB へ問い合
わせる処理を追加すると、
DatabaseAccessMultiNode クラスを経由して複
数 DB に問い合わせもする事ができる
class DatabaseAccessMultiNode
{
function __call($func_name, $args = array())
{
// 各 DB に対して実行
foreach ($this->dban_arr as $key => $dban) {
$tmp_data_arr[] =
call_user_func_array(array($dban, $func_name), $args);
}](https://image.slidesharecdn.com/socialgamedbslice-130715205921-phpapp01/85/DB-PHP-34-320.jpg)
![コミット
まとめてコミットと言っても順番にコミットするだけ
いわゆる 2 相コミットではないため、一部がコミットされ
てしまうと全体のロールバックは不可能
やはり途中でエラーとなった場合はデータ不整合となる
$commited_arr = array();
foreach ($dban_arr as $dban) {
$dban->commit();
$commited_arr[] = $dban->database_name;
}](https://image.slidesharecdn.com/socialgamedbslice-130715205921-phpapp01/85/DB-PHP-46-320.jpg)
![コミット
途中でコミットがエラーとなった場合は、どの DB がコミッ
トされ、どの DB がコミットされていないのかをログに残す
} catch (Exception $e) {
if (0 < count($commited_arr)) {
// 1 度以上コミットしたということはデータ不整合
$uncommited_arr = array();
foreach ($dban_arr as $dban) {
if ($dban->isTransaction()) {
// トランザクション中なら配列に含める
$uncommited_arr[] = $dban->database_name;
}
}
// エラーとなった DB 情報のログを残す
logging(sprintf('commit error commited[%s]
uncommited[%s]', implode(',', $commited_arr),
implode(',', $uncommited_arr)));
}
}](https://image.slidesharecdn.com/socialgamedbslice-130715205921-phpapp01/85/DB-PHP-47-320.jpg)
Uploaded byinfinite_loop
ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装 ～とにかく分割ですよ。10回じゃ足りない。20回くらい分割。～ 株式会社インフィニットループ 佐々木 亨基 2013/7/15にPHPMatsuri2013内で発表された講演のスライド
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
![大切な名前[Intro]公開版](https://cdn.slidesharecdn.com/ss_thumbnails/intro-171030075715-thumbnail.jpg?width=640&height=640&fit=bounds)
ソーシャルゲーム案件におけるDB分割のPHP実装
- 1. 1 ソーシャルゲーム案件における DB 分割の PHP実装 ～とにかく分割ですよ。 10 回じゃ足りない。 20 回くらい分割。～ 株式会社インフィニットループ 佐々木 亨基
- 2. 自己紹介 ・佐々木 亨基 ・ゆきこ yukicon ・Twitter:@yukiconEx ・株式会社インフィニットループ所属 ・札幌 MySQL 勉強会代表 ・ PHP 歴は 4 年くらい ・現在仕事では PHP オンリー ・いい加減な人間なので PHP の緩さは好き
- 3. インフィニットループについて ・北海道札幌市にあるシステム開発会社 約 90 名（契約スタッフ・アルバイト含む）で活動中 社長も含め、ほぼ全員がエンジニア ・主な開発実績（主にサーバサイドを担当） ブラウザ三国志(2009) 英雄クエスト (2010) Lord of Knights(2012) フォトバトラー (2012) Vim 検定 (2012) PHP 検定 (2013) その他いろいろ
- 4. お題目 ■ はじめに ・ DB分割とは ・どうして DB 分割なんかするの？ ・ユーザ単位による水平分割 ・ DB 分割のデメリット
- 5. お題目 ■ 実装のお話 ・クラス設計 ・使用例 ・エイリアス ・水平分割 ・水平分割された DBへの問い合わせ ・トランザクション ・トランザクションの開始 ・コミット ・まとめ
- 6. DB 分割とは 分割していない DB Aテーブル B テーブル C テーブル D テーブル E テーブル F テーブル
- 7. DB 分割とは 分割した DB Aテーブル B テーブル E テーブル F テーブル E テーブル F テーブル E テーブル F テーブル … 垂直分割 ( テーブル単位での分割 ) 水平分割 ( 同テーブルの ID 単位による分割 ) C テーブル D テーブル
- 8. DB 分割とは 更にそれぞれがマスタスレーブ構成を取る Master Master … 垂直分割 ( テーブル単位での分割) 水平分割 ( 同テーブルの ID 単位による分割 ) Slave Slave Slave Master Slave Slave Slave Slave Slave Slave Master Slave Slave Slave Master Slave Slave Slave
- 9. どうして DB 分割なんかするの？ ■要件 数万～十数万の同時接続数に耐えられるシステム ■ 案件の特徴 ソーシャルゲーム案件の規模は予測が難しい 突然跳ねる事もあり、正確な規模が見積もれない
- 10.
- 11. どうして DB 分割なんかするの？ Webサーバは単純なサーバ追加で対応可能 しかし DB は簡単にはいかない ・・・ ×nWeb Web Web Web DB × ？
- 12. どうして DB 分割なんかするの？ DBのスケールアウトと言えばマスタスレーブ構成 Master Slave Slave Slave ・・・ ×n SELECT UPDATE SELECT SELECT
- 13. どうして DB 分割なんかするの？ しかしマスタスレーブ構成のマスタサーバは1 台 マスタサーバの更新性能がネックとなり いずれ限界が来る Master Slave Slave Slave ・・・ ×n SELECT UPDATE SELECT SELECT
- 14. どうして DB 分割なんかするの？ マスタ1 台で数万の同時接続数を捌くのは不可能 要件的にマスタスレーブ構成では破綻する
- 15. どうして DB 分割なんかするの？ ではどうする？ ・Fusion-io のような超高速ストレージを使う？ →用意できるとは限らない →導入しても解決しなかった場合に詰む ・ MySQL Cluster を使う？ →まだ枯れていない技術という印象 →制約も多く、導入は怖い
- 16. どうして DB 分割なんかするの？ マスタスレーブのセットを増やそう! | ＼ __ ／ ＿ （ｍ） ＿ﾋﾟｺｰﾝ | ミ | ／ ｀ ´ ＼ ('A`) ノヽノヽ くく
- 17. ユーザ単位による DB 分割 ユーザ数が増えたならUserDB を追加 Global が苦しくなったら更に垂直分割をする事で スケールアウト可能 User1 User2 User3 … 水平分割された UserDB ユーザに紐付くデータを一定のルールで振り分けて格納 Global GlobalDB ユーザに紐付かない共通のデータを格納
- 18. DB 分割のデメリット ■ 設計でカバーする ・DB 間を跨いだ JOIN ができない → 冗長なデータの持ち方をしてしまう → マスタデータは全 DB に持つなどして対策 ・水平分割すればするほどパフォーマンスが下がる ※とにかく分割とかいうタイトルになってますが あんまり分割しちゃダメです、最低限にしましょう
- 19. DB 分割のデメリット ■ できるだけライブラリ側で吸収する ・水平分割されたDB の串刺し検索が大変 → ユーザ一覧を持ってくるのですら一苦労 ・複数 DB のトランザクション管理が煩雑
- 20.
- 21. クラス設計 3 つのクラスから成っている ・ DatabaseAccess 全DB 、トランザクションを統括するクラス ・ DatabaseAccessNode 単一 DB にアクセスするクラス マスタスレーブの切り替えも行う 分割なしならこのクラスのみで完結 ・ DatabaseAccessMultiNode 水平分割された DB にまとめてアクセスするクラス
- 22. クラス設計 図にすると Master Master … DatabaseAccess Slave Slave Slave Master SlaveSlave Slave Slave Slave Slave Master Slave Slave Slave Master Slave Slave Slave DatabaseAccessNode DatabaseAccessMultiNode
- 23. 使用例 // singleton なインスタンスを取得 $dba= DatabaseAccess::getInstance(); // グローバル DB から SELECT $dba->getDBAN('global')->select('user_id_tbl'); // 対象ユーザ ID のデータがある DB から SELECT $dba->getDBAN('user', $user_id)->select('user_tbl'); // 複数の対象ユーザ DB から SELECT $dban_arr = $dba->getDBANArr('user', $user_id_arr); $dbam = new DatabaseAccessMultiNode($dban_arr); $dbam->select('user_tbl');
- 24. 使用例 // singleton なインスタンスを取得 $dba= DatabaseAccess::getInstance(); // グローバル DB から SELECT $dba->getDBAN('global')->select('user_id_tbl'); // 対象ユーザ ID のデータがある DB から SELECT $dba->getDBAN('user', $user_id)->select('user_tbl'); // 複数の対象ユーザ DB から SELECT $dban_arr = $dba->getDBANArr('user', $user_id_arr); $dbam = new DatabaseAccessMultiNode($dban_arr); $dbam->select('user_tbl'); なんか難しい！
- 25. エイリアス エイリアスをつくって抽象化 class DatabaseAccess { function gb() { //global の DatabaseAccessNode オブジェクトを返す return $this->getDBAN('global'); } function user($user_id) { // user の DatabaseAccessNode オブジェクトを返す return $this->getDBAN('user', $user_id); } : :
- 26. エイリアス // singleton なインスタンスを取得 $dba= DatabaseAccess::getInstance(); // グローバル DB から SELECT $dba->gb()->select('user_id_tbl'); // 対象ユーザ ID のデータがある DB から SELECT $dba->user($user_id)->select('user_tbl'); // 複数のユーザ DB から SELECT $dba->user_multi($user_id_arr)->select('user_tbl'); だいぶすっきり
- 27. エイリアス // singleton なインスタンスを取得 $dba= DatabaseAccess::getInstance(); // グローバル DB から SELECT $dba->gb()->select('user_id_tbl'); // 対象ユーザ ID のデータがある DB から SELECT $dba->user($user_id)->select('user_tbl'); // 複数のユーザ DB から SELECT $dba->user_multi($user_id_arr)->select('user_tbl'); // 全ユーザ DB から SELECT $dba->user_all()->select('user_tbl'); 全ユーザ DB 用のエイリアスも用意すると便利
- 28. 水平分割 ID とサーバ IDをマッピングするテーブルを グローバル DB に作成して管理 CREATE TABLE `id_partition_tbl` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `server_id` tinyint(4) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `server_id` (`id`,`server_id`) ) id server_id 1000 1 1001 2 1002 3
- 29. 水平分割 ID の発行 (仮に server_id を 1 で指定 ) INSERT INTO id_partition_tbl (server_id) VALUE (1); SELECT LAST_INSERT_ID(); ↓ 分割ルールに従ってサーバの割り当て ↓ テーブルへの登録 UPDATE id_partition_tbl SET server_id = 3 WHERE id = 1000;
- 30. 水平分割 分割ルール ・テーブルによる管理 必ずテーブルを参照する必要がある server_id をキャッシュするなどの工夫が必要 登録数の少ないサーバに振り分け 各サーバに重みをつけて振り分け 既存データを意図通りに再配置 など柔軟な対応が可能 $server_id =getServerId('id_partition_tbl', $id);
- 31.
- 32. 水平分割 分割ルール ・範囲による振り分け ある程度意図を持ってバランシングできる 既存データに手をいれずサーバ追加が可能 ただし小回りは効かない foreach ($range_arr as$range) { if ($range['min'] <= $id and $id <= $range_info['max']) { $server_id = $range['server_id']; break; } }
- 33. 水平分割された DB への問い合わせ DatabaseAccessMultiNodeクラスにより実現 複数 DB に同じ SQL を投げ、結果をマージ 使用者は複数 DB への問い合わせである事を意識 せず、単一 DB を扱うのと同様に記述する事がで きる // 単一 DB への問い合わせ $dba->user($user_id)->select('user_tbl'); $dba->user($user_id)->update('user_tbl'); // 複数 DB への問い合わせ $dba->user_multi($user_id_arr)->select('user_tbl'); $dba->user_multi($user_id_arr)->update('user_tbl');
- 34. 水平分割された DB への問い合わせ __callと call_user_func_array によって実装 DatabaseAccessNode クラスに単一 DB へ問い合 わせる処理を追加すると、 DatabaseAccessMultiNode クラスを経由して複 数 DB に問い合わせもする事ができる class DatabaseAccessMultiNode { function __call($func_name, $args = array()) { // 各 DB に対して実行 foreach ($this->dban_arr as $key => $dban) { $tmp_data_arr[] = call_user_func_array(array($dban, $func_name), $args); }
- 35. 水平分割された DB への問い合わせ レスポンスは型によって処理を振り分ける $tmp_data= reset($tmp_data_arr); if (is_numeric($tmp_data)) { // 数値の場合は和を返す $sum = 0; foreach ($tmp_data_arr as $tmp_data) { $sum += $tmp_data; } return $sum; } else if (is_array($tmp_data)) { // 配列の場合はマージして返す $data = array(); foreach ($tmp_data_arr as $tmp_data) { $data = array_merge($data, $tmp_data); } return $data; : :
- 36. 水平分割された DB への問い合わせ user_idをキーにした場合 UPDATE は対象レコードが存在しないため問題無いが User1 (1000-1999) User2 (2000-2999) User3 (3000-3999) UPDATE t SET a = a + 100 WHERE user_id IN (1000, 2000, 3000); UPDATE t SET a = a + 100 WHERE user_id IN (1000, 2000, 3000); UPDATE t SET a = a + 100 WHERE user_id IN (1000, 2000, 3000);
- 37. 水平分割された DB への問い合わせ INSERTは気をつける必要がある User1 (1000-1999) User2 (2000-2999) User3 (3000-3999) INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0); INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0); INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0);
- 38. 水平分割された DB への問い合わせ INSERTは気をつける必要がある User1 (1000-1999) User2 (2000-2999) User3 (3000-3999) INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0); INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0); INSERT INTO t (user_id, a) VALUES (1000, 0), (2000, 0), (3000, 0); 不要なレコードまで INSERT されてしまう
- 39. 水平分割された DB への問い合わせ __callによる実装は、あくまでも全 DB に同じ クエリを投げているだけ レスポンスも型によって機械的に対応している INSERT のようにそれでは問題がある場合は、 専用メソッドを立てて対応する
- 40. トランザクション トランザクションは DB 単位でかかるため 管理に気を使わなくてはいけない //対象のユーザ DB にトランザクション開始 $dba->beginTransactionToUser($user_id); // この更新はグローバル DB への更新のため // トランザクションの対象とならない $dba->gb()->update(); XA トランザクション… うっ…頭が… ( 分離レベルが SERIALIZABLE に限られる、 挙動が怪しいという事で、ミドルウェアに頼らず アプリによる実装としました )
- 41. トランザクションの開始 複数 DB へのトランザクション開始方法は2 通り ・最初にまとめて開始してしまう ・必要になった時点で開始する トランザクションが必要な事がわかりきっている場合は最 初にまとめてしまう方が管理が楽かつ簡単 どれか 1 つでもトランザクションがかかっていれば他の DB も更新処理時に自動でトランザクション状態となるオート モードも用意したが、管理できなくなる懸念があったため 使っていない
- 42. トランザクションの開始 ■ 最初にまとめて開始してしまう場合 トランザクションは短い方が良い コネクションのコストによって無用にトランザクションが 長くならないようにマスタサーバへのコネクションを行 なってからまとめてトランザクションを開始する // 対象のDB をマスタに接続 $dba->gb()->useMaster(); $dba->user($user_id)->useMaster(); // マスタに接続した DB を一斉にトランザクション開始 $dba->myBeginTransactionToConnectionMaster(); Global User コネクション BEGIN コネクション BEGIN Global User コネクション コネクション BEGIN BEGIN
- 43. トランザクションの開始 ■ 必要になった時点で開始する場合 ある DBに対してトランザクションをかけるが、 ある DB に対しては 10 回に 1 回くらいしかトランザクショ ンが必要が無い処理の場合、必要になった時にトランザク ションを開始する 別々のユーザ ID が対象になった際に両方のユーザ ID が同 じ DB に所属している場合など、既にトランザクションが開 始されている事もある // 対象のユーザ DB にトランザクション開始 $dba->beginTransactionToUser($user_id); // たまにしかここに来ないので、ここでトランザクション開始 // 既にトランザクション開始されているならスルーする If ($dba->user($other_user_id)->isTransaction()) { // 同じ DB の場合はここにはこない $dba->beginTransactionToUser($other_user_id); }
- 44. コミット 各 DB に対してバラバラのタイミングでコミットを行うとつ くりが複雑になり、データ不整合となるバグを引き起こす 可能性が高くなる 悪い例 //グローバル DB をアップデート $dba->gb()->update(); // グローバル DB をコミット $dba->commitToGlobal(); // ユーザ DB をアップデート $dba->user($user_id)->update(); // ユーザ DB をコミット $dba->commitToUser($user_id); ここでエラーが起こるとユーザ DB のみ更新されず データ不整合状態となる Global User UPDATE COMMIT UPDATE COMMIT
- 45. コミット コミットは必ず処理の最後にまとめて行うようにする 処理の順番によるデータ不整合に気を配る必要が無くなり コーディングの難易度も下がる // グローバル DBをアップデート $dba->gb()->update(); // ユーザ DB をアップデート $dba->user($user_id)->update(); // まとめてコミット $dba->allCommit(); Global User UPDATE UPDATE COMMIT COMMIT
- 46. コミット まとめてコミットと言っても順番にコミットするだけ いわゆる 2 相コミットではないため、一部がコミットされ てしまうと全体のロールバックは不可能 やはり途中でエラーとなった場合はデータ不整合となる $commited_arr= array(); foreach ($dban_arr as $dban) { $dban->commit(); $commited_arr[] = $dban->database_name; }
- 47. コミット 途中でコミットがエラーとなった場合は、どの DB がコミッ トされ、どのDB がコミットされていないのかをログに残す } catch (Exception $e) { if (0 < count($commited_arr)) { // 1 度以上コミットしたということはデータ不整合 $uncommited_arr = array(); foreach ($dban_arr as $dban) { if ($dban->isTransaction()) { // トランザクション中なら配列に含める $uncommited_arr[] = $dban->database_name; } } // エラーとなった DB 情報のログを残す logging(sprintf('commit error commited[%s] uncommited[%s]', implode(',', $commited_arr), implode(',', $uncommited_arr))); } }
- 48. コミット ログを頼りに手で対応する事になってしまうが 実際データ不整合はほとんど起こらず 1 年で 1回や 2 回という低い頻度のため ログによる対応で問題となった事はない
- 49. まとめ ・エイリアスを用意 ・複数 DB を束ねて管理するクラスを用意 抽象化は重要 抽象化する事で経験の浅いエンジニアでも扱える ・分割ルールは設計段階で破綻の無いように決めておく 必要であれば独自のルールによる振り分けを実装する ・トランザクションの管理もできるだけ簡単にする ・特にコミットはデータ不整合の起こりやすいポイント ・2 相コミットではない ・一部コミットされると全体ロールバックは不可 ・データ不整合はコミット失敗のログを残す事で対応する DB 分割意外となんとかなる でも気をつけるところはちゃんと気をつけないとダメ
- 50. 求人募集 インフィニットループでは、エンジニアを募集しています ・社長も含めほぼ全員がプログラマで技術者に優しい環境 ・勤務地は北海道札幌市、他社出向などは無し ・おいしい食べ物、自然いっぱい、花粉少ない、涼しい ・短い通勤時間、徒歩や自転車で通勤が可能 ・ U ターン、I ターン大歓迎 ・ PHP 開発エンジニア ・スマホ開発エンジニア ・ MySQL エンジニア ・インフラエンジニア
- 51.