Как лучше реализовать логику биллинга?

Question

[Павел Тысляцкий]

Здравствуй, Хабр.

Есть две коллекции прихода и расхода средств:

приход средств
    дата
    сумма
    статус (не поддтвержден, подтвержден, отменен)

расход средств
    дата
    сумма

Мне нужно получать остаток на счету и отчеты по использованию.

Без дополнительных коллекций

1. Чтобы получить остаток на счету нужно просумировать подтверженные пришедшие средства и отнять от них сумму расходов.
2. Чтобы получить отчет нужно вывести данные приходящие и расходуемые средства за период.

Здесь мне не нарвится что нужно постоянно вычислять остаток.

Добавить коллекцию счета

счет
    остаток

1. Чтобы получить остаток на счету нужно вернуть значение остатка.
2. Получение отчета анологично предыдущему методу.

Здесь мне не нарвится, что я должен менять остаток всегда когда меняются средства (добавляются новые записи или изменяется статус). Если у меня вдруг где-нибудь произойдет ошибка, для проверки мне нужно будет высчитать остаток как в первом методе, причем где и когда произошла ошибка мне будет сложно понять.

Добавить коллекцию периода

период
    закрыт (да, нет)
    дата начала
    дата окончания
    остаток в начале
    остаток при окончании

1. Чтобы получить остаток мне нужно вернуть значение остатка при окончании за последний открытый период.
2. Получение отчета анологично как и предыдущем методе, возможно проще получать даты для отчетов по периодам.

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

---

Собственно возможно кто-нибудь может описать другие модели или же дополнить/поправить мои рассуждения.

Спасибо.

Answer 1

[rPman]

Вы сами, с каждым новым примером расширяли саму задачу: +увеличить скорость, +увеличить надежность, +найти место и причину проблемы и возможность получить состояние на любой момент времени,…
Что значит другие модели? какие еще задачи нужно решить?

p.s. последний приведенный вариант вполне хорош, но накладывает ограничение — данные должны быть последовательны (для получения следующей записи нужна самая последняя запись), что может некрасиво ложиться на горизонтальное масштабирование, когда коллекция размазывается по нескольким физическим нодам (но эта проблема вполне решается, либо глобальными локами на объект — в данном случае 'счет', либо введением дополнительными коллекциями типа — данные о последнем изменении, если честно это та же реализация глобального лока, но уже через эту коллекцию...)
Т.е. ваша задача будет расширяться и дополняться, боюсь как бы не до бесконечности по мере появления новых проблем, порождаемых очередным решением предыдущей… рекомендую где то остановиться сразу.

Comments

[Павел Тысляцкий]

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

По поводу глобального лока и дополнительной коллекции типа не совсем понял хотя перечитал 5 раз.

[rPman]

Ладно, если речь пошла про расширение структуры и алгоритмы работы с учетом большого количества серверов, обслуживающих базу данных:

Тут тоже есть варианты, вытекают из тех же вариантов.
0. Самая простая реализация размазывания базы счетов и транзакций по нодам — это привязать транзакции одного счета к своей ноде, тогда все алгоритмы становятся точно такими же как и в односерверной реализации, просто балансер, выбирающий нужную ноду должен по счету однозначно выбирать ноду за O(1), обычно это тупой хеш. Метд идеален, когда количество транзакций на счете значительно меньше количества счетов, иначе прирост в скорости за сет расширения количества нод будет не линейным.
1. Если же количество транзакций велико… Есть два вида задач, в одних, когда нужно ускорить получение остатка на счете и когда нужно быстро обрабатывать транзакции (у транзакции тоже есть моменты, транзакция создается отдельно от своего исполнения, и если есть возможность не проверять величину остатка на счете во время исполнения, например не превышает ли объем транзакции лимита на счете, то это тоже имеет смысл), и конечно ничто не мешает реализовать оба механизма:
a) ускорение исполнения транзакции: каждая нода хранит часть транзакций, т.е. один счет может быть размазан по нодам, на каждой ноде хранится информация о итоговой сумме транзакций в этой ноде, т.е. для получения остатка нужно обратиться ко всем нодам запросом.
Плюсы:
* при создании/исполнении транзакции трудоемкость O(1), затрагивается только одна нода (на самом деле тут влияет от алгоритма выбора ноды, но в общем это так)
Минусы:
* запрос на итоговое значение на счете затрагивает сразу все ноды, с трудоемкостью O(m), где m — количество нод (если конечно алгоритм выбора нод не позволит определить ее до запроса)
* при создании/исполнении транзакции необходимо пересчитывать и следить за итоговой суммой на ноде (кстати не вижу особых проблем, понятие тригеры и атомарные операции в виде транзакций хранилища есть у даже самых отсталых БД), а значит пока идет запрос к нодам, необходимо либо блокировать глобально операции по транзакциям соответствующего счета (это и есть глобальный лок на счет), либо делать как то поправку на текущие исполняемые транзакции с этим счетом на других нодах.
b) ускорение получения итоговой суммы на счете:
Решение вообще то самое простое — где то хранить и обновлять информацию о состоянии счета, не размазывая ее по нодам, т.е. для одного счета задействовать не больше одной ноды, то есть на каждой ноде дополнительная коллекция счет->итог. Для каждой транзакции в этом случае придется затрагивать от одной до двух нод (одна нода — это если итоговая информация о счете хранится на той же ноде, куда попала транзакция), но благодаря этому трудоемкость транзакции остается O(1), и при этом трудоемкость получения итога так же O(1) — затрагивает одну ноду.

2. Стоит напомнить, что хранение истории/архива транзакций и исполнение транзакций — это разные задачи, и использовать одни и те же структуры данных для них как минимум глупо. Почти наверняка требования при работе с архивом/историей отличаются от требований по работе с текущими/исполняемыми транзакциями (время исполнения транзакции — время необходимое чтобы информация о ней расползлась по нодам, даже если их всего две, а это время не только записи, но и ожидания, когда выполнится предыдущая). Отсюда напрашивается простое решение — для поддержания архива транзакций использовать алгоритм 0, а для текущих транзакций — 1.

Answer 2

[Владимир Оленин]

была у меня такая задача, с уточнением: кол-во строк: сотни тысяч, группировка по счетам
в результате выглядело так:
операция это:
id транзакции (до 20 операцийна транзакциювыходило в реальной жизни)
счет
дата
сумма (плюс или минус)
описание
логический тип (основная операция, комиссия, себестоимость и тд)
кешируемый_баланс_после_операции
кешируемая_себестоимость_рубля
кешируемый_средневзвешенный_курс

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

надеюсь, будет полезно.

Comments

[Павел Тысляцкий]

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

[1x1]

Или добавить ещё одну транзакцию для отмены неподтверждённой. Получится прозрачнее для возможных проверок.

[Владимир Оленин]

не, лучше всего у транзакции добавить тип и статус. тип = приход, расход, статус = заявка, оплачена, отказана и прочее. а у операции добавить поле изменяет_баланс = 0 или 1. тебе нужно будет перепросчитывать все операции с датой позже изменяемой. обычно их немного, потому что релко бывают корректировки за прошлый год.