データストアはスキーマレスなデータベースとなっています。さらにデータベースで言うテーブル相当についても、リクエストした際になければ作るといった仕組みになっています。そのため、今回紹介するようなちょっと無茶な使い方もできてしまいます。
ユーザごとにテーブル（クラス）を分ける
ユーザごとにデータを厳密に分けたい、という時に使えます。 User_Taro 、 User_Hanako といったユーザ名を使ってテーブル（クラス）を動的に作れます。大量のデータでない場合はACLでの制御がオススメです。アプリがプラットフォームになっており、ユーザがさらに自分独自のユーザを集めているといった場合には、この方法が便利です。
ログに使う
ログは刻々とデータが追加されるので、一つのクラスに保存すると数千万行ものデータが入ってしまいます。それを防ぐために、ログを保存するテーブル（クラス）を年月ごとに分けてしまう方法があります。 LOG_201904 、 LOG_201905 とプログラム側でクラス名を動的に指定してあげるだけです。集計する際にはログクラス全体を対象にする必要がありますが、データが分割されている方が検索も速いでしょう。
iOS/Androidを分けたプッシュ通知を作る
プッシュ通知を作成する際に、相手のデバイスがiOSかAndroidかチェックして文面を分けて配信したいことがあるかも知れません。しかし、そのフローは以下のようになり、APIを2回コールする必要があります。
- 対象データの取得
- 処理分けしてプッシュ通知作成
その場合、相手のデバイスが何であるか気にせず、次のように作成してしまう手があります。
- iOSをターゲット指定してプッシュ通知作成
- Androidをターゲット指定してプッシュ通知作成
このようにしてもAPIコール数は2回です。一つはムダになってしまうかも知れませんが、処理分岐をしない分コードは簡単になるでしょう。
一つのデータに紐付く大量のデータは配列で管理する
データストアはリレーションをサポートしていますが、本来のNoSQL的な使い方とは言えません。データストアは配列やオブジェクトをサポートしていますので、あえてリレーションを組むことなくデータを配列として保存してしまうのが便利です。
常に配列カラムは必要ない、という場合には別クラスにしておくとデータ転送量が減らせます。
行ごとにデータ型を変える
アプリの設定などで便利です。通常のデータベースではカラムごとに文字列や数字など、データ型は決まっています。そのため大抵は文字列で保存しておくでしょう。データストアの場合、同じカラムであっても行ごとにデータ型を変えられます。そのため設定項目ごとに最適なデータ型で保存しておけます。
まとめ
データストアではRDBMSのように正規化を行って、細かくテーブルを分割するような運用はあまりオススメしません。API経由で、複雑なクエリを書けないので、クラスを分割する度にネットワークアクセスが増えてしまいます。また、データを1,000件取得する処理よりも、一つのカラムに1,000件のデータを入れてしまった方が検索は高速になります。
制約は多いですが、クラスがなければ動的に作るなど便利な面もあります。ぜひデータストアらしい使い方でアプリ開発を行ってください。
