SlideShare a Scribd company logo
1 of 102
Download to read offline
分割と整合性をがんばる話 
ソーシャルゲームの整合性対策
自己紹介 
清水 佑吾 
@yamionp 
株式会社 gumi 勤務 
Python歴約2年半 
サーバーさわりはじめて約10年 
前職はISP
水平分割がやりたくて転職
関わったもの 
HTML + FlashLite 
Cocos2d-x
使用環境 
Python 2.7 
Django 
MySQL 5.5/5.6 (RDS) 
Redis 
RabbitMQ
アジェンダ 
2012年前期 負荷対策 
2012年中期 トランザクション 
2012年後期 デッドロック
負荷対策期
サービスがヒット 
更新処理が限界に 
当時最強のインスタンスを用意 
もう大丈夫! 
・・・が、ダメっっ!
というわけで
Player 
RDB 
Master Trade Guild Friend 
KVS 
Memcache 
TokyoTryant
垂直分割 
機能単位で格納先DBを変える 
性能問題に突き当たる度に分割対象を選定 
外部キーを外して別DBに移すだけの簡単なお仕事 
1機能に負荷が集中すると対処不能 
KVSにもじゃんじゃん逃す
機能をまたがる処理 
Friend フレンドが増えたので Player 
ポイントUP 
Friend ++ 
Point +10 
save 
フレンドが増えたのに save 
rollback 
ポイントが増えないい… 
失敗!
同時に使う機能は分割できない 
負荷の多いPlayer/Card/Quest/Itemの分割が難しい 
たとえ分割しても負荷は変わらないことも
そこで
Player 
RDB 
Master Guild 
Trade Friend 
KVS 
Memcache Redis 
カード等のCache 体力等
性能問題には一定の解決をみた
が…
多発する不整合 
消えた更新 
なぜか消えるカード 
なぜか増えるカード
増えるカード
プレイヤーをまたがる処理 
Player A Player B 
Trade 
Card Delete 
Card Add 
save 
save 
失敗! 
rollback 
こちらは残ったまま
消えるカード
ユーザー「合成したらカードが消えたんですが!
プレイヤーをまたがる処理 
Shard1 
ID:1 PlayerA 
Shard2 
- ID:1 PlayerC
プレイヤーをまたがる処理 
Shard1 
ID:1 PlayerA 
Shard2 
ID:1 P la y e r C - 
上書き!
分割キーを消してはいけない
機能をまたぐ場合の問題も 
残ったまま
ただし負荷は下がった 
高負荷状態にならないのでエラーも少ない 
ログだけ丁寧に仕込んで個別ケース対応 
KVSに大事なデータを置かない 
ゲームに致命的にならない範囲でエラー時はユーザー 
が得になる方に倒す 
バグは直す
そして新プロジェクトへ
アジェンダ 
2012年前期 負荷対策 
2012年中期 トランザクション 
2012年後期 デッドロック
不整合と戦う
偉い人「100万人きても大丈夫なようにしといて!」
1から抜本的に見直し 
負荷は水平分割で対処する 
XA Transactionによる一貫性担保 
ロックによる排他制御
水平分割を前提とした構成
全部DBにいれる 
Guild 
RDB Player
マスターデータはjson化 
変更がないのでデプロイ時にAppサーバーに配布 
メモリ上に展開するので非常に高速 
ますますキャッシュレスに
DBのみで実装する 
プレイヤーに紐づくデータはすべてDBに 
自動回復系ステータス(体力、BPなど)もDB 
トランザクションに収められる! 
正規化を徹底
自動回復系ステータス
RDB 
いままではKVSに格納 
Master Guild 
Player 
Trade Friend 
KVS 
Memcache Redis
よくおきる不整合 
お金追加 
体力減算 
失敗! 
begin 
commit 
rollback
自動回復系ステータス
今まではKVSに格納していた 
DBだけ更新、KVSだけ更新がおきていた 
ユーザーに得になる場合は裏技として2chで祭り 
ユーザーの損になる場合はCSが爆発する 
KVSだけ更新というパターンは0 
ほとんどの場合お金かアイテムかカードが一緒に増える 
KVSに居るメリットが実は無い
実装 
現在値、最大値、最終更新時刻を持つ 
最終更新時間と現在値から自動回復済の値を計算し 
て使う 
減算時のみUPDATE
正規化
正規化 
意味の重複する値を保存しない 
レベルの値は無く、合計経験値のみ保存 
参照時に経験値からレベルを計算 
レベルからパラメータを計算。
Before 
id int 
card_id int 
hp int 
attack int 
defense int 
magic_attack int 
magic_defense int 
exp int 
level int
After 
id int 
驚きのダイエット 
card_id int 
効果! 
exp int
XAトランザクション
普通のトランザクション 
begin; 
SELECT…; 
INSERT INTO…; 
commit; 反映
XAトランザクション 
DB1 DB2 
xa begin 
SELECT…; 
INSERT INTO…; 
xa end 
反映 
xa prepare 
xa commit 
xa begin 
SELECT…; 
INSERT INTO…; 
xa end 
xa prepare 
xa commit 
commit 
成功を保証
prepare 
prepare 
prepare 
prepare 
prepare 
prepare 
App
commit 
commit 
commit 
prepare 
prepare 
prepare 
App 
commit 
commit 
commit
もし途中でエラーになったら
prepare 
prepare 
prepare 
prepare 
App prepare 
失敗! 
rollback
rollback 
rollback 
rollback 
prepare 
App prepare 
rollback
無事に処理前の状態に!
複数のDBを跨ったtrxが可能 
XAに参加するいずれかの段階でエラーが起これば 
ロールバックが可能 
複数DBの状態が 処理成功 or 処理なし のいずれかの 
みを保証できるようになった 
中途半端な状態がなくなる 
体力のみ減る、カードだけ増えるなどがなくなる
が、 
DjangoはXA Transactionに非対応 
水平分割にも非対応 
自社開発!
これらを簡単に使うために 
エラーハンドリングを毎回書くのは無駄 
スキル的にもきびしい 
トランザクションに何を含めるかだけ書けるように
エンジニアが書くべきこと 
トランザクションに何を含めるか 
範囲はモデルの機能ではなくリクエストごとに決 
まる 
最適なロック順番は個別の処理ごとに異なる 
ロック・トランザクションを要求する
# player1とplayer2のDBにトランザクション開始 
with commit_on_success([player1_id, 
player2_id]): 
# ロック付きで取得 
player1 = Player.get_for_update(player1_id) 
player2 = Player.get_for_update(player2_id) 
# 減算を実行 
player1.decrement_ap(5) 
player1.increment_money(10) 
player2.decrement_money(10)
def increment_ap(self, quantity): 
# 自身がロック済みであることを要求 
self.require_for_update() 
# 減算 
self.ap -= quantity 
# UPDATE 
self.save()
入れ子のトランザクションを扱えない 
トランザクションに何を含めるかはモデルにはわか 
らない
ちなみに
commit途中で死んだら?
commit 
commit 
commit 
prepare 
prepare 
prepare 
App 
commit 
突然の死!! commit
commit 
commit 
commit 
XA Recover 
pcorempmariet 
cron
処理を完遂!
というのが理想 
innodbのxaは切断時にpreparedだと勝手にrollbackし 
てしまう 
2005年ぐらいから指摘されていて、patchも送られた 
が、patchの取り込みに失敗 
どうしようもない
ログベースの個別対応orz
ある日の夜 
イベントリリース! 
しばらくは問題なく動作していたが… 
ページが開けない!と苦情が
CloudWatch 
AppサーバーCPU使用 
率もリクエスト数も問 
題ないが... 
DBのCPU使用率が張り 
付いていた
即JetProfilerを起動 
ç
テキスト 
クリック一つて即Eplain 
グラフィカル&レーティングしてくれる。 
DBにくわしくなくてもいかにもダメそうな感じ
インデックスがなかった 
特定クエリが処理時間の9割以上を占めていた 
緊急メンテに入りインデックスを追加 
インデックスをはったら5%以下に
ほとんど同じ状況で 
別パターン
無駄インデックス問題 
特定クエリが処理時間の3割以上を占めていた 
スローではないが一クエリ当たりの時間が多い 
Explainしたら index merge 
インデックスを削除したら100倍高速化
アジェンダ 
2012年前期 負荷対策 
2012年中期 トランザクション 
2012年後期 デッドロック
排他制御 
ロック 
CAS
CASの話はしません
ロック 
innodbはレコードロックが可能 
ロックの実現にはインデックスが使われる 
存在するインデックスより狭い範囲のロックはでき 
ない
ロック範囲 
PrimaryKey Index 
ID player_id value 
1 401 A 
2 401 B 
3 402 B 
4 403 C
SELECT * 
FROM player 
WHERE player_id = 401 
FOR UPDATE
ロック範囲 
PrimaryKey Index 
ID player_id value 
1 401 A 
ロック範囲 
2 401 B 
3 402 B 
4 403 C
SELECT * 
FROM player 
WHERE value = “B” 
FOR UPDATE
ロック範囲 
PrimaryKey Index 
ID player_id value 
1 401 A 
2 401 B 
期実待際すのるロロッックク範範囲囲 
3 402 B 
4 403 C
実際のロック範囲はオプティマイザーの気分次第 
必要なインデックスが無いと不必要に大きな範囲の 
ロックをとってしまう 
インデックスが無駄にあると意図しないインデック 
スを使われてロックをとられてしまう
何が起きるか
ある日 
ゲームが重い 
画面が開けない 
レイドボスを攻撃したのに重くて叩けなかった 
イベントが動かない!
生涯発生中に自分がプレイしても得に問題なかった 
だがエラー報告が大量発生 
サーバー負荷は大したことなかった 
CPU/RAM/Disk/Networkすべて低レベル 
ロードバランサーのレスポンスタイムがどんどん劣化
JetProfiler
ロック状態
何が起きていたか 
デッドロックによってロック待ちとタイムアウトが 
発生
ロック 
ID player_id value 
1 401 A 
2 401 B 
3 402 B 
4 403 C 
App 
1 
2
デッドロック 
ID player_id value 
1 401 A 
2 401 B 
3 402 B 
4 403 C 
App 
1 
デッドロック 
App 2
MySQLさんは親切 
同じDB内のデッドロックは検知して解除してくれる 
分割しているとMySQLは検知できない 
XAでトランザクションをまとめているので複数DBに 
またがって止まる
回避するには 
ロック順番を統一する 
ロックする前にソート(id, Player_id,) 
DBをソート 
テーブルをソート 
レコードをソート 
大きくロックを取る player単位、レイドボス単位
参照処理に更新を混ぜない
負荷も跳ね上がる。更新にはほとんどの場合ロック 
が必要 
参照がロックをとる 
ロック機会の圧倒的増大 
デッドロック祭り 
止まってしまうサービス 
まってくれない終電
MySQL「XAはSERIALIZABLE」 
どのみち更新に必要なデータはFOR UPDATEで取得 
する必要がある 
じつはいらなくね・・・? 
REPEATABLE READにしたら速度もあがって問題なく 
なりました
まとめ 
単にKVSに移すのは問題の先延ばしにしかならない 
きちんと使えばRDBだけで十分さばける 
マスターオンリー障害対策用のSlaveはいるがクエリは裁かない 
デッドロック対策の前に適切なインデックスを 
インデックスショットガン。だめ、絶対。 
NewRelicとJetProfilerは神超オススメです
ご清聴ありがとうございました
質疑応答

