Работа UTM5 и СУБД при высокой загрузке и кол-ве клиентов
По тому что было доделано:
1) Своя статистика
2) Своя админка
4) Фрирадиус
5) Винтрей свой
6) Индексы свои в базе
7) Триггеры и доп поля в котрые вносится дата изменения строки(типа `dt` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,) потом на основании даты запускаются скрипты которые чтото делают
так как статистика своя, и админка, в архивные таблицы пихаю все у которых допустим больше пары миллионов записей, паймент_транзакшин, мессаджес итп, кроме блок_инфо
9) Перепарсиватель детальной статистики и раскладывания ее сразу по файлам аккаунтам юзеров..
10) Счас обдумываем потихоньку вариант предколектора трафика, который будет на основании классов трафика и тарифных планов у пользователей, дропать ненуный трафик чтоы не грузить этим биллинг
(видимо дадим анлимным юзерам на статистике решать коллекционировать для них трафик или нет, остальное нафиг)
11) Бекапирование данных, ну ерунда конечно, но по сравнению с оригинальным скриптом бекапа, вообщем просто сделано правильно.
12) Своя Интеграцис с платежными системами
13) Свой интерфейс работы со счетами и контрагентами, сверки там, выдача счетов, контроль подписей актов итп..
14) Свои отчеты по биллингу, тот же самый основной отчет по сути только инфа берется не из транзакций, а из инвойсов.
15) динашейп был свой (переросли)
Собственно вот и все доработки (ну моет что и забыл )
1) Своя статистика
2) Своя админка
4) Фрирадиус
5) Винтрей свой
6) Индексы свои в базе
7) Триггеры и доп поля в котрые вносится дата изменения строки(типа `dt` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,) потом на основании даты запускаются скрипты которые чтото делают
так как статистика своя, и админка, в архивные таблицы пихаю все у которых допустим больше пары миллионов записей, паймент_транзакшин, мессаджес итп, кроме блок_инфо9) Перепарсиватель детальной статистики и раскладывания ее сразу по файлам аккаунтам юзеров..
10) Счас обдумываем потихоньку вариант предколектора трафика, который будет на основании классов трафика и тарифных планов у пользователей, дропать ненуный трафик чтоы не грузить этим биллинг
(видимо дадим анлимным юзерам на статистике решать коллекционировать для них трафик или нет, остальное нафиг)
11) Бекапирование данных, ну ерунда конечно, но по сравнению с оригинальным скриптом бекапа, вообщем просто сделано правильно.
12) Своя Интеграцис с платежными системами
13) Свой интерфейс работы со счетами и контрагентами, сверки там, выдача счетов, контроль подписей актов итп..
14) Свои отчеты по биллингу, тот же самый основной отчет по сути только инфа берется не из транзакций, а из инвойсов.
15) динашейп был свой (переросли)
Собственно вот и все доработки (ну моет что и забыл
)Magnum72 писал(а):По тому что было доделано:
1) Своя статистика
2) Своя админка
4) Фрирадиус
5) Винтрей свой
6) Индексы свои в базе
7) Триггеры и доп поля в котрые вносится дата изменения строки(типа `dt` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,) потом на основании даты запускаются скрипты которые чтото делают
9) Перепарсиватель детальной статистики и раскладывания ее сразу по файлам аккаунтам юзеров..
10) Счас обдумываем потихоньку вариант предколектора трафика, который будет на основании классов трафика и тарифных планов у пользователей, дропать ненуный трафик чтоы не грузить этим биллинг
(видимо дадим анлимным юзерам на статистике решать коллекционировать для них трафик или нет, остальное нафиг)
11) Бекапирование данных, ну ерунда конечно, но по сравнению с оригинальным скриптом бекапа, вообщем просто сделано правильно.
12) Своя Интеграцис с платежными системами
13) Свой интерфейс работы со счетами и контрагентами, сверки там, выдача счетов, контроль подписей актов итп..
14) Свои отчеты по биллингу, тот же самый основной отчет по сути только инфа берется не из транзакций, а из инвойсов.
15) динашейп был свой (переросли)
Собственно вот и все доработки (ну моет что и забыл
