Предотвращение быстрого роста таблиц БД

[kaN5300]

Сейчас характеристики СУБД такие.

К-во обращений в секунду: 17
Максимальное к-во одновременных соединений: 18
Запросы UPDATE: 43%
discount_transactions_all: 40 млн / 6 Gb
discount_transactions_iptraffic_all: 14 млн / 2 Gb

Всего в базе 73 млн / 10 гигов.

Всё чаще приходится подчищать таблицы с транзакциями, чтобы уменьшить объём базы и увелисить производительность отчетов. В этой теме предлагаю систематизировать подходы к сокращению стремительного роста БД UTM.

Что мне видится из вариантов:

1) Увеличение traffic_agregation_interval
Выставлен в 1200. Можно еще немного поднять. На выходе получим меньшее число записей в таблицах за интервалл времени (сутки).

2) Ежедневная ротация таблиц с транзакциями и модификация клиентского интерфейса напильником для доступа к статистике. Не очень хочется лезть в УТМ с напильником.

3) Отнести безлимитных пользователей в другую подсеть, которая не пересекается ни с одним из классов трафика, создать еще один netflow-приемник на отдельном сервере и уже оттуда генерить отчеты по юзерам по заданным параметрам. Тогда львиная доля статистики безлимитчиков не будет попадать в базу нетапа.

Больше на ум ничего не пришло.

[Magnum72]

Сейчас характеристики СУБД такие.

К-во обращений в секунду: 17
Максимальное к-во одновременных соединений: 18
Запросы UPDATE: 43%
discount_transactions_all: 40 млн / 6 Gb
discount_transactions_iptraffic_all: 14 млн / 2 Gb

Всего в базе 73 млн / 10 гигов.

Всё чаще приходится подчищать таблицы с транзакциями, чтобы уменьшить объём базы и увелисить производительность отчетов. В этой теме предлагаю систематизировать подходы к сокращению стремительного роста БД UTM.

Что мне видится из вариантов:

1) Увеличение traffic_agregation_interval
Выставлен в 1200. Можно еще немного поднять. На выходе получим меньшее число записей в таблицах за интервалл времени (сутки).

2) Ежедневная ротация таблиц с транзакциями и модификация клиентского интерфейса напильником для доступа к статистике. Не очень хочется лезть в УТМ с напильником.

3) Отнести безлимитных пользователей в другую подсеть, которая не пересекается ни с одним из классов трафика, создать еще один netflow-приемник на отдельном сервере и уже оттуда генерить отчеты по юзерам по заданным параметрам. Тогда львиная доля статистики безлимитчиков не будет попадать в базу нетапа.

Больше на ум ничего не пришло.

Запросы UPDATE: 43%

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

[kaN5300]

Я еще тут вспомнил про radius accounting. Может ли его введение положительно отразиться на базе? Как понимаю, запись о потребленном трафике будет заноситьс только в случае разрыва/окончания pptp-сессии пользователя, которая частельно переваливает за 10 или 20 часов.

[bear]

радиус аккаунтинг плох тем, что абон на помегобайтщине может накачать за эти 24 часа(у нас макс время сессии 86400 секунд) СТОЛЬКО! что потом сам в ахуе бывает когда начинает смотреть баланс, а потом вынос мозга ТП/операторам(слезные бумаги на руководство), почему его по достижении 0 на балансе не отключили...
еще один минус в радиус аккаунтинг - непонятно как тарифицировать внутренний трафик, крендель криво прописал роуты(слетели роуты) и весь трафик из тогоже DC завернулся на впн, и начинается - "я не качал, все вранье, обираете сирых и убогих мироеды гацкие", бумага уходит в отдел разбора, и нагружает тем самым их, которые колупаются в флоу логах, выявляя качал/не качал...

[kaN5300]

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

[bear]

я щас с содроганием начинаю поглядывать на свою бд размером 30гигов...
а абоны все прут и прут, правда больше половины объема - это архивные таблицы... которые я думаю всетаки выгрузить дампом(за прошлый год), запаковать и нарезать на 5 двд, да сдать в архив
но есть другая проблемма
мою буйную голову все больше посещают тяжелые мысли, куда девать флоу...
у меня за месяц набегает гигов 700-800
при условии того что необходимо хранить их 3 года, даже уже и не знаю что придумать да куда писать
а главное как работать с ними, если даже поархивирую... такой объем разворачиваться только будет пол дня...

[mikkey finn]

флоу распарсеный по Магнуму на 700-800 гигов?

[kaN5300]

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

[Magnum72]

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

Ну у радиуса есть апдейты, но это нагружает циску..

[kaN5300]

Не совсем ясно, что за апдейты, что в них передается? У нас в роли насов фря с mpd.

[Magnum72]

я щас с содроганием начинаю поглядывать на свою бд размером 30гигов...
а абоны все прут и прут, правда больше половины объема - это архивные таблицы... которые я думаю всетаки выгрузить дампом(за прошлый год), запаковать и нарезать на 5 двд, да сдать в архив
но есть другая проблемма
мою буйную голову все больше посещают тяжелые мысли, куда девать флоу...
у меня за месяц набегает гигов 700-800
при условии того что необходимо хранить их 3 года, даже уже и не знаю что придумать да куда писать
а главное как работать с ними, если даже поархивирую... такой объем разворачиваться только будет пол дня...

А причем тут архивные таблицы? ты их разве в базе UTM5 хранишь?
Если да то нахрена? На том же сервере создаешь базу данных UTM5H и переносишь архивные таблицы туда, в таблице arhives соответственно переделываешь пути к таблицам с nametable_xxxxxx2008 на UTM5H.nametable_xxxxxx2008

У меня база UTM5 на начало месяца пару гигов занимает.. (я до кучи переношу в UTM5H данные из таблиц радиуса, сообщений )