More Related Content

What's hot

イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
 

What's hot (20)

ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
 
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
 
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
 
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
Cloud runのオートスケールを検証してみる
Cloud runのオートスケールを検証してみるCloud runのオートスケールを検証してみる
Cloud runのオートスケールを検証してみる
 
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
 

Viewers also liked

ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方
Daisaku Mochizuki
 

Viewers also liked (12)

MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
 
Imprementation of realtime_networkgame
Imprementation of realtime_networkgameImprementation of realtime_networkgame
Imprementation of realtime_networkgame
 
負荷がたかいいんだから~♪(仮)
負荷がたかいいんだから~♪(仮)負荷がたかいいんだから~♪(仮)
負荷がたかいいんだから~♪(仮)
 
サーバーのおしごと
サーバーのおしごとサーバーのおしごと
サーバーのおしごと
 
Fluentd and Embulk Game Server 4
Fluentd and Embulk Game Server 4Fluentd and Embulk Game Server 4
Fluentd and Embulk Game Server 4
 
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Halo2 におけるHFSM(階層型有限状態マシン)  【ビヘイビアツリー解説】Halo2 におけるHFSM(階層型有限状態マシン)  【ビヘイビアツリー解説】
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
 
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜 リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
 
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
 
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤とEmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
 
自宅で出来る!ゲームサーバの作り方
自宅で出来る!ゲームサーバの作り方自宅で出来る!ゲームサーバの作り方
自宅で出来る!ゲームサーバの作り方
 
ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方
 
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
 

