Как лучше хранить баланс?

Question

[Олег Цветков]

Есть такая таблица, в которой хранится баланс пользователей:

• userId
  
• balance
  
• holdBalance
  

Сейчас в поле balance хранятся как деньги, заработанные пользователем в рамках сервиса, так и введённые им в сервис (пополнение баланса). Нужно вынести деньги, которые пользователь ввёл в систему, в отдельную колонку, условно depositBalance, которая нужна для упращения логики механизма вывода средст.

Как лучше поступить?

1. Хранить все деньги в колонке balance, а depositBalance использовать параллельно ().
   
2. Хранить деньги, заработанные в системе, в таблице balance, а в depositBalance введённые в системе. На уровне модельки/контроллера складывать оба значения.
   
3. Что-то другое...
   

Answer 1

[lega]

1-й вариант + транзакционный журнал

Answer 2

[sim3x]

user_id
balance_change = Decimal
datetime

баланс получаем как сумму balance_change

Или можно помучаться с локами записи
Или можно поиметь проблем при race updates

Comments

[Олег Цветков]

sim3x, сейчас так и реализовано, но проблема в том, что, при выводе средств пользователем, нужно расчитывать 2 суммы: сумма заработанных средств и сумма введённых средств. Это достаточно затратно по ресурсам получается...

Введённые пользователем средства мы обязаны выводить без выплаты налогов (возврат), а вот из заработанных средств уже необходимо вычетать налоги.

[sim3x]

Олег Цветков: насколько затратно, что проще потом по raw логам восстанавливать баланс пользователя?

[Олег Цветков]

sim3x: да. При разработке сервиса бывшая команда разработчиков не озадачила себя созданием адекватной архитектурой как БД, так и самого приложения. Какое-то время спасали модификации механизма расчёта этих двух сумм на уровне приложения, но со временем уже не осталось мест, которые можно оптимизировать и как-либо улучшить. Да и давным-давно кто-то из разработчиков сделал механизм для пересчёта баланса по логам.

[sim3x]

Олег Цветков: если все делается по логам, то проще отказаться от данной таблицы

[lega]

> Или можно помучаться с локами записи

в чем проблема? транзакция сама залочит и разлочит (with update и т.п.) и избежит race updates

а вот размазывание данных (нормализация?) в результате может привести к реальным тормозам.

[sim3x]

lega: update set balance_change = 0

Если сумма по балансу может привести к тормозам, то ето дааа

[lega]

sim3x: > update set balance_change = 0

поподробней, в моем варианте нет balance_change

> Если сумма по балансу может привести к тормозам, то ето дааа

Если у вас в проекте одна значимая колонка, то можно расслабится, а когда "актуальный объект" собирается из 10 таблиц с кучей джойнов (там не только баланс, но и другие значения) то тормоза уже заметны.

Кстати под колонку active:bool вы тоже порекомендуете отдельную таблицу?, ведь для неё тоже можно организовать локи и race

[sim3x]

lega: вашего варианта, собственно, не видел

Думаю, что его стоит озвучить

Если куча джоинов, но тормозит только сум, то нужно читать експлейн, а не сразу жаловаться на сум

[lega]

sim3x: не, вы предлагаете использовать "вычисляемое поле" вместо хранения конечного значения. Если злоупотреблять вычисляемыми полями то в итоге может накопиться чрезмерная нагрузка.

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

А этих проблем нет, если делать правильно.
> Или можно помучаться с локами записи
> Или можно поиметь проблем при race updates

Хотя можете попробовать привести пример.

[lega]

Кстати для вашего варианта как раз локи нужны будут, чтобы не списать баланс дважды.

[sim3x]

lega:
те у вас нет решения

лок не нужен
Смотрим на лист операций - удаляем или помечаем как некореектную повторную

[lega]

sim3x: мой вариант снизу висит 2-3 часа

> лок не нужен Смотрим на лист операций - удаляем или помечаем как некореектную повторную

значит какое-то время данные будут не валидны, и товар может быть уже отправлен или лишние деньги переведены или т.п.

[sim3x]

lega: также как и в вашем варианте

[lega]

sim3x: Да, только двойного списания не будет

[sim3x]

lega: каким образом?

[lega]

sim3x: в mysql например можно заюзать "for update", тогда все транзакции (в repeatable read) застакаются и выполнятся последовательно.

[sim3x]

lega:
Если проект нагруженный, то нужно дважды подумать чтобы взять этот подход.

Если у вас в проекте одна значимая колонка, то можно расслабится, а когда "актуальный объект" собирается из 10 таблиц с кучей джойнов (там не только баланс, но и другие значения) то тормоза уже заметны.