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
70
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
280
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
TiDBにおけるテーブル設計と最適化の事例
cygames
0
810
Taking Flight with Tailwind CSS
opdavies
0
4.3k
社内での継続的な機械学習勉強会の開催のコツ
yudai00
2
390
20240509 CloudWatch でいろいろなものを監視してみよう
masaruogura
1
120
QAエンジニアが伝えたい品質保証の羅針盤 / Compass for Quality Assurance
mii3king
2
350
マルチテナントマルチクラスタKubernetesでもUXを損なわない認証認可の勘所
pfn
PRO
0
110
サービス開発におけるVue3とTypeScriptの親和性について
tsukuha
10
1.8k
OPENLOGI Company Profile
hr01
0
46k
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
180
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
1.7k
Databricksの生成AI戦略
taka_aki
1
380
Trade-offs all the way down
_aitor
1
120
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
The Language of Interfaces
destraynor
151
23k
It's Worth the Effort
3n
180
27k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
7k
Become a Pro
speakerdeck
PRO
13
4.6k
Being A Developer After 40
akosma
67
580k
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
jQuery: Nuts, Bolts and Bling
dougneiner
60
7.2k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Thoughts on Productivity
jonyablonski
60
3.9k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
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