[gtbear]

Не скажите,батенька,там хоть пока и кастрированный..но PL/SQL.Впрочем ребята из MySQL AB слезно клянутся что все расширят и дополнят..а на просторах ихнего багтрака появилось куча фичер регвестов на тему процедур.

P.S.Ну канеш пока многих вещей нет приходится приделывать костыли..например AV-пары отдаваемые радиусу у меня формируются на этапе авторизации и скидываются во временку..откуда потом забираются.

P.P.S.Главное что-то написать можно..остальное со временем бует.

[zcat]

Когда делаешь INSERT - никаких выборок не делается, а просто добавляется запись и все. Нагрузка на машину с БД минимальная.

Нда, советчик блин.

А ты не думал что пакеты между интерфейсами летают быстрее чем даже MySQL успевает записи вставлять ? А что когда ты запускаешь delete ... для того чтобы старую статистику пожать, делается блокировка на запись на всю таблицу ? MySQL на среднем сервачке типа 4го пенька с SATA-дисками способна делать вставку ~3000 записей в секунду, это если в таблицу делается только запись, без select'ов по ней. Ну и посчитай теперь при каких объемах трафика весь твой биллинг загнется раком потому что будет не в состоянии весь трафик просто записать в БД.

В БД надо писать только те данные, которые реально потом будут использоваться для расчетов. Например статистику раз в 5 минут. А если нужно детализацию по пакетам - пиши их заголовки в файлы и храни эти файлы сколько влезет.

 

Даже не представляю себе для какой задачи заголовок каждого пакета нужно хранить в БД. Вероятно для того чтобы в конце дня дать серверу прикурить простым запросом с select count(*) ?

[Forst]

тиблица zones: name, start_ip, stop_ip

например:

'localnet',ip_to_int('192.168.0.0'), ip_to_int('192.168.15.255');

'media',ip_to_int('192.168.16.0'),ip_to_int('192.168.16.10');

'media',ip_to_int('1.2.3.4'), ip_to_int('1.2.3.8');

'peering',ip_to_int('10.0.0.0'),ip_to_int('10.0.255.255');

 

таблица определения класса услуг service_kinds: тар.план, зона-источник, зона-приемник, услуга (можно дополнить "время начала - время окончания", "день недели" - по желанию)

например:

'basic','localnet','localnet','local_traf'

'basic','media','localnet','media_traf_in'

'basic','localnet','media','media_traf_out'

'basic','peering','localnet','peer_traf_in'

'basic','localnet','peering','peer_traf_out'

 

таблица правил тарификации услуг по тарифному плану:

tafif_schema: tarif, service, round, price

'basic','local',1,0 (бесплатно)

'basic','media', 1024*1024*1024,10 (10 руб/гигабайт)

'basic','peer_traf_in',1024*1024,1 (1 руб/мегабайт )

'basic','peer_traf_out',1,0 (бесплатно)

'basic','inet_traf_in',1024*1024,3.50 (3.50 руб/мегабайт )

'basic','inet_traf_out',1,0 (бесплатно)

 

Определение зоны по IP-адресу лучше делать хранимой процедурой, которая при невозможности найти запись в таблице зон для данного адреса будет возвращать предопределенное значение 'inet' (т.е. все явно не обозначенные зоны считаются интернетом). Аналогично при невозможности найти услугу для двух указанных зон трафика можно возвращать предопреленное значение "none", и не тарифицировать его, лобо тарифицировать по специально обученной строке с нулевым тарифом - для единообразия.

 

Такая схема позволит достаточно гибко рулить несколькими тарифными планами (например, в одном аська считатеся отдельно, а в другом - как обычный интернет), при этом имея одну таблицу зон....

Один из самых класных советов за весь топик :-)

А вот если надо тарифицировать локальный трафик.

Тогда у билинга на входе будет SrcIP == localnet && DstIP == localnet.

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

[balamutang]

Когда делаешь INSERT - никаких выборок не делается, а просто добавляется запись и все. Нагрузка на машину с БД минимальная.

Нда, советчик блин.

А ты не думал что пакеты между интерфейсами летают быстрее чем даже MySQL успевает записи вставлять ? А что когда ты запускаешь delete ... для того чтобы старую статистику пожать, делается блокировка на запись на всю таблицу ? MySQL на среднем сервачке типа 4го пенька с SATA-дисками способна делать вставку ~3000 записей в секунду, это если в таблицу делается только запись, без select'ов по ней. Ну и посчитай теперь при каких объемах трафика весь твой биллинг загнется раком потому что будет не в состоянии весь трафик просто записать в БД.

