2

私たちは、クライアントの予定を管理するためのスケジューリング システムを構築しました。このシステムは、Prometric が試験をスケジュールするために使用するものと似ています。主な懸念事項は次のとおりです。オーバースケジュールがないことを保証し、1 か月あたり少なくとも 10 万件の予約をサポートし、テスト センターのキャパシティを簡単に増減できるようにします。

容量ベクトルに基づいて、次の設計を考案しました。各予定には少なくとも 5 分かかると仮定しました。ベクトルは 288 スロット (24 時間 * 1 時間あたり 12 スロット) で構成され、各スロットは 1 バイトで表されます。このベクトルにより、システムは 5 分ごとに最大 255 件の予定を表すことができます。使用される情報は、2 つのベクトルで構成されます。1 つはテスト センターの容量(NOMINAL CAPACITY)を格納するためのもので、もう 1 つは使用済みの容量 (USED CAPACITY)を格納するためのものです。現在の容量(CURRENT CAPACITY)を回復するために、システムはテストの NOMINAL CAPACITY を取得し、USED CAPACITY を差し引きます。

データベースの構造は次のとおりです。

公称容量

公称キャパシティは、稼働日 (月～金) のキャパシティを表します。

| TEST_CENTER_ID | NOMINAL_CAPACITY
| 1          | 0000001212121212....0000
| 2          | 0000005555555555....0000
...
| N          | 0000000000010101....0000

使用容量

このテーブルには、各日/テスト センターの使用容量が格納されます。

| TEST_CENTER_ID | DATE       | USED_CAPACITY
| 1          | 01/01/2010 | 0000001010101010...0000
| 1          | 01/02/2010 | 0000000202020202...0000
| 1          | 01/03/2010 | 0000001010101010...0000
...
| 2          | 01/01/2010 | 0000001010101010...0000
...
| N          | 01/01/2010 | 0000000000000000...0000

クライアントがテスト センターと日付を選択すると、システムは次の計算を行って利用可能なスロットを提示します。例えば：

TEST_CENTER_ID   1
DATE             01/01/2010
NOMINAL_CAPACITY 0000001212121212...0000
USED_CAPACITY    0000001010101010...0000
AVAILABLE_CAPAC  0000000202020202...0000

クライアントが予定をスケジュールすることを決定した場合、システムは選択された日 (# USED CAPACITY テーブルの行) をロックし、対応するバイトを増やします。

現在、システムはうまく機能していますが、予約数が増えすぎると、競合の問題が発生することが予想されます。

この問題に対するより良い/別のモデル、またはそれを改善するための提案はありますか?

ベクトルの表現を時間単位でサブダイビングし、楽観的なロック戦略に変更することで、競合を回避することを考えました。例えば：

| TEST_CENTER_ID | DATE       | USED_CAPACITY_0 | USED_CAPACITY_1 | ... | USED_CAPACITY_23
| 1             | 01/01/2010 | 000000101010    | 1010...         | ... | ...0000

この方法では、行をロックして衝突イベントを減らす必要はありません。

4

1 に答える 1