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
220
RDB脳からFirestore脳へ
ham
March 07, 2022
Tweet
Share
More Decks by ham
See All by ham
メンバーがオーナーシップを発揮しやすいチームづくり
ham0215
2
410
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.7k
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
5
2.1k
アジャイルを始めるための基礎を固める
ham0215
1
94
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
940
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
1.1k
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.7k
今こそ思い出すGraphQLの特徴
ham0215
0
190
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
570
Other Decks in Technology
See All in Technology
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
5
1.8k
アジャイル開発とスクラム
araihara
0
140
Ask! NIKKEIの運用基盤と改善に向けた取り組み / NIKKEI TECH TALK #30
kaitomajima
1
420
Datadogとともにオブザーバビリティを布教しよう
mego2221
0
110
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
840
日経電子版 x AIエージェントの可能性とAgentic RAGによって提案書生成を行う技術
masahiro_nishimi
1
250
まだ間に合う! エンジニアのための生成AIアプリ開発入門 on AWS
minorun365
PRO
4
530
BLEAでAWSアカウントのセキュリティレベルを向上させよう
koheiyoshikawa
0
180
[JAWS-UG栃木]地方だからできたクラウドネイティブ事例大公開! / jawsug_tochigi_tachibana
biatunky
0
220
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
2
490
Bounded Context: Problem or Solution?
ewolff
1
200
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
110
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
6
230
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
A designer walks into a library…
pauljervisheath
205
24k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
9
1.3k
Building an army of robots
kneath
302
45k
Automating Front-end Workflow
addyosmani
1367
200k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
BBQ
matthewcrist
86
9.4k
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