В БД надо писать только те данные, которые реально потом будут использоваться для расчетов. Например статистику раз в 5 минут. А если нужно детализацию по пакетам - пиши их заголовки в файлы и храни эти файлы сколько влезет.

 

Даже не представляю себе для какой задачи заголовок каждого пакета нужно хранить в БД. Вероятно для того чтобы в конце дня дать серверу прикурить простым запросом с select count(*) ?

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

[Чупа-Чупс]

А ты не думал что пакеты между интерфейсами летают быстрее чем даже MySQL успевает записи вставлять ? А что когда ты запускаешь delete ... для того чтобы старую статистику пожать, делается блокировка на запись на всю таблицу ? MySQL на среднем сервачке типа 4го пенька с SATA-дисками способна делать вставку ~3000 записей в секунду, это если в таблицу делается только запись, без select'ов по ней. Ну и посчитай теперь при каких объемах трафика весь твой биллинг загнется раком потому что будет не в состоянии весь трафик просто записать в БД.

В БД надо писать только те данные, которые реально потом будут использоваться для расчетов. Например статистику раз в 5 минут. А если нужно детализацию по пакетам - пиши их заголовки в файлы и храни эти файлы сколько влезет.

 

Даже не представляю себе для какой задачи заголовок каждого пакета нужно хранить в БД. Вероятно для того чтобы в конце дня дать серверу прикурить простым запросом с select count(*) ?

при чём тут скорость полёта пакетов? пакеты аггрегируются netflow или каким-нить другим способом - это снижает нагрузку. дальше используем транзакционный InnoDB вместо MyIASM - там блокировка по записям, а не по таблицам.

 

а ещё есть очень питательная конструкция INSERT ... ON DUPLICATE UPDATE ... - в таблице делается уникальный индекс, например, (SrcIP, DstIP, Date, Hour) - и если за час будет больше одного потока от одной конкретной машины к другой, то эти потоки будут храниться одной записью

 

А вот если надо тарифицировать локальный трафик.

Тогда у билинга на входе будет SrcIP == localnet && DstIP == localnet.

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

а именно обоим и надо. одному - за исходящий, другому - за входящий

[zcat]

Чупа-Чупс, хочешь я тебе секрет открою :) InnoDB с транзакциями работает процентов на 20 медленее, чем MyISAM без транзакций.

 

Есть факт: если напрямую фигачить статистику в базу, биллинг заткнется из-за тормозов базы. Не веришь - увидишь со временем.

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

[CWN]

сбор статистики по нетфлоу:

1. коллектор ловит и предагрегирует все приходящие netflow, по типам траффика.

2. C некоторым интервалом (2-5-10) минут сбрасывает все накопленное в биллинг (читай БД), где производится списание средств со счета клиента с инкрементированием счетчиков по типам траффика.

3. С некоторым интервалом (15-20-30 минут) в биллинге (БД), производится постагрегация сброшенной инфы и перенос ее в общую статистику.

 

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

 

ЗЫ. Это схема проверена и работает уже больше 5 лет ;)

[Чупа-Чупс]

Чупа-Чупс, хочешь я тебе секрет открою :) InnoDB с транзакциями работает процентов на 20 медленее, чем MyISAM без транзакций.

 

Есть факт: если напрямую фигачить статистику в базу, биллинг заткнется из-за тормозов базы. Не веришь - увидишь со временем.

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

по выборке InnoDB - медленнее, по апдейтам - разве? я не просто так упомянул update on duplicate - чтобы не только все пакеты при помощи netflow паковать в потоки ( в локальной сети без этого - абсолютно никак), но и однородные потоки ещё собирать в базе вместе. ну а уж от предварительной обработки данных вообще отказываться нельзя - либо у пользователя изменится IP-адрес, либо у него их несколько - поэтому, например, у себя я сразу в ресивере обрабатываю и классифицирую flows, определяю, к какому юзеру он относится, бла-бла-бла, а потом ещё и пакую все потоки за час в одну запись. никаких файлов не надо. но если уж очень хочется поизвращаться, то всегда можно файл заменить той же таблицей БД ;)