Similar to 分割と整合性と戦う

S2dao Seminar in tripodworks
S2dao Seminar in tripodworksS2dao Seminar in tripodworks
S2dao Seminar in tripodworks
tripodworks
 
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Insight Technology, Inc.
 
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1
Makoto Haruyama
 
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD PatternApplication Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Atsushi Kambara
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
hideki hasegawa
 

Similar to 分割と整合性と戦う (20)

Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築
 
Java/Androidセキュアコーディング
Java/AndroidセキュアコーディングJava/Androidセキュアコーディング
Java/Androidセキュアコーディング
 
Inside mobage platform
Inside mobage platformInside mobage platform
Inside mobage platform
 
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
 
S2dao Seminar in tripodworks
S2dao Seminar in tripodworksS2dao Seminar in tripodworks
S2dao Seminar in tripodworks
 
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説MongoDB Configパラメータ解説
MongoDB Configパラメータ解説
 
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
 
Asakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for HadoopAsakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for Hadoop
 
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
 
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1
 
Groovyで楽にSQLを実行してみよう
Groovyで楽にSQLを実行してみようGroovyで楽にSQLを実行してみよう
Groovyで楽にSQLを実行してみよう
 
ソーシャルゲームの為のデータベース設計
ソーシャルゲームの為のデータベース設計ソーシャルゲームの為のデータベース設計
ソーシャルゲームの為のデータベース設計
 
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD PatternApplication Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
 
Edge os(vyos)の基本(入門編)
Edge os(vyos)の基本(入門編)Edge os(vyos)の基本(入門編)
Edge os(vyos)の基本(入門編)
 
コンテナ時代にインフラエンジニアは何をするのか
コンテナ時代にインフラエンジニアは何をするのかコンテナ時代にインフラエンジニアは何をするのか
コンテナ時代にインフラエンジニアは何をするのか
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
 
最速C# 7.x
最速C# 7.x最速C# 7.x
最速C# 7.x
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
 

分割と整合性と戦う