Firestore（firebase サービス内の NoSQL）を使ってみたいと思ったので調べてみた。
https://firebase.google.com/docs/Firestore
qiita.com のリンク先を参考にした。
NoSQL の概念について
Firestore 以前に NoSQL についてあまり知見がなかったので調べた。
NoSQL データモデリング技法 · GitHub は NoSQL のお気持ちというか概念が体系的にまとまっていた。
非正規化
非正規化することで IO の高速化を得る。
- メリット：クエリの IO の速さ、クエリがシンプルに
- NoSQL の方が IO は早くなる
- 正規化されていないので設計によるが、クエリがシンプルになりやすい、
- application 側で必要な情報を、冗長化して保持する。
- デメリット：トータルデータのボリューム
- 正規化されていないのでトータルのデータは増える
集計
- RDB でいうクエリ結果に近いものをレコードとして保持
アプリケーションサイド Join (Application Side Join)
- クエリで join するのでなく、application 側で join
Firestore のリレーション仕様を確認
NoSQL というより、Firestore のリレーションの仕様がざっくり書いてある。
- 通常の kvs とは異なる
- ドキュメントデータベース
- redis のようなイメージでクライアント側で join するイメージだったが、クレリ発行が出来リレーションが可能
- クエリについてはまだきちんと理解できていないので逐次調べる必要がありそう。
- Key
- Reference
- SameID
- Query 横断的に Query を行える Read のセキュリティルールは必ず全員に公開する必要がある
- SubCollection セキュリティの設定が容易 ネストしている親をまたいで検索は行えない
- CollectionGroup ネストしている親をまたいで検索を行える 横断範囲が広くセキュリティの設定が難しい
- Junction Collection 横断的にリレーションシップの検索を行える
- ReferenceCollection リレーションシップを持っている状態を隠せる ネストしている親をまたいで検索は行えない
- マイグレーションについて
- 検索
- 弱い
- サーバー停止できない
- クライアント側に停止ロジックを入れる
- 強制アップデートなどのロジックを入れる
Firestore のデータ構造について
データ構造や実際のクエリの書き方がまとまっていた。
- コレクション > ドキュメント > サブコレクション > データ
- コレクション
- データベースのルート要素で、ドキュメントの集合。配下のドキュメントは一意な名前を持つ。
- ドキュメント
- データおよびサブコレクションの集合。
- サブコレクション
- サブコレクション
- ドキュメント配下に存在するコレクション。コレクションと同じく、ドキュメントを配下にとることが出来る。
- 親のドキュメントを削除しても、サブコレクション自体は破棄されない。削除するには手動で消さないといけないという点だけは注意が必要。
- データ
- キーとバリューのセット
- トランザクション / batch
設計で注意したほうがよさそうな箇所
細かく記載されていて勉強になった。
- クライアント側で batch より Cloud Functions でコピーしたほうがよさそう
- 仕様変更後のメンテナンス楽そう。mobile 等は update しないとコードが上書きされないのでデータの仕様変更があってもクライアント側が対応できない
- Cloud Functions でコピーするやり方では、基本的にクライアントは 1 ドキュメントだけの更新で済み、その後のコピーの仕方はクライアントアップデートとは関係なくいつでも好きなタイミングで自由に変更でき、柔軟性が高い。
- ここでコピーでなく、batch を使用することもできそう。