Изменено 12 октября, 2006 пользователем Чупа-Чупс

[Forst]

Сваял веб-морду для управления тарифами.

Зацените: http://fagot.ifastnet.com/bi3/tariffs.php

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

[Forst]

Как сделать более гибкую систему?

Данная система:

Тариф состоит из сервисов,

Сервис состоит из зоны отправки, зона назначения, правила.

Зоан состоит из диапазонов ИП-адремов.

Правило состоит из времени начала, времени конца действия правила и стстоимости определённого объёма трафика.

Ну вобщем всё как Kuzmich написал.

 

Но это очень негибко. Есть ли какие-нибудь идеи, в направлении использования скриптов?

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

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

 

Может есть у кого какие мысли?

[Kuzmich]

Как сделать более гибкую систему?

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

 

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

 

 

Наиболее гибкие системы имеют язык программирования. Тот же Excel, например, имеет Visual Basic - пожэтому на нем в принципе можно и биллинг написать, хотя он для этогоне предназначен.

 

Писать собственный скриптовой язык для встраивания в биллинг тебе не надо - у тебя уже есть PL/SQL (или его аналог в той субд, которую ты используешь). Дай оператору-настройщику возможность писать прямо на нем! (EXECUTE IMMEDIATE foreva, хоть и тормозит).

 

Например, вместо того, чтобы ставить абонентскую плату 100 рублей, и самостоятельно думать о том, надо ли вычилсять ее пропорционально дням использвания, позволь автору тарифного плана вносить в таблицы не только числа, но и ссылки на вычисляемые на лету значения, которые он сам сможет создавать... правда, для получения хоть какой-то производительности придется компилировать эти значения в хранимые процедуры, создавать прототипы таблиц для хранения этих значений в оперативной памяти в процессе вычислений (declare values values_proto%rowtype), и перекомпилировать большие куски ядра после изменений в списках этих вычислимых значений...

 

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

 

Следующим шагом вообще может быть создание компилируемых тарифных планов, построенных по древовидной схеме, в узлах которой находятся условные операторы IF и CASE (например, IF зона_удаленного_адреса=internet), а в листьях - заполнение значений, необходимых для тарификации ( например, услуга:='inet_in', единица измерения :='мегабайт', количество :=200, политика тарификации:='ночь', договор := 'ИТ-124', учетный период :='октябрь 2006', учетная категория := 'Доступ в интернет' и т.д.) с последующим начислением конкретного бабла по предопределенным схемам, на входе которых эти самые значения.

 

 

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

 

В общем - задача явно не для одного человека, и не на один год.

[jab]

Kuzmich, это Вы amstat образца 1996 года описали. :-)

Правда он без всякого оракла работал на mSQL. Ну и с некоторыми

оговорками, которые с учетом древности продукта незначительны.

[Forst]

Ну щас я сделал так.

Раз в пять минут в память билинга грузится (из скрипта) информация по текущей стоимости для определённого тарифа и определёной зоны.

Т.е. заполняется массив:

Tariff_ID - номер тарифа

Traffic_Type - тип трафика (исходящий/входящий/время)

First_Zone_IP - первый ип диапазона

Last_Zone_IP - последний ип диапазона

Cost - стоимость вычисляется при обработке скрипта

 

Про компиляцию скрипта, я думал, но эта задумка мне показалась через чур сложно и использовать её надо не в АСР, а в искусственном интеллекте.

[jab]

Ну щас я сделал так.

Раз в пять минут в память билинга грузится (из скрипта) информация по текущей стоимости для определённого тарифа и определёной зоны.

Т.е. заполняется массив:

Tariff_ID - номер тарифа

Traffic_Type - тип трафика (исходящий/входящий/время)

First_Zone_IP - первый ип диапазона

Last_Zone_IP - последний ип диапазона

Cost - стоимость вычисляется при обработке скрипта

 

Про компиляцию скрипта, я думал, но эта задумка мне показалась через чур сложно и использовать её надо не в АСР, а в искусственном интеллекте.

ROTFL

[Igor Diakonov]

Определение зоны по IP-адресу лучше делать хранимой процедурой, которая при невозможности найти запись в таблице зон для данного адреса будет возвращать предопределенное значение 'inet' (т.е. все явно не обозначенные зоны считаются интернетом). Аналогично при невозможности найти услугу для двух указанных зон трафика можно возвращать предопреленное значение "none", и не тарифицировать его, лобо тарифицировать по специально обученной строке с нулевым тарифом - для единообразия.

 

