Модель системы планирования

Мы создали систему планирования для контроля встреч наших клиентов. Эта система аналогична той, которую Prometric использует для планирования экзаменов. Основные заботы: гарантировать отсутствие перепланировок, поддерживать не менее ста тысяч назначений в месяц и позволять легко увеличивать/уменьшать пропускную способность центра тестирования.

Мы разработали следующий дизайн на основе векторов емкости. Мы исходили из того, что каждая встреча требует не менее пяти минут. Вектор состоит из 288 слотов (24 часа * 12 слотов в час), каждый из которых представлен одним байтом. Вектор позволяет системе представлять до 255 встреч каждые пять минут. Используемая информация состоит из двух векторов: один для хранения мощности центра тестирования (НОМИНАЛЬНАЯ МОЩНОСТЬ), а другой для хранения используемой мощности (ИСПОЛЬЗУЕМАЯ МОЩНОСТЬ). Чтобы восстановить текущую мощность (ТЕКУЩАЯ МОЩНОСТЬ), система берет НОМИНАЛЬНУЮ МОЩНОСТЬ тестирования и вычитает ИСПОЛЬЗУЕМУЮ МОЩНОСТЬ.

База данных имеет следующую структуру:

НОМИНАЛЬНАЯ МОЩНОСТЬ

Номинальная мощность представляет собой мощность за рабочие дни (пн-пт).

| 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

Таким образом, не нужно будет блокировать строку и уменьшать количество коллизий.


schedule data-modeling
person David Reis    schedule 16.03.2010    source источник
comment
Вы пользуетесь этой системой уже почти год. Как это работает?   -  person Mike Sherrill 'Cat Recall'    schedule 22.02.2011

Ответы (1)


arrow_upward
0
arrow_downward

Вот одна идея:

Вы можете использовать оптимистическую блокировку с вашим текущим дизайном. Вместо использования отдельного номера версии или временной метки для проверки того, была ли изменена вся строка, сохраните на память массив used_capacity при чтении строки. Вы блокируете только обновление, и в это время вы сравниваете только измененный байт слота, чтобы увидеть, был ли он обновлен. Если нет, вы можете внедрить новое значение в этот один элемент, не изменяя остальные, тем самым сохраняя модификации других слотов, выполненные другими процессами с момента вашего первоначального чтения.

Это также должно работать с набором смежных байтов для встреч продолжительностью более 5 минут.

Если вы знаете слот (ы), о котором идет речь, при первом чтении, вы можете просто сохранить начальный индекс массива и значимые значения вместо всего массива.

person NaturalData    schedule 29.03.2014