1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

firestoreの考察

Posted at

最近firestoreの使い方について調べてたので考察です。
元の記事はこちらです。

考察のまとめ

考察は以下のような感じです

  • データベースの拡張性について
  • データを小分けにする
  • 重複するデータを活用する
  • リレーションデータを作成する
  • 検索が弱い
  • 注意すべきところ

データベースの拡張性について

まずデータベースのスペックに関してですが、Google側で自動的にスケールアウトしてるので特に意識する必要がないです。アクセスがスパイクしても難なく対応できますが、読み込めば読み込むほど料金はかかるので、効率的にデータへアクセスすることを考える必要があります。(googleに寄付したい場合は別ですが)

データを小分けにする

1ドキュメントで持つことのできるデータ量は1MBが上限らしいです。レストランの住所や電話番号のようにそのデータの属性ならそのドキュメントで持つことがいいですが、訪問したレストランの履歴など増えていくデータを持ちたいとか考え出すと話は異なります。その場合はそのドキュメントにサブコレクションを作成してデータ量の少ないドキュメントを作成した方が安全だと思います。

重複するデータを活用する

firestoreはRDSと違ってデータを重複させて持つことがあるらしいです。ほんまかいな。ということは、ユースケースを考えてトップレベルのコレクションにするかサブコレクションにするか吟味する必要がありそうだと思いました。また、更新処理がめんどくさくなりそうなので、関連するサブコレクションで持っておいた方が処理が楽になるかと思います。例えば、ユーザがレビューしたレストランの情報をサブコレクションとして持つと更新時に必要な箇所を取得することができて全てのレストランの全てのレビューを見て対象箇所を見つけて更新する手間が省けるかと思う。

リレーションデータを作成する

firestoreにはjoinはありません。なので、重複するという特徴を使ってドキュメントにリレーション用のサブコレクションを作成すると効率的にデータにアクセスできるかと思います。全てのコレクションから対象のデータを検索して、その中身を取得するよりいいのではないでしょうか?

検索が弱い

条件指定の方法はこちらのリンクを見てもらうとわかりやすいです。

firestoreは以上、以下などの条件で絞ることはできますがlikeのような条件で絞ることができません。

注意すべきところ

スキーマレスで拡張性が高いfirestoreはデータ構造を変更する際に簡単に変更することができます。要件が変わりやすいベンチャー企業などのシステムには最適ですが、仕様書などにどのような項目があるか残していかないと後々問題になっていくと思います。

サンプルデータ

チャット機能

チャット機能について考えてみます。
まず、ユースケースについて考えてみます。
LINEやマッチングアプリでは会話の一覧があり、その中にメッセージ投稿するので、以下のユースケースが考えられます。

  • チャットの一覧を見る
  • チャットの詳細を見る
  • メッセージを投稿する

まず、ChatRoomCollectionを作成してそこにチャットを作成します。
/ChatRoomCollection/{chatRoomDocument}

{
    "id" : "testId",
    "chat_name" : "テストのチャット",
    "latest_message" : "最新のメッセージです。",
}

そこにチャットのドキュメントを作成して、そのサブコレクションに会話データを入れていきます。
これが実際の投稿するメッセージのデータになります。
/ChatRoomCollection/{chatRoomDocument}/ChatCollection/{chatDocument}

{
    "id" : "testChatId-0001",
    "post_user_id" : "userId001",
    "text" : "こんにちわ、私はテストです。",
    "create_datetime" : "2022-01-01 00:00:00",
}

このようにすることで、コレクションから対象の会話データを絞り込む必要がなくなります。

ChatCollectionと同じ階層にこんな感じでユーザデータを登録すると参加しているユーザが取得しやすいですね。
/ChatRoomCollection/{chatRoomDocument}/UserCollection/{userDocument}

{
    "id":"user1",
    "enable":"false",
    "auth":"admin",
}

次に各ユーザのサブコレクションにリレーションデータを登録します。
/UserCollection/{UserDocument}/ChatRelationCollection/{ChatRelationDocument}
UserDocumentはとりあえずこんな感じですかね

{
    "id":"user1",
    "name":"テスト太郎",
    "email":"taro.test@gmail.com",
}

ChatRelationDocumentはこんな感じです。
このデータはユーザがチャット一覧を見る際に使うユースケースで使う想定です。

{
    "id":"chatRelation-001",
    "chat_id":"testChatId-0001",
    "show_flg":false,
}

とりあえず今回はこんな感じです。
違う機能も気が向いたら記載していこうと思います。

まだ開発で使ったことがないので、意見をいただけると助かります。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?