I_m_MadДействительно, готовой системы под наши требования пока найти не удается.
.....8<.....
Отдать доработку сторонней фирме - долго и дорого.
И врядле найдете...Может у какой-то фирмы-стаптапа только, если повезет ее найти...

Никакая серьездная billing-система нестоит <10K...
Доработки, как правило делает сам производитель или его партнеры.
Про "эти деньги" лучше вообще неупоменать.

Сами же, при очень благоприятных условиях,
сможите сделать и запустить свою систету... ну пол-года...
Так как руководство нежелает/неимет возможности вкладывать в "это" деньги,
будут набраны люди "по-дешевле"...
На первый срок запуска это не повлияет,
зато на следующие версии (с новыми требованиями) ой-как...

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

Как пример, если типовая billing'oвая система справляться с 80% задач,
то в определенные моменты, когда возрастает активность пользователей
(типа праздник какой-то,выходной,Новый год и т.д.), случаються мягко говоря - неприятности, которые могут приносит существенные потери и простои. С одной стороны, можно постававит лучше hardware + теже кластеры, но это очень сильно увеличит расходы, а-ля лицензии и т.д. Очень хорошо, если в этом есть целесообразность с точки зрения денег. А если нет?

Иногда, решения бывают очень простыми.
Большенство (если почти невсе) биллингов работают по типу [какой-то биллинговый процесс/сервер]->[база], т.е. как только пришел log,CDR, сразу его пишем в базу (еще скорее всего и считает log,CDR какая-нибудь процедура/триггер). Вот и получаеться что при 100 сессий в секунду все OK, а при 1000 - ж..а всему.
А если поступить так [какой-то биллинговый процесс/сервер]->[сервер сообщений]->[читаем инфо и пишем в базу]->[база], получаем что при 1000 сессиях скорость поподания log/cdr в сервер сообщений намного больше чем в базу, а из базы то что и при 100 сессий. Единственный момент, что 1000-сессия окажеться в базе "в течении какого-то времени", другими словами все происходит асинхронно, но при этом вся система работает безперебоев. А это и главное для near/real-time billing'ов.

Garya
Биллинговая система, как правило, не содержит каких-либо сложных алгоритмов обработки информации. Самое главное - это объемы, скорость и надежность.
Это уже специфика биллинга.
Бывает просто кол-во MB (минут) x цена, бывает "когда,куда,откуда,во сколько, сколько было туда вчера и на сколько", да "еще посчитаем агента/дилера" и т.д.

I_m_Mad
1. Загрузка логов. Биллинг должен работать с готовыми логами CGP (почта), netgraph (на роутере), squid (это прокси), т.е. загружать все это каждый день и обсчитывать,. В базе должна присутствовать инфа о посещенных урл (ее дает прокси).


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

Совсем разные вещи.

Пользователь
to SQL Developer - Где бы поподробнее почитать про архитектуру подобных биллингов?

Где черному по белому расписано что и как "надо делать" - невстречал :-)

В основном - case studies,сайты компаний,конференции и т.д. и т.д.
Другими словами типа "читаешь между строк",
ну и конечно умеються ввиду "их" и собственные грабли от той или иной системы...

I_m_Mad
Склонить руководство в сторону разработки представляется..ммм.. не слишком вероятным. Большие сроки, риски, тем более что собрать команду программеров, организовать процесс разработки... вряд ли это понравится вождям... Но, конечно, как вариант предложу.
Если руководство решало >0.5 года, нужен биллинг или нет, то
>> Большие сроки
это уже тогда >2 лет :-)

Валентин К
Прочитать про архитектуру бининговых систем негде, потому что это надо видеть, а не читать про это.

Ну и что же вы там увидите то?
Без теоритических/практических знаний, с вероятностью 95% наступите на теже грабли что и другие. :-)

P.S.
Можно открыть капот машины, посмотрет, сказать "О! Как круто!", но от этого неприбавяться знаний о том, как работает двигатель

Валентин К
Вобщем искать надо кроме билинговой системы еще и нормального архитектора систем учета.
Лучше сперва найти человека, а уже потом billing :-)
Дешевле будет :-)

I_m_Mad Да и попытка эта не далеко первая... и сами биллинг писали, вот только он был не "онлайновый".

А если сами что-то делали уже, то используете то?
Кто мешает грузить данные каждые 5 минут (как пример),
не real-time, но "hot" billing получаеться :-)

I_m_Mad
Согласен. Вот только людей таких в пределах досягаемости не сказать чтобы нет, но...почти нет;
Нужных людей никогда нету :-)

I_m_Mad
максимум рассчитывать на человека, который _работал_ с каким-либо готовым решением, и который может _посоветовать обратить внимание_ на такою-то систему.

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

Пользователь SQL Developer Пользователь
to SQL Developer - Где бы поподробнее почитать про архитектуру подобных биллингов?

Где черному по белому расписано что и как "надо делать" - невстречал :-)
...
1) Такого не может быть - потому что такого не может быть никогда...
2) Может какой-то пример существующей системы - описание архитектуры, реализации...
3) Хотя бы общее описание проблем биллингов - масштабируемости (рост транзакций с сохранением времени отклика)...
Не совсем понятно, что этим хотели сказать.
Что одного правильного решения в этой жизни небывает??

Пользователь SQL Developer Пользователь
to SQL Developer - Где бы поподробнее почитать про архитектуру подобных биллингов?

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

Совсем просто - где бы почитать поподробней про строительство биллингов? именно онлайн (решение принимается во время коннекта клиента) биллингов.
Сколько реализаций - столько и "строителей".
У меня нету линка на "документ"...

Ищите
www.google.com

Здесь собраны n-oe кол-во реализаций "небольших" billingov
http://www.telecom-portal.com/

Больших игроков можно найти здесь, например
http://www.iir-billingsystems.com/