6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Firebase RealtimeDatabaseに大量データ投入 - その1 -

Last updated at Posted at 2018-07-04

GYAOのtsです。

経緯

投稿がかなり久しぶりになってしまった。チームが変わったり、担当のプロダクトが変わったりで完全にチームも作り直し状態になってしまった。個人的にはチームをある程度固定してチームに対して仕事をアサインしたほうが効率的かつインクリメンタルなチームを作る上で効果的な気がする。評価もチームに対してなされる方がいいと思うのだが、そうなっていない現状がある。。。努力せねば。

そんなこんなで、現在はFirebase Realtime Database を主軸とし、モバイルアプリケーションのバックエンドを刷新しようとしている。

やりたいこと

  • ユーザーに対するお知らせをメッセージとして格納していく。
  • 全ユーザーに対するお知らせ、個別ユーザーに対するお知らせがある。
  • メッセージの変更、削除ができる
  • 個別ユーザーに対するお知らせは1回で500万程度のユーザーに対して。

これを実現するために迂余曲折(Firestore試したり、dataflow-pubsub試したり)あったが、
現状、以下の構成で行くことに決めた。

データ構造

/root/messagesの中にメッセージIDとメッセージ内容を格納。

isEveryoneがtrueであれば全員向け。(モバイルアプリで制御)
スクリーンショット 2018-07-04 14.17.15.png

/root/usersの中にメッセージIDとboolean(既読・未読)を格納。

スクリーンショット 2018-07-04 14.53.10.png

システム全体

design.png

  1. cloud storageにmessageディレクトリ、usersディレクトリを作成。
  2. 既存システムからjson linerをcloud storageにアップロードしてもらう(1ファイル1万行を500ファイル)
  3. CloudFunctionsのevent triggerでバケットを監視。uploadを検知
  4. cloud storageのpathがmessagesならmessagesに、usersならusersにupsert(マージ)する。

※messageは有効期限(expireDate)をunix timestampで持っているので、モバイルアプリの方で切れたメッセージは出さない処理を入れる。DB上は残ってしまうので、cleanExpiredMessageでdailyで削除。functionsはcron triggerが提供されていない。 他サービスつかってね なので、AzureのLogicAppsを使って、httpsで起動。

次回

DBのルールセットアップとupsertJsonを書きます。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?