価格推移のデータベースをつくりたい
masa5714【やろうとしてること】
対象店舗： 1000件ほど。
各店舗商品数： 5000件ほど
1日あたり500万レコードを収集することになる。
【課題と解決】
-
ざっくりとした計算だが、作りたいものを実現しようとすると1年で40GBほどになってしまいそう。価格を抑えて実現するには工夫が必要。（月1,000円未満で抑えたい。）
-
knex経由でクエリを実行する予定ではあるが、一応Supabaseで実行できる状態にしておきたい。なので、Supabaseを使うことになる。Supabase社がホストするタイプのサービスではDBサイズが足りないので無理。オープンソース版を使うことになりそう。
-
安いVPSを借りてそこにデータを蓄積しまくる形式になりそうだ。
masa5714擬似的なレプリケーションが効いてきそう
ここで考えた擬似的なレプリケーションがすごく役に立ってくれそうな予感。
普通にSupabaseだけを使ってたら knex を使おうなんて発想にならなかった。
knex 経由であれば、PostgreSQLだろうが、MySQLだろうが、CURDに限って言えばそれほど意識する必要が無い。単なるデータ保管庫として安価なレンタルサーバーにI/Oを酷使してしまえばいい気がする。
これなら月額500円未満で価格推移を実現できるかもしれない。
現時点で考えている処理の流れとしては下記の通り。
- 対象サイトをスクレイピングしてレンタルサーバーにデータを溜め込む。
- 毎日0時ぐらいにCronを実行し、2週間ぐらい前のデータをファイル化して保管し、古いデータをDBから物理削除する。そのファイルは自宅のサブPCで管理しておく。ファイル名はuuidで管理。サブPCで
LISTEN hoge_channelしておく。 - 古いデータの閲覧をしたいユーザーからのリクエストが発生したら、サーバーから
NOTIFY hoge_channge, 【ここにuuid】を実行し、受け取ったuuid名のファイルを開いてknex経由でテーブルにデータをINSERTする。このデータは閲覧用に一時的に格納されるものである。 - 1時間ごとに閲覧用のデータをDELETEする。
これでテーブルサイズを抑えつつ、古いデータをいつでも呼び出せるような環境を作り出せそうだ。サブPCがストレージサーバーとなりつつも、アーカイブ呼び出し用の処理サーバーとしても動いてくれるという構成。サーバー代を抑える節約術としてのアイデアだ。
※準備ができたらすぐにユーザー側の表示を切り替えるためにSupabaseのリアルタイム機能を使うと良いだろう。リアルタイム機能はチャット以外の用途もあるんやで。