Такая схема позволит достаточно гибко рулить несколькими тарифными планами (например, в одном аська считатеся отдельно, а в другом - как обычный интернет), при этом имея одну таблицу зон....

Собственно для проверки попадания потока в определённый класс трафика можно использовать след алгоритм: http://www.csse.monash.edu.au/~lloyd/tilde.../Tree/PATRICIA/

Реализция на перле: http://search.cpan.org/dist/Net-Patricia/Patricia.pm (кстати, там есть и пример на С).

This module uses a Patricia Trie data structure to quickly perform IP address prefix matching for applications such as IP subnet, network or routing table lookups. The data structure is based on a radix tree using a radix of two, so sometimes you see patricia implementations called "radix" as well. The term "Trie" is derived from the word "retrieval" but is pronounced like "try". Patricia stands for "Practical Algorithm to Retrieve Information Coded as Alphanumeric", and was first suggested for routing table lookups by Van Jacobsen. Patricia Trie performance characteristics are well-known as it has been employed for routing table lookups within the BSD kernel since the 4.3 Reno release.

The BSD radix code is thoroughly described in "TCP/IP Illustrated, Volume 2" by Wright and Stevens and in the paper ``A Tree-Based Packet Routing Table for Berkeley Unix'' by Keith Sklower.

 

Примерно делаем так:

10.0.0.0/8->192.168.0.0/24 - class1

10.0.0.0/8->192.168.1.0/24 - class1

10.0.0.0/8->0.0.0.0/0 - class2

192.168.1.0/24->0.0.0.0/0 - class3

Создаются деревья (сеть, возвращаемая ссылка):

Дерево1:

1)10.0.0.0/8, дерево2

2)192.168.1.0/24, дерево3

Дерево2:

1) 192.168.0.0/24, 1

2) 192.168.1.0/24, 1

3) 0.0.0.0/0,2

Дерево3:

1) 0.0.0.0/0,3

 

При разборе строчки:

1) Ищем в дереве1 по src_ip, получаем ссылку на второе дерево.

2) Ищем во втором дереве по dst_ip, получаем класс трафика.

 

 

При достаточно сложных классах (скажем, описание класса трафика состоит из 5-10 записей) работает значительно быстрее последовательного перебора.

 

Кстати и для поиска соответствия IP какому-то пользователю идеально подходит....

Изменено 4 ноября, 2006 пользователем Igor Diakonov

[mlevel]

Извините что поднимаю старую тему, но перед началом разработки биллинговой системы дилема - что должно делать ядро этой самой системы(если мы говорим о масштабируемой системе, которая должна читать услуги, неважно, ето трафик или длительность звонков, etc.) и в каком виде его исполнять(cron | daemon). Помогите советами пожалуйста.

[Giga-Byte]

чёрт побери, а на..я в институте изучают IDF?

начните с гугла ->

IDF0

этапы создания программного продукта/обеспечения

этапы разработки программного обеспечения

технологии разработки программного обеспечения

 

 

смысл в том, чтобы всё описать и понять как должно работать - 70% времени

разработка 10-15% и отладка 15-20%

 

ну и естественно должен быть интерес этим заниматься, интузиазма не всегда достаточно,

и надо в живую видеть железки, с которыми этот биллинг будет взаимодействовать,

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

Изменено 24 января, 2011 пользователем Giga-Byte

[Ilya Evseev]

Извините что поднимаю старую тему, но перед началом разработки биллинговой системы дилема - что должно делать ядро этой самой системы(если мы говорим о масштабируемой системе, которая должна читать услуги, неважно, ето трафик или длительность звонков, etc.) и в каком виде его исполнять(cron | daemon). Помогите советами пожалуйста.

Скачайте Abills, установите, запустите, почитайте исходники и документацию.

И настанет Вам просветление.

 

Только не пытайтесь потом сдать его как собственный курсовик или диплом - нормальный препод, не тратя время на чтение очередной макулатуры, просто тыкнет пальцем в первую попавшуюся строчку и спросит "а это чё?" и Ваше меканье-беканье моментально Вас выдаст ;)

[Ivan Rostovikov]

>чёрт побери, а на..я в институте изучают IDF?

 

Это Вы про IDEF ?