これまでの連載で見てきたように、
しかしながら、
今回は例として以下のようなチャットアプリケーションを想定し、
- チャットルームが複数存在する
- チャットのメッセージはルームごとに管理する
- 複数ユーザがおり、
ユーザは任意のルームに参加して発言することができる
効率的なデータ構造
データのネストを避ける
FirebaseはJSONのツリーを最大で32階層まで持つことができます。これは一般的なアプリケーションを作るのに十分な深さです。
今回のアプリケーションでは、
{
"chats": {
"room01": {
"title": "チャットルーム01",
"messages": {
"message01": {
"sender": "Fumihiko Shiroyama",
"message": "こんにちは。誰かいますか？"
},
"message02": { ... },
"message03": { ... }
}
},
"room02": { ... }
}
}まず/chatsという階層を作り、/chats/、/chats/のように存在しています。
チャットルームの下には/chats/$room_といった形でルームのタイトルが保存され、/chats/$room_の下には/chats/$room_の形式でルームのメッセージ一覧が保持されており、sender、messageでそれぞれ送信者とメッセージ本文が保存されています。
一見すると何の問題もなさそうなデータ構造ですが、
/chatsにValueEventListenerをセットしてDataSnapshot#getChildren()メソッドを使ってループを回しながら取得する方法などが考えられますが、
Firebaseはあるパスに存在するデータを取得する際に、
できるだけ階層を浅くする
このため、ユーザ一覧、ルーム一覧、本文一覧でツリーを分けることにしてみましょう。
{
"users": {
"shiroyama": { "name": "Fumihiko Shiroyama" },
"tanaka": { ... },
"sato": { ... }
},
"rooms": {
"room01": {
"title": "チャットルーム01",
"members": {
"member01": "shiroyama",
"member02": "tanaka"
}
},
"room02": { ... }
},
"messages": {
"room01": {
"message01": {
"sender": "shiroyama",
"message": "こんにちは。誰かいますか？"
},
"message02": {
"sender": "tanaka",
"message": "はい、いますよ。"
},
"message03": { ... }
},
"room02": { ... }
}
}これでずいぶん良くなりました。
ユーザ一覧が/usersへ、/roomsへ、/messagesへ分かれたので、
ところがこれでもまだ問題があります。もしユーザshiroyamaが自分の参加しているルーム一覧を取得したくなったとしたら、/rooms以下の全ルームをひとつひとつ走査しながら自分がそのルームのメンバーかどうかを確認する必要があります。もしルームが何千と存在すれば、
セキュリティルールはフィルタとしては利用できない
上記の例が良くない理由がもうひとつあります。
前回、
Firebaseでは、
今回の場合、/rooms/$room_以下へのアクセスは、member01だけ成功してmember02は失敗するのではなく、
{
"rules": {
"rooms": {
"$room_id": {
"members": {
"member01": {
".read": true
},
"member02": {
".read": false
}
}
}
}
}
}これは公式ドキュメントにも説明されている仕様通りの挙動なので注意してください。
したがって、
双方向のリレーションを作成する
これらの状況を踏まえて、
{
"users": {
"shiroyama": {
"name": "Fumihiko Shiroyama",
"rooms": {
"room01": true,
"room02": true
}
},
"tanaka": { ... },
"sato": { ... }
},
"rooms": {
"room01": {
"title": "チャットルーム01",
"members": {
"shiroyama": true,
"tanaka": true
}
},
"room02": { ... }
},
"messages": {
"room01": {
"message01": {
"sender": "shiroyama",
"message": "こんにちは。誰かいますか？"
},
"message02": {
"sender": "tanaka",
"message": "はい、いますよ。"
},
"message03": { ... }
},
"room02": { ... }
}
}/users/$user_以下に、/rooms/$room_にもユーザ一覧を保持するようになりました。
こうすることで、
値はいずれもtrueにしていますが、
これは、
残念ながら、/usersの下にも/roomsの下にもいわば重複するデータが存在することになります
しかしながら、
データを結合する
さて、
リレーショナルデータベースでは、
結合から言うと、
まずは以下の例を見てください。
final Firebase messageRef = ref.child("messages");
final Firebase userRef = ref.child("users");
messageRef.child("room01").addListenerForSingleValueEvent(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
for (DataSnapshot snapshot : dataSnapshot.getChildren()) {
final Message message = snapshot.getValue(Message.class);
userRef.child(message.sender).addListenerForSingleValueEvent(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
Log.d(TAG, "message: " + message.message);
Log.d(TAG, "sender: " + message.sender);
User user = dataSnapshot.getValue(User.class);
Log.d(TAG, "sender's full name: " + user.name);
}
@Override
public void onCancelled(FirebaseError firebaseError) {
Log.e(TAG, firebaseError.getMessage(), firebaseError.toException());
}
});
}
}
@Override
public void onCancelled(FirebaseError firebaseError) {
Log.e(TAG, firebaseError.getMessage(), firebaseError.toException());
}
});1～2行目で/messagesと/usersのリファレンスをそれぞれ取得し、/messages/に対してValueEventListenerをセットして6～7行目でメッセージ一覧を取得しています。ここまでは第3回の内容を参考にしていただければ問題ないと思います。
次に、/messages/のループの中でuserRef.に対して更にValueEventListenerをセットして、
リレーショナルデータベースに慣れていると、n+1問題でパフォーマンスが心配になるかもしれませんが、
結局のところ、
なお、
結果的に、
データにIndexを作成する
連載第3回の.indexOnルールを使ってデータにIndexを作成することで、
たとえば、
/rooms/$room_以下にtimestamp情報を追加しましょう。
{
"rooms": {
"room01": {
"title": "チャットルーム01",
"members": {
"shiroyama": true,
"tanaka": true
},
"timestamp": 1464511789
},
"room02": { ... }
}
}このtimestampのIndexを作成するには、
{
"rules": {
"rooms": {
"$room_id": {
".indexOn": ["timestamp"]
}
}
}
}こうすることでtimestampにIndexが作成され、
読み出しのコードは以下のようになります。
Firebase roomRef = ref.child("rooms");
roomRef.orderByChild("timestamp").addListenerForSingleValueEvent(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
for (DataSnapshot snapshot : dataSnapshot.getChildren()) {
Room room = snapshot.getValue(Room.class);
Log.d(TAG, "title: " + room.title);
Log.d(TAG, "timestamp: " + room.timestamp);
}
}
@Override
public void onCancelled(FirebaseError firebaseError) {
Log.e(TAG, firebaseError.getMessage(), firebaseError.toException());
}
});/roomsへのリファレンスを作成し、orderByChild("timestamp")で並び替えているだけです。こちらも、timestampの昇順
なお、".indexOn": ["timestamp", "title"]のようにカンマ区切りで追加するだけです。
デフォルトで作成されるIndex
Indexは、
今回の例では/rooms/$room_の部分はキーなので、
プライオリティ（優先度）
第3回で少し触れましたが、
Firebaseではデータ作成時に、
今回の例では、timestampを符号反転させたものを設定してみましょう。こうすることでtimestampを降順に並べることが可能です。
Firebase roomRef = ref.child("rooms");
roomRef.child("room01").setValue(room01);
roomRef.child("room01").setPriority(-room01.timestamp);詳細は割愛しますが、room01の情報を保存するロジックで、setPriority()してtimestampの符号をマイナスにしたものをセットしているだけです。
読み出すコードは以下のとおりです。
Firebase roomRef = ref.child("rooms");
roomRef.orderByPriority().addListenerForSingleValueEvent(new ValueEventListener() { // 略 }ValueEventListenerの中身は昇順読み出しとまったく同様です。ルーム一覧が降順に並べば成功です。
まとめ
いかがだったでしょうか。
今回はFirebaseのデータベース構造を効率的に設計し、
今回までで、
さて、