Firestoreとうまく付き合うために

Copyright © 2022 Bitkey Inc. All right reserved. Firestoreとうまく付き合うために株式会社ビットキー　　白木
孝典 2022.10.24

2 Copyright © 2022 Bitkey Inc. All right reserved. Outline
1. 自己紹介 2. これまでの話 3. Firestoreについて 4. Firestoreを実際使ってきて 5. 今後の話

3 Copyright © 2022 Bitkey Inc. All right reserved. 自己紹介
白木孝典 Shiraki Takanori 2014  2016  2018  株式会社ワークスアプリケーションズに入社会計システムのソフトウェア開発者として、管理会計、特に予算管理を主に担当会計事業からEC事業へ異動受注・決済管理の開発チームのマネージャーとなる現場でマネジメントをしながら、導入業務も兼任創業からビットキーへジョインスマホアプリ・ウェブアプリ・バックエンドの基礎設計、インフラ選定、アーキテクチャ設計、フレームワークやライブラリの決定から実装までを担う 2022  新規サービスの設計・実装、既存サービスの改善、開発体験の改善、色々やってます

4 Copyright © 2022 Bitkey Inc. All right reserved. 1.
これまでの話

5 Copyright © 2022 Bitkey Inc. All right reserved. これまでの話
GCP製品を使うようになった理由 • コスト • 機能 • 将来性 • 考え方 • ほか

GCP製品を使うようになった理由 • コスト • 機能 • 将来性 • 考え方 • ほか 2018年の創業時、他のクラウドサービスと比較して一番自分たちに合っていた

コンシューマー向けスマホアプリからスタート Firestore、Storage、Functionsを主軸に開発当時は快適に開発できていました

事業拡大期。 Webアプリを作り、機能が広がる中、だんだんペインが増えていく・・・ Firestoreに向かないユースケースや、 Cloud Functionsの限界など。

Firestoreについて

10 Copyright © 2022 Bitkey Inc. All right reserved. Firestoreについて
Firestoreとは… • ドキュメント指向データベース • スケーラビリティすごい • オフラインサポートがアツい • リアルタイムアップデートが強力 • トリガーが簡単 • （正しく使えば）異次元の安さ東京リージョンの場合 $0.038 / 100,000 read

逆によく考えて使わないといけないポイントも・・・

• スキーマレス • 動的な結合はできない • ドキュメントの更新頻度の制限 • ドキュメントサイズの制限 • プロジェクトにひとつだけ • ロケーションの変更はできない • クエリの制約が厳しめ • 複合インデックス上限200 • 一度の書き込み上限500

Firestoreを実際使ってきて

14 Copyright © 2022 Bitkey Inc. All right reserved. Firestoreを実際使ってきて
実際に使って感じたこと • スケーラビリティについて • リアルタイムアップデートについて • オフラインサポートについて • クエリについて • コレクション設計について • イベントトリガーについて • スキーマレスについて • ロケーションについて

実際に使って感じたこと • スケーラビリティについて • リアルタイムアップデートについて • オフラインサポートについて • クエリについて • コレクション設計について • イベントトリガーについて • スキーマレスについて • ロケーションについて

クエリについて日々苦労するのは、結局ここ。 • joinはできず、inに渡せる値は10まで • 範囲検索は1フィールドが上限 • 範囲+αの検索には複合インデックスが必要 • 複合インデックスの上限は全体で200まで

クエリについてグループ1に所属する人のアクティビティを取得したい → ？？ or 所属 group id 1 1 1 2 2 1 行動 id activity 1 A 1 B 2 C 行動 group id activity 1 1 A 1 1 B 1 2 C 2 1 A 2 1 B or 行動 groups id activity 1, 2 1 A 1, 2 1 A 1 2 C

クエリについて範囲検索は1フィールドが上限できるできない

クエリについて日々苦労するのは、結局ここ。 • joinはできず、inに渡せる値は10まで • 範囲検索は1フィールドが上限 • 範囲+αの検索には複合インデックスが必要 • 複合インデックスの上限は全体で200まで → 問題となるユースケースでは　素直に他のDBを検討するべき

コレクション設計についてめちゃくちゃ悩みました

コレクション設計について設計が難しい設計ができてもすっきりしないレビューはもっと難しい

イベントトリガーについて便利で簡単に作れてしまうから使いがち。だけど本当に慎重になった方が良い。 • 変更から処理までのタイムラグ • エラーハンドリング • やりすぎるとカオス • 変更難易度がめちゃくちゃ高い

スキーマレスについて実際は、変なデータが取得される可能性を常に考慮するコストのほうが、大きい。メリットとして語られることもあるが… ネストも含めた全フィールドに対して定義しきることは、かなり大変セキュリティルールで制御はできるが…

スキーマレスへの向き合い方その1 定義はOpenAPI • 厳密なセキュリティルールを書くのは大変 • ランタイムエラーよりコンパイルエラー • 必要ならここからセキュリティルールを生成できる

スキーマレスへの向き合い方その2 定義違反は都度チェックチェックと変換

ロケーション選択についてロケーションは一度決めたら変更できず、 Firestoreはプロジェクトごとにひとつしかもてない。 • 基本はユーザーとバックエンドとFirestoreをすべて近づけるべき • 事業展開が予定通りでない場合のインパクト • 初期のプロジェクト全体の設計が重要

今後の話

目指す形メインがFirestore これまで RDBをベースに、 Firestoreがサポートするこれから Cloud SQL Cloud Spanner AlloyDB Firestore Firestore

Firestoreが担う領域だいたい全部これまでこれから以下によってユーザー体験がよくなるところ • Getの負荷分散 • リアルタイム更新 • オフラインサポート

結論得意なものに任せる • 厳密な情報の管理（整合性、トランザクション） → RDB • 全文検索・統計量 → 検索エンジン • 類似度検索 → Vertex AI Matching Engine • リアルタイム更新・オフライン操作 → Firestore • 分析 → BigQuery • スケール・レイテンシの限界 → Bigtable

やっぱり『ベストプラクティス』をしっかり読むこと Firestoreについてはおすすめの使い方ではなく、守るべきルールが書かれています。 https://firebase.google.com/docs/firestore/best-practices?hl=ja

やっぱり『ベストプラクティス』をしっかり読むこと • ドキュメントへの書き込みを1秒間に複数回行わないでください • オフセットは使用しないでください • 単一フィールド除外を追加した方がよい場合があります • 最近削除されたデータをスキップするようなクエリの使用をさけてください • 辞書順で近い一連のドキュメントに対して、高頻度で読み取りや書き込みを行わないでください例えばこんなことが書かれています

Firestoreとうまく付き合うために

Firestoreとうまく付き合うために

More Decks by 株式会社ビットキー / Bitkey Inc.

Other Decks in Technology

Featured

Transcript