Есть ли альтернатива оптимистичной блокировке?

Question

Я работаю над проектом, в котором мы собираем (last_x, counters) информацию об учетной записи.Действия пользователя могут привести к созданию нескольких бизнес-событий.Когда одно пользовательское действие в сети приводит к более чем одному событию, оно инициирует обновление таблицы USER HISTORY.

Мы выполняем оптимистическую блокировку, чтобы все события приводили к обновлению таблицы ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ.

Проблема:

Результатом оптимистической блокировки являетсядополнительные операции чтения (при обнаружении конфликтов, повторное чтение и обновление) и дополнительные операции записи (после разрешения конфликта).

Испытанные решения:

• Каждое событие приводит к вставке в таблицу ИСТОРИИ ПОЛЬЗОВАТЕЛЯ - больше информации в истории, что приводит к снижению производительности чтения.

  Есть ли другая альтернатива?

Answer 1

Есть ли переопределение необходимости , чтобы иметь производительность чтения для этой таблицы?

Мне кажется, что это какой-то «рабочий день» / каждый час или около того, профиль клиента / таблица аналитики. Если это так, то вы можете просто использовать вставки и подумать о методах хранения данных, таких как Схема звезды , чтобы заботиться о стороне (last_x, counters).

Если это более критично и зависит от времени, то ваша схема, вероятно, не подходит для этой работы. Рассматривали ли вы использование промежуточного программного обеспечения для обмена сообщениями, такого как JMS , для уведомления и запуска других бизнес-событий?

Поскольку вы используете Oracle, вы можете посмотреть: Oracle AS

[РЕДАКТИРОВАТЬ] Основываясь на обсуждении, вы имеете в реальном времени производителя / потребителя встречной информации. Я не думаю, что база данных - это основной способ сделать это. Возможно, вам придется придерживаться счетчиков для целей бухгалтерского учета, поэтому, возможно, вам нужно что-то вроде этого:

Производитель : init (перестроить сессию / memcached из БД)
RECV User Action X -> Session / Memcached (ActionX) + Вставить в БД.

Потребитель : выполняется (проверка состояния / memcached для условия, действие)

Вы даже можете сделать так, чтобы потребители счетчиков истории пользователей были подписчиками события, которое запускается производителем, когда счетчики достигают X, и устраняет зависимость потребителей от ИСТОРИИ ПОЛЬЗОВАТЕЛЯ

Answer 2

Похоже, что эти многочисленные события следуют по разному пути, и каждое событие приводит к записи в истории.Это правильно?

Разве приложение не должно иметь возможность контролировать события и каким-то образом указывать одно и то же событие по разным путям?Как, например, сгенерировать уникальный идентификатор для каждого события и сделать поле уникальным в БД, чтобы запись не выполнялась?Вы можете легко игнорировать ошибки из-за уникального ограничения.