Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RDB脳からFirestore脳へ
Search
ham
March 07, 2022
Technology
0
150
RDB脳からFirestore脳へ
ham
March 07, 2022
Tweet
Share
More Decks by ham
See All by ham
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.3k
今こそ思い出すGraphQLの特徴
ham0215
0
71
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
290
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
0
2.7k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.1k
可視化からはじめる開発生産性向上への道のり
ham0215
0
330
GraphQL データ取得高速化
ham0215
0
270
キーボードのすゝめ.pdf
ham0215
0
110
イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜
ham0215
0
3.4k
Other Decks in Technology
See All in Technology
パフォーマンス最適化のベストプラクティス
databricksjapan
0
220
20240516 OpenID TechNight Vol.21 OpenIDファウンデーション・ジャパンの 今後の活動について
oidfj
0
190
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
12
8k
SWC Transformerから見るTypeScript関数記述ベストプラクティス
fujiyamaorange
1
190
iThome2024 Wailing Wall of Enterprise Security
notsurprised
0
310
My road to OSEE Part1
yunolay
0
130
スクラムに出会って「できた」を実感できるようになってきた話 / Scrum makes me feel like I can do it
yayoi_dd
2
120
#phpconkagawa レガシーコードにもオブザーバビリティを 〜少しずつ始めるサービス監視〜
yamato_sorariku
0
570
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
1
200
PHP 9 に備えよ - 動的プロパティ、どうすればいぃ?
taisukearase
0
410
OpenID Foundation updates
fujie
0
260
マルチテナントマルチクラスタKubernetesでもUXを損なわない認証認可の勘所
pfn
PRO
1
190
Featured
See All Featured
Building Your Own Lightsaber
phodgson
100
5.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
323
20k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
How to Ace a Technical Interview
jacobian
273
22k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Mobile First: as difficult as doing things right
swwweet
217
8.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Faster Mobile Websites
deanohume
300
30k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
Code Reviewing Like a Champion
maltzj
516
39k
Documentation Writing (for coders)
carmenintech
60
4k
Imperfection Machines: The Place of Print at Facebook
scottboms
261
12k
Transcript
RDB脳からFirestore脳へ 2022/3/7 LT ham
Firestoreとは • Firebase(Google Cloud)で提供されているNoSQLデータベース • フロントコードから直接呼び出すことができるため、バックエンドの構築が 不要。 • 料金は保存量+READやWRITE数で決まる従量課金だが、無料枠がありサクッ と使うだけであれば無料枠におさまるのでプロトタイプ開発や個人開発での
使い勝手が良い。
RDB脳からFirestore脳へ システムでデータの保存先と言えば、PostgreSQLやMySQLなどのリレーショナ ルデータベース(RDB)が主流です。 そのため、システム開発したことがある方はRDBの知識を持っている方が多いの ですが、RDBの考え方をFirestoreにそのまま適用するとうまくいかないこと/ 面倒なこと/そもそもできないことが多々あります。 そこで、このスライドではRDBとFirestoreで考え方を変えるべき例を2つ紹介 します。
アクセス範囲に合わせてテーブルを分ける 例えばユーザー情報を管理するテーブルを考えます。 保持する情報は下記の通り。 • ニックネーム ◦ 全体に公開OK • メールアドレス ◦
本人のみ閲覧OK
アクセス範囲に合わせてテーブルを分ける RDBの場合 usersテーブルに nicknameとemailを保持 users ・nickname ・email バックエンド クライアントからバックエンドを通して RDBにアクセスするため、同一テーブル
に入っていてもシステムでアクセス制御 可能
アクセス範囲に合わせてテーブルを分ける Firestoreの場合 usersドキュメントに nicknameとemailを保持 /users ・nickname ・email レコード単位でルールを設定しアクセス 制御するので1レコードにアクセス範囲 が異なるデータが入っているとアクセス
制御が困難 ルール
アクセス範囲に合わせてテーブルを分ける Firestoreの場合 nicknameとemailでドキュメントを 分ける /private_users ・email /users ・nickname ルール ルール
ドキュメントを分けることでそれぞれに ルールを設定可能
用途ごとにテーブルを作成する 複数のリソースを持っており、画面によって必要な情報が異なる場合を考えま す。 画面A:usersのみ使用 画面B:usersとそれに関連するuser_hogesを使用 画面C:usersとそれに関連するuser_fugasを使用 画面A 画面B 画面C users
users └user_hoges users └user_fugas
用途ごとにテーブルを作成する RDBの場合 リソースごとに テーブル管理 users バックエンドで必要なデータをDBから取 得して整形して返却 A B C
user_hoges user_fugas バックエンド users users └user_hoges users └user_fugas
用途ごとにテーブルを作成する Firestoreの場合 /users A B C /user_hoges /user_fugas users users
user_hoges users user_fugas リソースごとに ドキュメント管理 バックエンドがないため、データの整形をク ライアントが実装する必要がある。 また、RDBのように適切にjoinしてリクエスト を減らすことが難しくREAD数も増える (READ数課金)
用途ごとにテーブルを作成する Firestoreの場合 /users A B C /user_hoges (with users) /user_fugas
(with users) users user_hoges user_hogesやuser_fugasに users情報を含める。 クライアントが使いやすい形に整 形しておく。 あらかじめクライアントが使いやすい形に整 形してあるので、クライアント処理がシンプ ルになり、READ数も減る。 user_fugas 参照処理はシンプルに なるが、更新処理が煩 雑になるのでは?
usersが更新された場合 用途ごとにテーブルを作成する /users /user_hoges (with users) /user_fugas (with users) usersが更新された時、user情報を含んでいるすべてのド
キュメントを更新する必要がある。 →クライアントがuser情報を持っているドキュメントを把握し ておく必要がある →処理が煩雑に・・・
usersが更新された場合 用途ごとにテーブルを作成する /users /user_hoges (with users) /user_fugas (with users) クライアントからはusersのみ更新
Cloud Functions usersの更新を検知して、user_hogesや user_fugasを更新 →クライアントはuser情報を持っているドキュメン トを把握する必要がなくなる。
参考書籍 Firestoreのドキュメントだけでは読み取れない、実践で役立つプラクティスが 書かれている本。 私はこの本を読んでFirestore脳ができました。 Firestoreを使ってみようと思っている方は一読の価値があると思います。 (ちなみに私はこの本の関係者でもなんでもありません) 実践Firestore