Firestoreの魅力を調べながらNoSQLとRDBMSの違いを探る

[subaru-hello]

Firestore vs RDBMS

特徴	Firebase Firestore (NoSQL)	RDBMS
データ保管方法	- ドキュメントとコレクション形式で保存。 - スキーマレスまたは動的スキーマを採用。 - JSONライクなデータ構造を使用。	- テーブル形式で保存。 - 明確に定義されたスキーマ（列と型）が必要。 - データの正規化を通じて重複を排除。
Create（作成）	- スキーマレスなので新しいフィールドやデータ型を簡単に追加可能。 - データスキーマの変更が即座に反映される。	- 事前にスキーマを定義する必要があるため、変更にはデータベース全体の再設計が必要。
Read（読み取り）	- リアルタイムクエリが得意。 - 簡単な検索やフィルタリングは高速。 - クエリの構造に制限がある（複雑な結合や集計は不得意）。	- 高度な結合（JOIN）や集計クエリに対応可能。 - SQLを使用した複雑なデータ分析が得意。
Update（更新）	- ドキュメント単位での更新が中心。 - 部分更新も可能だが、柔軟性が劣る場合も。	- 特定のフィールドのみを効率的に更新可能。 - トランザクションでデータの整合性を保証。
Delete（削除）	- ドキュメント単位で削除可能。 - コレクション全体の削除には工夫が必要。	- テーブル単位または特定の条件での削除が容易。 - 外部キー制約により、参照整合性が保証される。
スケーラビリティ	- 水平スケーラビリティに優れる（サーバーレス設計）。 - トラフィックに応じて自動スケーリング。	- 垂直スケーラビリティが基本。 - スケーリングにはデータベースの分割や再設計が必要。
リアルタイム機能	- クライアント間でデータのリアルタイム同期が可能（リスナーで即時反映）。	- データのリアルタイム同期には専用の仕組みやカスタムAPIが必要。
オフライン対応	- オフライン時にも読み書きが可能。 - 再接続時に自動的に同期される。	- オフライン対応は手動での実装が必要。
セキュリティ	- セキュリティルールで細かいアクセス制御が可能（ドキュメント単位）。	- ユーザー認証やアクセス制御はアプリケーションや外部システムに依存。
得意な分野	- チャット、コラボレーションツール、IoTアプリ。 - リアルタイム性が求められるアプリ。	- 金融データ、在庫管理、トランザクション処理など整合性が重要なシステム。
不得意な分野	- 複雑な結合や多対多関係の処理が苦手。 - データの正規化や高度な分析には不向き。	- 非構造化データや動的なデータスキーマには不向き。
コストモデル	- サーバーレスで使った分だけ課金（リクエスト数やストレージ量）。	- サーバーの台数やスペックに応じた固定コストがかかる。

[subaru-hello]

https://zenn.dev/yucatio/articles/173f386c471398

[subaru-hello]

オフラインでもデータを同期をできるのはなぜなのか気になった。

https://firebase.google.com/products/firestore?hl=ja

[subaru-hello]

データ特徴

Cloud Firestore は NoSQL ドキュメント指向データベースです。SQL データベースとは違い、テーブルや行はありません。代わりに、データは「ドキュメント」に格納し、それが「コレクション」にまとめられます。

データはドキュメントに書き込まれ、コレクションとして保管される。

https://firebase.google.com/docs/firestore/data-model?hl=ja&_gl=1*vc7ycw*_up*MQ..*_ga*MTI4ODc4NTYwMC4xNzMyODc3Nzk3*_ga_CW55HF8NVT*MTczMjg3Nzc5Ny4xLjAuMTczMjg3Nzc5Ny4wLjAuMA..