プッシュ通知のテーブル設計の考え方

プッシュトークンの性質を考慮したデータベース設計が必要となります。

プッシュトークンの性質を理解する

プッシュトークンは以下のような性質を持っています。このような性質を理解してテーブルを設計することが重要です。

アプリと端末の組み合わせで発行されます。
不定期に変更される場合があります。
無効になったプッシュトークンは、プッシュを送信したとき、もしくはフィードバックサービスに接続したときに無効になっていることを検出することができます。
アプリをアンインストールした場合や、長期にわたってアプリが使用されていないと無効になります。
アプリを再インストールすると新しく発行され直します。(iOS では iOS 9 以降)
サービスの構造によっては 1デバイス＝1トークンでない可能性があります。
- 例えば、同じユーザーが iPhone と iPad からログインする場合があります。
- また、家族共有のタブレットで、複数のユーザーがログインするアプリという場合もあります。

実際のテーブルの構成例をいくつかご紹介します。

単純に全体配信を行うだけであれば、1テーブルのみで構成できるでしょう。

端末テーブルのスキーマ

このテーブルを使い、以下のように管理します。

アプリの初回登録時は、プッシュトークンのみをアプリ向けAPIへ送ります。サーバーは端末を特定するキーを発行し、端末に返します。
アプリでプッシュトークンの更新を検知したときは、端末キーとトークンをアプリ向け API へ送ります。サーバーは端末キーに対応するプッシュトークンを更新します。
- このとき、無効化日時が入っている場合はNULLにします。
- 対応する端末キーがない場合は、無効化されて時間が経ちすぎたものが再起動したと判断できるので、アプリにエラーを返すか、そのまま再発行するなどして再登録します。
プッシュを送信するときは、無効化日時に日時が入っていないトークンを取得し、送信します。
プッシュ送信時に無効トークンとして結果が戻ってきたり、iOSのフィードバックサービスで得られた無効トークンに対応するデータには無効化日時をセットします。
定期的に無効化日時が一定以上過ぎたデータを削除します。サービスの形態にも寄りますが、概ね3ヶ月以上超えたデータは削除しても良いでしょう。

ユーザーがログインをして使う形態のアプリでは、ユーザと端末を別テーブルで管理します。

先ほどのシンプルな例に加え、ユーザー ID の外部キーが追加されています。端末の登録については、シンプルな例と変わりませんが、以下のような処理が加わります。

ユーザーがログインした時に、端末をユーザーと紐付けます。
- アプリの形態によってはログインよりも後にプッシュトークンが来る場合がありますので、トークン登録 API でもユーザーを紐付けられるように考慮する必要があります。
ユーザーがログアウトしたときは、端末テーブルの外部キーから値を削除して関連づけを解除します。
プッシュを送信するときは、対象となるユーザーの端末全てにデータを送信します。

データベースからのデータの抽出速度は、そのままプッシュ通知の性能となります。いかに BoltzEngine が高速に配信することができても、データベースアクセスが時間を取ってしまった場合はシステム全体で十分な性能を確保することができません。

データベースを使った開発の一般的な留意事項ではありますが、以下のような点に注意してください。