設計について
今まで使っていたRDB(リレーショナル)と同じ感覚で設計するとコケたのでNoSQLについて調べることにしました。
そもそも NoSQL(Firebase Realtime DB) とは
Qiita: Firebase Realtime Databaseとはなんなのか？
要約すると
- NoSQLとはリレーショナルDBと本質が異なる
- RDB = デスクトップアプリケーション向け、NoSQL = モバイルアプリケーション向け（双方で使えないわけではない）
- RDBは厳格な一貫性（ACID）を保つことに重点を置いている
- RDBは古い昔にデザインされたデスクトップ向けの設計で、現代のモバイルアプリケーションに適していない
- ACID = Atomicity:原子性、Consistency:一貫性、Isolation:独立性、Durability:永続性
- NoSQLは可用性を重視している
- モバイルの所以は途中でネットワークが切断されても対応できるところにある
- ローカルDBとリモートDBを自動同期し続けるため、途中でオフラインになっても利用し続けられる（高可用性）
- DB全体で一時的に一貫性のない状態が発生するが、一定時間後に修復する特性を持つ（結果整合性: Eventually Consistent）
- CAP定理は場合によって
CA 分断耐性+可用性orAP 可用性+一貫性の優先度（ECにおけるカートとチェックアウトなど）で切り替えていく - CAP定理 = Consistency:一貫性、Availability:可用性、Partition Tolerance:ネットワーク分断耐性
- CAP定理と著名サービス
- CAP定理の誤解
- CAP定理を特にモバイルに最適化した結果、BASEとなる。
- BASE = Basically Available:高可用性、Soft-State:緩やかな状態、Eventually Consistent:緩やかな一貫性
- FirebaseRealtimeDB = NoSQL
- 一級市民とは？ → 第一級オブジェクト
モデリング
設計してみる
ポイント
- キー名は転送速度に直結するため可読性を犠牲にしてキー名を短くするなどする (name -> nm など)
-
非正規化を意識する