Это необходимость если вы начинаете предоставлять в корне разные услуги.
Это вы про торговлю фруктами (апельсинами) :-))? Мы позиционируемся на рынке ISP.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение. Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен. Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет. При этом все проблемы — все лишь написать (найти в Инете) скрипт управления конкретным имеющимся оборудованием.
1. Когда БД используется как хранилище данных, то действительно — это всё отвлечённые фичи СУБД. Если же принять модель «биллинг = БД», то возможности, предоставляемые СУБД, выходят на передний план. Чем их больше и чем они изощрённее — тем проще создать надёжную и высокопроизводительную биллинговую систему.
2. «Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона. Конечно, здорово, что можно использовать любой источник данных, однако:
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
— исходные данные часто тоже надо хранить
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат? Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
В плагинах для работы системы нет никакой надобности, т.к. ядро общается с RADIUS-сервером без посредников. А именно: все конфигурационные настройки и сведения о сессиях хранятся в БД.
Да уж, Максим, отсутствие профессиональных знаний вам всегда сильно мешало (не из-за этого пришлось уволиться из компании провайдера?). Вы так до сих пор и не разобрались, как устроена и работает система. Похоже, даже её краткое описание в этом топике не прочитали.
Очень жаль, что вводите читателей блога в заблуждение. Однако, по порядку (синтаксис автора оставил без изменений):
1. «Вся система по настоящее время работает на пхе скриптах» — вся система работает на PostgreSQL
2. «Все периодические задачи, такие как… Работает на пхп скриптах, которые с rwx запускаются от рута кроном» — подсистема управления построена на планировщике задач pgAgent
3. «в субд на машине с локалью UTF8 бд имеет cp1251» — локаль кластера БД не имеет никакого отношения к системной локали
4. «Коллекторы для учета трафика писаны на пехепе» — система поставляется настроенной для работы с коллектором и агрегатором NetFlow из пакета nfdump
5. «Роли пользователей прописываются не в субд а в скриптах веб интерфейса» — роль системного пользователя — это один из атрибутов справочника пользователей базы данных
6. «Роли правятся инъекциями» — в WEB-интерфейсе администратора предусмотрена защита от sql-инъекций
7. «хранить пароли плэйнтекстрм в субд вообще плохо» — пароли пользователей хранятся в хешированном виде
8. «я представитель компании в которой это внедрялось впервые» — и это тоже неправда
На прочие огульные типа «система ВСЯ состоит из подпорок» и «жжены могли друг у друга деньги тырить» и просто оскорбительные высказывания я, конечно, отвечать не намерен.
Размещение всей бизнес-логики системы, описанной отношениями между сущностями, ограничениями, проверками, правилами, триггерами и функциями, непосредственно в базе данных на наш взгяд имеет следующие преимущества:
1. надёжность — прекомпиляцию, оптимизацию и исполнение кода выполняет СУБД
2. корректность хранимых данных — проверкой правильности пользовательского ввода и поддержкой целостности данных занимается СУБД
3. скорость работы — индексирование данных в таблицах и построение представлений не «вообще», а оптимизированных под выполнение конкретных запросов на чтение, добавление и модификацию данных
4. низкие требования к вычислительным ресурсам — отсутствие массы неоптимизированных запросов к БД из программных модулей, кстати, самих потребляющих системные ресуры при работе
5. простота написания и модификации WEB-интерфейсов — один, как правило примитивный, sql-запрос к базе на страничку
6. удобство поддержки и простота проведения доработок — весь код находится в одном месте, а не «размазан» по отдельным модулям
7. простота установки системы и низкая стоимость владения — сводится, в основном, к инсталляции и поддержке работы сервера PostgreSQL.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
Не хотелось грузить текст техническими подробностями, что, очевидно, привело бы к его плохой читаемости.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Наследование использовалось для секционирования больших архивных таблиц с данными о трафике и начислениях.
Может, текст и не очень складный, но идею Вы уловили правильно: ядро системы — БД PostgreSQL. Написать аналогичный код с использованием MySQL было бы затруднительно. И полностью открытый код, конечно.
Просто поделился опытом того, что можно не просто писать программы, но при этом и реализовывать некую концепцию. Хороша она или не очень — судить Вам, а насколько хорошо она реализована в продукте — пользователям системы.
Это вы про торговлю фруктами (апельсинами) :-))? Мы позиционируемся на рынке ISP.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение. Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен. Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет. При этом все проблемы — все лишь написать (найти в Инете) скрипт управления конкретным имеющимся оборудованием.
2. «Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона. Конечно, здорово, что можно использовать любой источник данных, однако:
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
— исходные данные часто тоже надо хранить
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат? Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
Очень жаль, что вводите читателей блога в заблуждение. Однако, по порядку (синтаксис автора оставил без изменений):
1. «Вся система по настоящее время работает на пхе скриптах» — вся система работает на PostgreSQL
2. «Все периодические задачи, такие как… Работает на пхп скриптах, которые с rwx запускаются от рута кроном» — подсистема управления построена на планировщике задач pgAgent
3. «в субд на машине с локалью UTF8 бд имеет cp1251» — локаль кластера БД не имеет никакого отношения к системной локали
4. «Коллекторы для учета трафика писаны на пехепе» — система поставляется настроенной для работы с коллектором и агрегатором NetFlow из пакета nfdump
5. «Роли пользователей прописываются не в субд а в скриптах веб интерфейса» — роль системного пользователя — это один из атрибутов справочника пользователей базы данных
6. «Роли правятся инъекциями» — в WEB-интерфейсе администратора предусмотрена защита от sql-инъекций
7. «хранить пароли плэйнтекстрм в субд вообще плохо» — пароли пользователей хранятся в хешированном виде
8. «я представитель компании в которой это внедрялось впервые» — и это тоже неправда
На прочие огульные типа «система ВСЯ состоит из подпорок» и «жжены могли друг у друга деньги тырить» и просто оскорбительные высказывания я, конечно, отвечать не намерен.
1. надёжность — прекомпиляцию, оптимизацию и исполнение кода выполняет СУБД
2. корректность хранимых данных — проверкой правильности пользовательского ввода и поддержкой целостности данных занимается СУБД
3. скорость работы — индексирование данных в таблицах и построение представлений не «вообще», а оптимизированных под выполнение конкретных запросов на чтение, добавление и модификацию данных
4. низкие требования к вычислительным ресурсам — отсутствие массы неоптимизированных запросов к БД из программных модулей, кстати, самих потребляющих системные ресуры при работе
5. простота написания и модификации WEB-интерфейсов — один, как правило примитивный, sql-запрос к базе на страничку
6. удобство поддержки и простота проведения доработок — весь код находится в одном месте, а не «размазан» по отдельным модулям
7. простота установки системы и низкая стоимость владения — сводится, в основном, к инсталляции и поддержке работы сервера PostgreSQL.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Наследование использовалось для секционирования больших архивных таблиц с данными о трафике и начислениях.