Традиционно при построении биллинговых систем база данных (БД) используется в качестве хранилища исходных, а иногда и агрегированных данных. В некоторых случаях кроме основного хранилища используется ещё и дополнительная база данных для целей предбиллинга.
При таком подходе главным требованием к используемой системе управления базами данных (СУБД) является минимальное время выполнения операций изменения, удаления и вставки строк в таблицы базы данных. Все остальные свойства и возможности СУБД, включая используемую модель организации данных, приобретают второстепенное значение. В этом свете логически (и экономически) оправданным выглядит использование в автоматизированных системах расчётов СУБД класса популярной MySQL.
Собственно сама биллинговая система представляет из себя некий набор программных модулей, написанных на самых различных языках программирования – от скриптовых до высокоуровневых.
Важно отметить, что в итоге каждый из этих модулей работает с данными, хранящимися в базе. В зависимости от назначения модуля производятся операции ввода, удаления или модификации данных, и почти всегда ещё и чтения.
Выбор языка программирования для создания модулей – дело вкуса и привычки и не носит принципиального характера, поскольку для задач биллинга общее время выполнения отдельной операции почти целиком определяется скоростью исполнения запросов к базе данных.
Перед выполнением этих операций модуль должен обеспечить соединение с БД. Здесь возможны два варианта: создание соединения для выполнения каждой операции или обеспечение постоянного подключения. Каждый из вариантов имеет свои плюсы и минусы, однако очевидно, что оба подхода требуют определённого расхода вычислительных ресурсов системы.
Парадоксальная ситуация возникает, когда источник первичных данных, например RADIUS-сервер, сам направляет их в БД. Некий внешний программный модуль, предназначенный для обработки этих данных должен подключиться к базе, считать необходимые данные, а затем ещё и вернуть в базу результат своих действий. Отдельно здесь встаёт вопрос об определении события в системе, которое должно привести к запуску модуля и формированию условий выборки данных, подлежащих обработке.
Поскольку вся бизнес-логика системы вынесена за пределы БД, обеспечение корректности вводимых данных и их непротиворечивости целиком ложится на плечи программиста-разработчика. Специальных усилий потребует и аспект поддержки транзакционности операций с данными.
Отсутствие в БД такого структурного элемента, как представление (view) приводит к генерации значительного количества последовательных запросов к разным таблицам, что затрудняет написание и отладку программного кода и создаёт дополнительную нагрузку на сервер БД.
Хочется подчеркнуть, что биллинг – это, прежде всего, система работы с данными, зачастую весьма значительных объёмов. А для работы с данными существует специализированное программное обеспечение – СУБД. Если следовать этой простой логике, то напрашивается вывод, что акцент при проектировании автоматизированной системы расчетов (АСР) должен быть перенесен на максимальное использование возможностей современных СУБД. Этот постулат и лёг в основу архитектуры предлагаемой вашему вниманию АСР «ASBS».
В представляемой концепции ядром биллинга является база данных, поэтому к выбору СУБД мы подошли со всей возможной тщательностью. В результате мы остановились на объектно-реляционной системе управления базами данных PostgreSQL. На данный момент это наиболее развитая из существующих открытых СУБД, которая является реальной альтернативой коммерческим базам данных.
Следствием выбора в качестве ядра системы PostgreSQL, распространяемой под либеральной OSD-лицензией, стало принятия решения о построении всей АСР на программном обеспечении с открытым исходным кодом.
Задуманное было претворено в жизнь и в результате была создана биллинговая система «ASBS», лицензированная 13.05.2009 ЦЭС «Инфоком» под № OC-1-CТ-0229. Она предназначена для использования операторами связи, Интернет-провайдерами, коммерческими предприятиями и организациями.
Одной из основных особенностей системы стала простота архитектуры.
Ядром системы является база данных, работающая под управлением сервера PostgreSQL. Вся логика системы находится в базе данных и описывается отношениями между сущностями, набором ограничений, проверок, правил, триггеров и функций. Пригодилась и предоставляемая PostgreSQL возможность наследования таблиц в рамках объектно-ориентированной модели. Тщательная проработка структуры БД, выбор оптимальных типов данных колонок в таблицах, использование всего предоставляемого СУБД спектра механизмов индексирования и акцент на максимально возможное применение триггеров позволили построить высокопроизводительную и надёжную систему.
Источниками данных для тарификации могут служить сессии RADIUS-сервера и IP-трафик. Обсчёт услуг и соответствующие списания происходят в режиме реального времени.
Движение финансовых средств по лицевым счетам клиентов обеспечивают WEB-интерфейсы системных пользователей и абонентов, написанные с применением HTML, PHP и JavaScript, интерфейсы к автоматизированным платёжным системам (электронные платежи, продукты «1С» и т.п.) и подсистема управления, производящая периодические списания абонентской платы за предоставленные услуги.
Подсистема управления обеспечивает также загрузку и агрегацию IP-трафика по протоколам NetFlow и SFlow, разрешение и запрещение доступа в сеть, изменение скорости доступа, динамическое изменение параметров сессий и их прерывание, запуск обслуживающих систему процедур. Она построена на планировщике задач pgAgent, непосредственно выполняющем SQL-запросы к БД или запускающем внешние скрипты управления.
Система поддерживает подключения пользователей к сети с коммутируемым доступом (DIALUP), со статическим IP-адресом, по протоколу 802.1x, через туннели (VPN) и с использованием DHCP information option 82 (CLIPS). Число подключаемых пользователей не лицензируется.
Опыт эксплуатации АСР «ASBS» провайдерами услуг доступа в Интернет показал, что система уверенно обслуживает десятки тысяч клиентов, не предъявляя особых требований к серверному оборудованию.
На официальном сайте системы кроме дополнительной информации Вы сможете получить полнофункциональный демо-доступ ко всем интерфейсами системы.
При таком подходе главным требованием к используемой системе управления базами данных (СУБД) является минимальное время выполнения операций изменения, удаления и вставки строк в таблицы базы данных. Все остальные свойства и возможности СУБД, включая используемую модель организации данных, приобретают второстепенное значение. В этом свете логически (и экономически) оправданным выглядит использование в автоматизированных системах расчётов СУБД класса популярной MySQL.
Собственно сама биллинговая система представляет из себя некий набор программных модулей, написанных на самых различных языках программирования – от скриптовых до высокоуровневых.
Важно отметить, что в итоге каждый из этих модулей работает с данными, хранящимися в базе. В зависимости от назначения модуля производятся операции ввода, удаления или модификации данных, и почти всегда ещё и чтения.
Выбор языка программирования для создания модулей – дело вкуса и привычки и не носит принципиального характера, поскольку для задач биллинга общее время выполнения отдельной операции почти целиком определяется скоростью исполнения запросов к базе данных.
Перед выполнением этих операций модуль должен обеспечить соединение с БД. Здесь возможны два варианта: создание соединения для выполнения каждой операции или обеспечение постоянного подключения. Каждый из вариантов имеет свои плюсы и минусы, однако очевидно, что оба подхода требуют определённого расхода вычислительных ресурсов системы.
Парадоксальная ситуация возникает, когда источник первичных данных, например RADIUS-сервер, сам направляет их в БД. Некий внешний программный модуль, предназначенный для обработки этих данных должен подключиться к базе, считать необходимые данные, а затем ещё и вернуть в базу результат своих действий. Отдельно здесь встаёт вопрос об определении события в системе, которое должно привести к запуску модуля и формированию условий выборки данных, подлежащих обработке.
Поскольку вся бизнес-логика системы вынесена за пределы БД, обеспечение корректности вводимых данных и их непротиворечивости целиком ложится на плечи программиста-разработчика. Специальных усилий потребует и аспект поддержки транзакционности операций с данными.
Отсутствие в БД такого структурного элемента, как представление (view) приводит к генерации значительного количества последовательных запросов к разным таблицам, что затрудняет написание и отладку программного кода и создаёт дополнительную нагрузку на сервер БД.
Хочется подчеркнуть, что биллинг – это, прежде всего, система работы с данными, зачастую весьма значительных объёмов. А для работы с данными существует специализированное программное обеспечение – СУБД. Если следовать этой простой логике, то напрашивается вывод, что акцент при проектировании автоматизированной системы расчетов (АСР) должен быть перенесен на максимальное использование возможностей современных СУБД. Этот постулат и лёг в основу архитектуры предлагаемой вашему вниманию АСР «ASBS».
В представляемой концепции ядром биллинга является база данных, поэтому к выбору СУБД мы подошли со всей возможной тщательностью. В результате мы остановились на объектно-реляционной системе управления базами данных PostgreSQL. На данный момент это наиболее развитая из существующих открытых СУБД, которая является реальной альтернативой коммерческим базам данных.
Следствием выбора в качестве ядра системы PostgreSQL, распространяемой под либеральной OSD-лицензией, стало принятия решения о построении всей АСР на программном обеспечении с открытым исходным кодом.
Задуманное было претворено в жизнь и в результате была создана биллинговая система «ASBS», лицензированная 13.05.2009 ЦЭС «Инфоком» под № OC-1-CТ-0229. Она предназначена для использования операторами связи, Интернет-провайдерами, коммерческими предприятиями и организациями.
Одной из основных особенностей системы стала простота архитектуры.
Ядром системы является база данных, работающая под управлением сервера PostgreSQL. Вся логика системы находится в базе данных и описывается отношениями между сущностями, набором ограничений, проверок, правил, триггеров и функций. Пригодилась и предоставляемая PostgreSQL возможность наследования таблиц в рамках объектно-ориентированной модели. Тщательная проработка структуры БД, выбор оптимальных типов данных колонок в таблицах, использование всего предоставляемого СУБД спектра механизмов индексирования и акцент на максимально возможное применение триггеров позволили построить высокопроизводительную и надёжную систему.
Источниками данных для тарификации могут служить сессии RADIUS-сервера и IP-трафик. Обсчёт услуг и соответствующие списания происходят в режиме реального времени.
Движение финансовых средств по лицевым счетам клиентов обеспечивают WEB-интерфейсы системных пользователей и абонентов, написанные с применением HTML, PHP и JavaScript, интерфейсы к автоматизированным платёжным системам (электронные платежи, продукты «1С» и т.п.) и подсистема управления, производящая периодические списания абонентской платы за предоставленные услуги.
Подсистема управления обеспечивает также загрузку и агрегацию IP-трафика по протоколам NetFlow и SFlow, разрешение и запрещение доступа в сеть, изменение скорости доступа, динамическое изменение параметров сессий и их прерывание, запуск обслуживающих систему процедур. Она построена на планировщике задач pgAgent, непосредственно выполняющем SQL-запросы к БД или запускающем внешние скрипты управления.
Система поддерживает подключения пользователей к сети с коммутируемым доступом (DIALUP), со статическим IP-адресом, по протоколу 802.1x, через туннели (VPN) и с использованием DHCP information option 82 (CLIPS). Число подключаемых пользователей не лицензируется.
Опыт эксплуатации АСР «ASBS» провайдерами услуг доступа в Интернет показал, что система уверенно обслуживает десятки тысяч клиентов, не предъявляя особых требований к серверному оборудованию.
На официальном сайте системы кроме дополнительной информации Вы сможете получить полнофункциональный демо-доступ ко всем интерфейсами системы.