Laravel:大量データ処理の速度と利便性がトレードオフ
大量データ生成時に掛かる処理時間をどう考えるか
結局これなんですよね。
行きつくところは『どう考えるか』
今回のシステムでは、楽天市場やYahoo!などのモール側が推奨する商品名をDBからCreateしようとしています。
その為、細かなデータの塊が大量に存在しています。
値は商品毎に異なるため、商品名を生成しようとした場合いくつものクエリを発行する事になります。
これを回避するための方法は大きく3つ。
- SQLにインデックスを貼りまくる
- 事前に取り出す予定の値を作り出して置き最後の合成処理だけ指示後に行う
- DBを小分けにせずに1商品1レコードの形で大きなテーブルを作る
1の場合はサーバーのHDDが結構大変なことになります。
2の場合は変更した内容がすぐに反映されない(事前に準備されているので)と言う問題点が。
3の場合は例えば商品サイズのように1商品に複数当てはまる内容をどう格納するかという課題が出てきます。
それぞれ解決方法もあります。
1.サーバーのグレードを上げる(コストを掛ける)
2.毎回の修正保存時に事前準備している値も書き換える
3.カラムに保存する値をJSONにする
最近は3が主流になっているでしょうか。
でも3は3で問題があります。
大きくなりすぎるとindexも大きくなる。
結局1へ戻るわけですね。
処理時間と汎用性、利便性はトレードオフの関係になる時がある
そう、トレードオフなんですよね。
『あっちを立てるとこっちが立たない』なかなか3方良しとはならないのです。
こういう時は断捨離的に捨ててもいい事柄を考えます。
今回の事案で考えると、システムの出品CSV作成に時間が掛かる。
・1日何回更新する?
・代替方法は無いの?
・代替方法の場合終了を待つ必要がある?(勝手に任せて無視できる?)
そんな事を考えると「別に多少時間が掛かってもいいか、急ぎで更新したい場合は単品ごとにAPI更新すればいいんだし」となります。
ましてやね、Wowma!なんてAPI無料CSV有料だからね、APIで出来りゃいいでしょう!
まとめ
現バージョンの出品補助システムはCSV生成に少しお時間を頂くモデルになると思います。
indexは極力しっかり張っていきますが、やっぱりHDDの限界がありますので…。
トレードオフの関係って判断難しいですよね。
さぁ頑張ろう!
-
前の記事
Laravel:処理時間のかかるQueueで発生した3倍のデータ処理 2019.08.07
-
次の記事
Laravel:Queue Driver の違いで動作結果が変わる怪事件発生 2019.08.09
コメントを残す