このアプローチを使えば、テーブル4からの大量の読み込みをスキップできるのがおわかりでしょう。

新たなレッジャーのエントリーを格納した後に、新たに計算したデータだけを格納すればいいと思うかもしれません。理論上はそれで良さそうに見えますが、これではデータの不一致とパフォーマンスの劣化につながりかねません。パフォーマンス劣化の一例は、読み込み後に書き込みが必要になることが多いために、再計算とデータ格納でシステムがビジーになることです。この場合は、全てのプレイヤーのために安定したパフォーマンスでゲームを実行することと、計算との間でバランスを取る必要があります。

データの不一致の一例は、対戦終了時の計算です。私たちの用いているサーバーインフラとプラットフォームでは、遅れて届くメッセージにも対応しています。例えば、AとBの2つのデータセンター間で一時的なズレが生じ、プレイヤーにミニのXPを付与するメッセージが、Aからは送信されているものの、Bにはまだ届いていない場合があります。例えば、深夜0時直前に対戦していたとしましょう。あなたが勝利したタイミングは水曜日の23：59だったとします。ロールアップ・プロセッサーが1日1回、現在の日付までの全データをロールアップするように設定されていたとしましょう。これは深夜0時に実行されて、木曜日の0:00までの合計XPの計算を行います。このデータは2つ目のテーブルに格納され、新たにXPを読み込む際には、前回格納された値と、木曜日の0:00以降の全エントリーを合算します。遅れて到着したメッセージに何が起こるかというと、取得はしますが、対戦は水曜日の23:59に完了しており、XPのエントリーはその時間で書き込まれることになります。ロールアップテーブルにはこのエントリーは含まれず、以降のデータへのクエリにもこのエントリーは表示されません。こうした不完全なデータが問題になるわけです。数日後に到着したメッセージはどうなるのでしょうか？これに関しては、私たちはモニタリングやアラートのシステムを用意しており、この新たな情報はほとんどの場合、次のロールアップの時間までには処理されます。

ミニのレベルを算出

合計XPのテーブルを見たときに、ここではレベルが計算されていないことに気付いたでしょうか？テーブル内には、これまでに獲得したXPの合計しかありません。実はこれとは別に、ゲームデザイナーが設定した、以下のような固定のテーブルが存在します。ミニはレベル1から始まり、XPを1ポイント獲得するとレベル2になりますが、レベル3になるにはXPを3ポイント獲得する必要があります。

2つを合わせると、現在までの累計を計算することで、ランタイムでミニの実際のレベルを算出することが可能になります。そして最終的に以下のデータセットが完成します。

こうしておけば、ゲームデザイナーはレベルを1つ上げるのに必要なXP量を自由に変更することができるようになります。低レベル帯でレベルアップするのが難しく感じられたら、次のレベルに到達するために必要なXP量を減らしたりといったことが可能です。そうすれば、データベースに保存されているプレイヤーデータには一切変更を加えることなく、全てのミニが現在のレベルから少しブーストされることとなり、次のレベルに到達するために必要なXP量が減少して、早くレベルアップできるようになります。これは逆の場合でも機能します。ゲームデザイナーがやっぱりレベルの上昇が早すぎると感じて、レベルアップに必要なXP量を増やそうと考えた場合でも、ミニを変更導入前のレベルに戻すためにXPを操作する必要はありません。とはいえ、レベルアップを容易にするために、ミニにXPを付与する選択肢もないわけではありませんが。

採用されなかったアプローチ

ミニの獲得XPの格納と最終的なレベルの計算に関しては、現在の解決策を採る前に様々なアプローチを考慮しました。プレイヤーのXPに変更を加えるための特別なダウンタイムを設ける方法や、進行状況こそ維持しながらも、プレイヤーに良い体験を届けることだけに的を絞った案も考慮しました。

「ミニのレベル、XP、次のレベルに到達するために必要なXP量を常に格納する方法」

単純にスタンダードなSQLパターンを使って、トランザクションアップデートを利用すればどうなるのでしょうか？トランザクションアップデートはデータセット全体をアップデートするため、「ゼロか全てか」です。一か所だけ書き込みできなかった場合は、全てが元の値にロールバックされます。これらはACID特性と呼ばれる、原子性（atomicity）、一貫性（consistency）、独立性（isolation）、永続性（durability）を持っています。

これは1つの行で各ミニのXPと合計レベルを管理するため、読み込みが非常に軽くなります。

ミニがXPを獲得すると、XPが2ポイント、次のレベル到達までに必要なXP量が8ポイント、現在はレベル3としてこのミニがアップデートされます。このタイプの変更はデータを読み込み、再計算し、その後データベースに書き込むことを強制します。このようなパターンではCassandraの長所を活かすことができません。さらにもうひとつの問題は、レベルアップに必要なXP量を変更したい場合、ゲームをオフラインにして全プレイヤーの全ミニのデータを書き換える必要がある点です。

「パーセンテージで格納する方法」

また、次のレベルに到達するまでに必要なXP量をパーセンテージで格納する手法も考慮しました。これは以下のようになります。

そして対戦後に簡単な計算を行います。例えば、ノールの暴れん坊が3ポイントXPを獲得し、パーセンテージは3/10となるので、ではノールの暴れん坊にレベル到達までの30%を付与しようということになって、結果は以下のようになります。

これなら、ミニのレベル上昇曲線に変更を行ってもミニのレベルは変化しないため、一定の自由度が得られます。また、単純にメーターを30%満たすだけで、追加の計算が必要ないことから、ゲームUIのビジュアル表示も容易になります。しかし、レベルが上がってくると、パーセンテージは微々たるものになってきます。例えば対戦ごとに10 XPを獲得しているミニが、次のレベルに上がるのに100,000 XPが必要だった場合、10 XPは0.01%となります。CPUは浮動小数は扱えますが、浮動小数点演算の性質を考慮しないと、正確度と精度の点でバグが発生する可能性があります。

それではまた次回…

援用可能なツールから、データの格納方法と計算方法まで、データベーステクノロジー全般について様々な選択肢が考慮されたこと、おわかりいただけましたでしょうか。全てはまだ開発中ですので、もっといい方法が見つかった場合は、こうした全てが変更される可能性もありますが、このゲームでは、これが良い出発点になると言えそうです。

お読みいただきありがとうございました！

~ アンディ・リム