HOME
流通工房について
各フェーズ定義
トピックについて
Link
■サイトマップ
■書籍・プロフィール
■サイト内検索
-------------------------
|
 |
 |
|
| ＜実装OnePoint！＞ |
＜吉田君＞
夜間バッチの業務データ処理全体を3時間で終わらせる必要があるのですが今回の150店舗
の発注処理だけでいろいろチューニングをしても4時間かかってしまっています。
もう少し、全体のバッチ処理時間を確保できませんか？
＜早瀬＞
店舗からの売上データの集信時間と翌日のオンライン開始時間、そしてバッチ処理全体で
多少予備時間を見ておかなければならないことを考えるとこれ以上、夜間バッチ処理時間
を確保することは難しい。
それよりは、データを分割実行するなどで処理時間の短縮を検討しよう
【ポイント】
業務データ処理は全店舗分の処理となるため、店舗数が多い場合は処理時間がかかって
しまうことが多々あります。
こういったときには、アプリケーション的に処理するデータを分割して、同時実行する
ことで全体の処理時間を短縮するといった方法を使います。
具体的には全店舗分の処理を1つのバッチ処理で実行した場合4時間かかるものがあった
場合、下記に記載をした店舗やJANにより、同じ処理を3分割で実行をし全体の処理時間
を圧縮する方法です。
どれだけ同時に分割処理を実行できるかはサーバーの負荷状況次第ですが、もしサーバー
の処理負荷に余裕がある場合は、3分割した場合、処理が3等分されるのでデータが平均的
に分布されている場合は単純に処理時間は1/3となります。
■具体的な分割方法
１．店舗による分割
例えば全国に店舗がある企業で、エリア管理をしているのであればそのエリア
単位での実施としたり、あるいは店舗の大小により当然データ量も異なるため
このデータ量が平均的になるように、バッチ制御テーブルをつくり処理する
店舗を制御するなどの方法です
この方法のメリット、デメリットは以下の通り
＜メリット＞
・分割数を自由に設定できる
・新規店舗など一時的に処理データが多いものを意識して分散させることが出来る
＜デメリット＞
・店舗が増減した時にバッチ制御テーブルをメンテナンスする必要性がある
・処理データ量が平均的に分散されるように店舗を振り分ける必要性がある
＜バッチ制御テーブルイメージ＞
処理グループ
店舗コード
※処理グループ１は大型店のA店とC店、小規模店のE、F、G店
処理グループ２は大型店のB店と、中規模店のH店、小規模店のI店
などとして、この2つの処理グループの処理を平行で実施するなどの使い方になります
２．JANの下1桁による分割
JANの下1桁はチェックデジットですが、この下1桁が0のもののみの処理、1のもののみの
処理などと商品単位に分割実行します。
つまり最大10分割になります。これを奇数偶数でわければ2分割になりますし
0と1など2つずつ処理をすれば5分割になります。
この方法のメリット、デメリットは以下の通り
＜メリット＞
・制御テーブルが不要なので店舗の増減などの際にメンテナンスが不要
・キーが店舗ではないので、データ処理的に店舗をキーに出来ない処理でも
処理の分散化が可能
＜デメリット＞
・特になし
さて、この方法を実施したことがない人が気になるのが
「そんなこといってもJANの1桁できれいに平均的に分散するの？」
といった部分でしょう。
例えば大げさな話下1桁が0のものが8割で、その他が2割で処理分散とならないのでは
ないかといったことですね。
これは確かに分散状況を調べる必要があります。
が、この仕組みを過去に2回使ったことがありますが、当然多少ばらつきがある
ものの面白いことにほぼ同じような件数になりました。
なお、くれぐれもJANの上1桁での分割などとはしないように（笑）
■重要なポイント１
上記の具体的な分割方法を見るとJANによる分割方法がデメリットがないので
よさそうに思えるのですが、これはあくまでもシステム的な観点によるものです。
いくつか流通システムを構築し、運用まで経験したことががある方は身にしみてわかって
いるかと思いますが、流通システムにおいて新店、閉店、改装などで特定の店舗だけ
データ量が大幅に増えること、また、日々の運用で業務的、システム的な問題で特定
の店舗だけ特別処理をする必要性があるケースも多々あります。
よって、個人的には、実際の業務運用を想定すると、店舗による処理分散の方が
良いと思います
■重要なポイント２
何分割が良いのか？
これはサーバーの負荷状況次第です。
10分割で実行したら結果的に、処理負荷が高まり、データ件数的には20分程度で
終わる想定が1時間かかってしまうといったこともあります。
負荷状況により何分割での処理が良いのかを見極める必要があります。
リリース直前の総合テストでは、実際の業務を想定したテストシナリオでの稼動結果、
処理結果の検証と共に、このあたりのチューニング作業が思っていたよりも作業負荷と
なる場合があります。
データ量が多い場合は、試算した通りの処理時間でに収まる保証はありません。
この総合テストフェーズでのチューニングが重要になります。
一方で、特に処理分散の方法を検討しておらず、総合テスト時点で処理分散が必要と
なり、上記の分散方法をアプリケーションに組み込むとなると、かなりの作業と
検証作業が発生することになります。
データ量が多い場合は是非、設計段階から処理分散を想定するようにしてください。
そして、その結果、もし処理の分散が不要であれば、仕組上は分散が可能となって
いるが制御テーブルやパラメータの設定で分散処理をしないようにすればよいだけですから。
|
Copyright (C) ビーコネクト. All rights reserved.
サイト内のテキスト、画像データの無断転載を禁じます |
|