- PR -

２４時間ノンストップ運用のＤＢ設計

1|2 次のページへ»
投稿者投稿内容
あいこ
会議室デビュー日: 2005/08/02
投稿数: 7
投稿日時: 2005-08-02 13:33
お世話になります。初めて投稿させて頂きます。

現在「２４時間ノンストップシステム」を設計しており、
トランザクションの同時実行について模索中です。

２４時間ノンストップシステムを構築していく場合、
どの様なデータベース設計（テーブル設計）をすべきか
皆さんのご意見をお聞かせ願いたいと思います。

実行環境は以下の通りです。
ＯＳ：ＷｉｎｄｏｗｓＳｅｒｖｅｒ２００３
ＤＢ：ＳＱＬＳｅｒｖｅｒ２０００

システムの概要は以下の通りです。（アバウトですいません。）
１．クライアントからの問い合わせに対して、ＤＢで保持している
　　最新の「在庫数量」をリアルに応答します。
　　又、「在庫数量」に対し出荷数を減算する更新を行います。
２．日次夜間バッチにて「在庫数量」に対し入荷数を加算する
　　更新を行います。

上記１．と２．の同時実行を可能とする為、どの様なテーブル構成に
すべきか悩んでおります。
日次バッチでは、一度に大量データが更新される為、ロックの
エスカレートでテーブルロックが起きるものと考えます。
日次更新の処理中（約１時間程）は、リアル処理は諦めるしか
ないのでしょうか？

皆さん、どの様に考えますか？
今川 美保(夏椰)
ぬし
会議室デビュー日: 2004/06/10
投稿数: 363
お住まい・勤務地: 神奈川県茅ヶ崎市
投稿日時: 2005-08-02 14:29
引用:

あいこさんの書き込み (2005-08-02 13:33) より:

日次バッチでは、一度に大量データが更新される為、ロックの
エスカレートでテーブルロックが起きるものと考えます。


と書かれているので、
バッチ処理ではトランザクション管理のもと、
全体ロールバックが必須である
と思って良いでしょうか？

そうだとしたらロックエスカレーションもそうですが、
デッドロックも気になるところです･･･。


今はまだ単純に考えただけですが、
Updateで 列名=値 ではなく、列名=列名+X(X=-出荷数 もしくは 入荷数)という
SQLで組んで、1行毎にCommitをかけるイメージなら
バッチ処理内で、オンラインの処理をたくさん出しているイメージになり
耐えれるのかしら･･･？
と思ってみたんですが、いかがでしょう？

#テーブル設計ではないですけどね･･･。
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2005-08-02 16:34
引用:

あいこさんの書き込み (2005-08-02 13:33) より:

日次更新の処理中（約１時間程）は、リアル処理は諦めるしか
ないのでしょうか？



詳しいことがわかりませんが、更新系を無くせば実現できるのでは？
データ量にもよりますが、入荷は入荷、出荷は出荷でトランザクション
として持ち、参照の都度計算するってのは．．．

まぁ週一とか月一で繰越処理などしないと遅くなりますけどね。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-08-02 17:04
引用:

１．クライアントからの問い合わせに対して、ＤＢで保持している
　　最新の「在庫数量」をリアルに応答します。
　　又、「在庫数量」に対し出荷数を減算する更新を行います。
２．日次夜間バッチにて「在庫数量」に対し入荷数を加算する
　　更新を行います。

「リアルに対応するなら、在庫数量もリアルに更新したらよいんじゃないの？」と思ってしまいました。パフォーマンスは落ちるでしょうけど・・・。

また仮に夜間バッチとして処理するとしたら、バッチ処理中は著しくパフォーマンスが落ちるのを承知の上でロックしながら更新するしかないんじゃないの。在庫数量に反映済みのレコードと、未反英のレコードが区別できるようにすれば出来ますよね。
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2005-08-02 17:17
それにしてもエスカレートでテーブルロックが起きるのかな？
ここは単なる思い込みか、それこそ作りによるのでは、
でも　どう作るか、どうテーブルを作るべきかは、与えられた情報からわからない
Desmo
大ベテラン
会議室デビュー日: 2004/03/24
投稿数: 149
投稿日時: 2005-08-02 17:25
毎日行なう更新処理に１時間もかかってしまうのですか？
リアル処理に影響するのは「"在庫参照"と"出荷数の減算"に関わるテーブルの更新時」だけだと思いますが、このトランザクションだけ工夫すれば、うまく行きませんか？
・入庫を複雑な計算で求めているのであれば、先にWORKテーブルに更新情報を
　用意しておいて、問題となるテーブルの更新はなるべく単純なSQL文にする。
・途中で何度もCommitを入れるようにする。
など。
Anthyhime
ぬし
会議室デビュー日: 2002/09/10
投稿数: 437
投稿日時: 2005-08-03 06:35
まず、バッチ、オンライン共にロックを楽観的ロックで行い、デッドロック、ロック待ちを無くすようにします。
その上で、バッチではバッチ中にオンラインで変更されてしまったデータをエラーで検出し、それらに関連するバッチデータだけ再度バッチの実施を行う形でDBに再登録します。

あまり夜間のオンライン利用者がいないことを前提にしていますが、こんな感じでできないでしょうか。
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2005-08-03 08:56
補足です。

出荷テーブル、在庫テーブル、入荷テーブル（これは必要なければ無くても
よい）に別け、バッチでは入荷テーブルと出荷テーブルの値を読んで、在庫
テーブルを更新します。
リアルタイムの出荷処理では、在庫テーブルと出荷テーブルを読み込んで
現状理論在庫を求めて表示し、出荷数は出荷テーブルにのみ書込めば、在庫
に関してはデッドロック等の心配はなくなるのでは？

ただ、情報が少ないので何とも言えませんが、在庫の引き当てとか出荷停止、
返品等の処理を考えた上でのお話でしょうか？
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）