Биллинг, Вопросы по работе

Сначала определись, что именно ты учитываешь. Т.е. что является объектом учёта - календарный месяц, сутки, произвольные 30 дней и т.д.

У нас вариант 2. postgresql, 60k - время отсилы 50 секунд, правильно проектируйте БД, например разнесите авторизацию, траффик и финансовые таблицы в tablespace'ы например на разных винтах, pg_xlog тоже желательно хранить отдельно, а все вкучу можно к примеру связывать через VIEW.... Давайте больше инфы.... Вариантов оптимизации *уева туча, безвыходных ситуаций не бывает, ну а с вашими вопросами сомневаюсь что у вас хотя бы 1к юзеров есть...(извините)

юзеров вообще нет — разработка же.

Окончательно выбрал вариант (1) снимать ежедневно ( цена_услуги / количество_дней_в_месяце ), так как он обладает рядом плюсов: таких как легкая смена тарифа, простая возможность временного приостановления услуги. Да и ближе как-то к облачному.

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

а если девочки из абон-отдела напутали с тарифом, и это обнаружилось в середине месяца?

У нас пользуются методом (2). Ночь первого числа закрываешь базу от операторов, пусть себе считает

дело вкуса, у метода №1 есть свои преимущества, а у метода №2 свои, в финансовом плане :)

> (2) по реализации самый простой, но например при 100к пользователей ночью первого числа база будет нагружена

А если отталкиваться не от обязательности операций расчёта, а от данных которые нужны? Т.е. не делаем в начале каждого месяца пересчёт по тарифу, а предоставляем данные о сумме на счету вычитая в реальном времени необходимое количество средств с баласа при запросе статистики пользователем (оборудованием) согласно тарифному плану? Поясню на примере.Допустим пользователь внёс 500р. на счёт, тарифный план у нас 250 в месяц, если пользователь запросит данные о счёте через месяц, то в базе так и остаётся 500, но показывается только 250р. на счету. По истечении 2-х месяцев уже показывается 0 (хотя в базе так и остаётся 500р.) и доступ блокируется. Как такой вариант?

60к - на таких объемах можно даже не париться с оптимизацией.

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

> есть свои недостатки - смена тарифа в середине месяца, временное приостановление услуги — эти операции нужно хранить, вариант прекрасный, но для системы размером с банк. Конечно хранить операции по счету нужно в любом случае, но не для целей расчёта.

Ну так фиксируйте в этом случае сумму делая грубо говоря UPDATE ячейки с вычисленным на текущий момент остатком средств в базе, после этого расчитывайте новый тариф от этой суммы в ячейке или оставляйте её как есть при приостановке услуги. Всяко лучше обработать одну учётную запись сейчас при необходимости внесения изменений чем 60к за ночь )